pgEdge Posts from Asif Naeem https://www.pgedge.com/blog The latest pgEdge Posts from Asif Naeem en-us postgres,pgEdge,PostgreSQL <![CDATA[Simplifying Cluster-Wide SQL Execution in pgEdge with exec_node()]]> https://www.pgedge.com/blog/simplifying-cluster-wide-sql-execution-in-pgedge-with-exec_node Fri, 14 Nov 2025 05:02:00 GMT pgEdge Distributed Postgres is a database system built on top of standard open‑source Postgres, extended to support global, distributed, and multi‑master (active‑active) deployments.In the evolving landscape of distributed databases, efficient query execution across nodes is essential to leverage the full power of a distributed architecture. Specifically for distributed Postgres environments, managing a multi-node cluster often requires executing SQL commands that don’t automatically replicate. This includes critical operations like executing DDL statements, performing administrative tasks, and altering cluster configuration - actions that must be applied only on specific nodes.To solve this operational challenge, I created the function: a utility designed to make remote SQL execution across pgEdge nodes simple, consistent, and scriptable directly from within the database.

Why I Created exec_node()

As part of general administration tasks, there is commonly a need to execute SQL commands on a specific node or all nodes within a pgEdge distributed cluster. pgEdge leverages Spock for logical replication, but many important SQL commands—particularly the following DDL and Spock-specific cluster management functions—do not replicate by design. This includes operations like:
      • -
      • VACUUM
      • Spock-specific commands like
      • spock.repset_add_table
      • ,
      • spock.node_add_interface
      In a traditional setup, executing these commands safely and consistently across all or specific nodes requires manual logins, scripts, or orchestration tools. This is time-consuming and requires additional steps.

      Using exec_node()

      With , you can issue commands directly from the database—through SQL—and target the exact node you want. The function signature is:
          With you can:Run SQL on Any or All Nodes — Remotely and NativelyWhether you're running a maintenance command, executing DDL statements, or configuring Spock, you can use to do it all from a single SQL interface.Example: Running a data maintenance command statement only on node1:;Example: Applying a maintenance operation across all nodes:;Execute Non-Replicating Commands Where They BelongSome SQL commands are intentionally not replicated in pgEdge; this is either to avoid conflicts or is because they are inherently local. allows these commands to be sent only to the relevant node(s), avoiding misconfiguration or inconsistencies.Common non-replicating commands include:
                Example: Setting a GUC value on node 3 (only):Example: Changing a GUC on all the cluster nodes:Execute Spock Cluster Management FunctionspgEdge clusters are built on top of the Spock extension for logical replication, but Spock management commands must be run on a specific node—and they don’t replicate.  makes this easy to automate and manage.Example: Adding a table to a replication set:Example: Creating a table on all the pgEdge nodes without adding them to the replication set:Without exec_node(), these operations would require logging into each node or writing external scripts; now they can be run as SQL from any connected client or script.Supports Targeted DDL DeploymentSometimes not every function or schema change is required to happen on every node. Instead,  you might want:Example: Targeted function deployment:You now have precise control over where that function lives.

                Improves Automation and Operational Safety

                Because  works like any SQL function, it integrates seamlessly into:It removes the need for external scripting or SSH automation and reduces the risk of human error by centralising command execution in a controlled and auditable way.

                Use Cases

                Use to help with:
                • deploying a non-replicated data maintenance command,  
                • DDL
                •  or
                • functions
                •  to a specific node.
                • running Spock configuration commands (
                • repset_add_table, node_add_interface
                • , etc.).
                • executing maintenance commands (
                • VACUUM, REINDEX, ANALYZE
                • ) cluster-wide.
                • setting or altering system parameters per node (
                • ALTER SYSTEM
                • ).
                • Creating or dropping databases on individual nodes.
                • Controlled rollout of feature flags or logic to subset of nodes.
                Best Practices
                • Use with awareness
                • : While powerful, be careful when executing write operations across all nodes. Ensure commands are safe / secure and do not pose risks.
                • Log executions
                • : In automation scripts, consider logging the use of
                • exec_node()
                •  for auditability.
                • Validate SQL
                • : Especially when executing SQL, validate the structure and scope to avoid unintended changes.
                • Test on dev/staging
                • : For complex cluster operations, test
                • exec_node()
                •  in non-production environments before rollout.

                ]]>                 https://www.pgedge.com/blog/simplifying-cluster-wide-sql-execution-in-pgedge-with-exec_node Asif Naeem                 PostgreSQL <![CDATA[Using Snowflake Sequences with the Hibernate IDENTITY column]]> https://www.pgedge.com/blog/using-snowflake-sequences-with-the-hibernate-identity-column Tue, 27 May 2025 05:28:00 GMT A PostgreSQL native sequence is a great way to generate unique IDs, but there is risk of duplicate ID generation if you use it in a distributed cluster environment. The pgEdge Snowflake extension is designed for use in a distributed environment, helping you generate truly unique identifiers with ease.Snowflake functions create unique identifiers that are designed to support parallel execution across multiple nodes. Using a Snowflake sequence ensures that each generated number is consistent and addresses the need for uniqueness across all of the pgEdge cluster nodes.This is the first in a series of blogs in which I will share different ways to adapt sequences in the pgEdge cluster environment.

                Snowflake Sequence Overview

                The Snowflake extension creates a replication-friendly identifier that you can use to replace problematic PostgreSQL sequence definitions in your tables that reside in a distributed replication environment. pgEdge PostgreSQL automatically installs and creates the extension in each pgEdge cluster.Snowflake sequences let you:
                • Add or modify data in different regions while ensuring a unique transaction sequence.
                • Preserve unique transaction identifiers without manual/administrative management of a numbering scheme.
                • Accurately identify the order in which globally distributed transactions are performed.
                Each Snowflake ID is a 64-bit value that is composed of the multiple parts:
                • Timestamp: 41 bits that contains the number milliseconds since 2023-01-01
                • Node number: 10 bits identifying a unique node number (set as a PostgreSQL GUC)
                • Counter Number: 12 bits that increment the value for handling multiple IDs that might be generated in the same millisecond
                Hibernate software is an object-relational mapping (ORM) tool for Java developers that helps map Java objects (classes) to database tables, and automatically handles converting data between the two. It’s one of the most popular ORM frameworks in the Java ecosystem and is part of the Java Persistence API (JPA) standard. In our examples, we'll use a Snowflake sequence in a Hibernate environment.If you're working in a traditional replication environment (without the benefits of multi-master replication), using a Hibernate identity column as an auto-generated primary key implies that the database will automatically generate IDs. However, in distributed systems like pgEdge multi-master replication, Hibernate IDs can lead to collision issues if multiple nodes try to generate the same ID concurrently.The following code snippets implement Snowflake sequences in a Hibernate environment hosted on a pgEdge cluster: relies on PostgreSQL's SERIAL or BIGSERIAL type. Hibernate will create the  table with a 64 bit ID; in SQL, the table would look like:In a distributed environment, adding data to this table would have the potential to create conflicting identifiers (which in turn result in replication interruption and maintenance overhead). The collision issue can be avoided with minimal changes by adopting Snowflake sequences. As shown in the following code snippets, it's simple to replace the PostgreSQL style sequences with Snowflake sequences; simply:

                  Automating Snowflake Sequence Implementation

                  You can use a PostgreSQL event trigger to ensure the use of Snowflake sequences when you create a table. The following example defines a PostgreSQL event trigger that automatically replaces column sequence definitions, replacing them with a Snowflake sequence.After creating this trigger in your PostgreSQL database, any time you run a  command, this trigger fires, looking for any  syntax that is part of the CREATE TABLE command; if it finds any, it replaces the column's default value (usually ) with .

                  ]]>                   https://www.pgedge.com/blog/using-snowflake-sequences-with-the-hibernate-identity-column Asif Naeem