Move system identifier generation to a common helper

On 04.06.26 14:22, Imran Zaheer wrote:

The code used to generate a new system identifier is duplicated in
multiple locations, including BootStrapXLOG(), pg_createsubscriber, and
pg_resetwal.

Move the generation logic into a common GenerateSystemIdentifier()
helper so that all callers use a single implementation, avoiding
duplication of the same algorithm.

Then again, this code is from PG 8.0. We have had pg_strong_random()
required since PG 12. Maybe we should use that now for this.

On 10 Jun 2026, at 15:25, Peter Eisentraut <peter@eisentraut.org> wrote:

On 04.06.26 14:22, Imran Zaheer wrote:

The code used to generate a new system identifier is duplicated in
multiple locations, including BootStrapXLOG(), pg_createsubscriber, and
pg_resetwal.
Move the generation logic into a common GenerateSystemIdentifier()
helper so that all callers use a single implementation, avoiding
duplication of the same algorithm.

Then again, this code is from PG 8.0. We have had pg_strong_random() required since PG 12. Maybe we should use that now for this.

One feature of the current scheme is that it's explicitly not random, but can
be reverse-engineered to figure out the init time. Maybe we should have a
better way of doing that regardless, but it doesn't seem like a bad feature to
keep.

--
Daniel Gustafsson

On Thu, Jun 11, 2026 at 1:29 AM Daniel Gustafsson <daniel@yesql.se> wrote:

On 10 Jun 2026, at 15:25, Peter Eisentraut <peter@eisentraut.org> wrote:

On 04.06.26 14:22, Imran Zaheer wrote:

The code used to generate a new system identifier is duplicated in
multiple locations, including BootStrapXLOG(), pg_createsubscriber, and
pg_resetwal.
Move the generation logic into a common GenerateSystemIdentifier()
helper so that all callers use a single implementation, avoiding
duplication of the same algorithm.

Then again, this code is from PG 8.0. We have had pg_strong_random() required since PG 12. Maybe we should use that now for this.

One feature of the current scheme is that it's explicitly not random, but can
be reverse-engineered to figure out the init time. Maybe we should have a
better way of doing that regardless, but it doesn't seem like a bad feature to
keep.

--
Daniel Gustafsson

Hi,

The ability to extract init time can be useful for debugging purposes.

```
postgres=# SELECT to_timestamp(system_identifier >> 32) AS
cluster_init_time FROM pg_control_system();
cluster_init_time
------------------------
2026-06-05 17:12:07+05
(1 row)

```

To preserve this while improving the uniqueness, we could keep the
upper 32 bit (tv_sec) and replace the lower half (tv_usec + PID) with
pg_strong_random().

```
+ struct timeval tv;
+ uint64 sysidentifier;
+ uint32 random_bits;
+
+ gettimeofday(&tv, NULL);
+ sysidentifier = ((uint64) tv.tv_sec) << 32;
+
+ if (!pg_strong_random(&random_bits, sizeof(random_bits)))
+ {
+ #ifndef FRONTEND
+ elog(PANIC, "could not generate random bytes for system identifier");
+ #else
+ pg_fatal("could not generate random bytes for system identifier");
+ #endif
+ }
+
+ sysidentifier |= (uint64) random_bits;

```

thoughts?