On Thu, Jun 11, 2026 at 1:29 AM Daniel Gustafsson <[email protected]> wrote:
>
> > On 10 Jun 2026, at 15:25, Peter Eisentraut <[email protected]> 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?
