Move system identifier generation to a common helper

Started by Imran Zaheer19 days ago3 messageshackers
Jump to latest
#1Imran Zaheer
imran.zhir@gmail.com

Hi

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.

Thanks
Imran Zaheer

Attachments:

v1-0001-Move-system-identifier-generation-to-a-common-hel.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Move-system-identifier-generation-to-a-common-hel.patchDownload+84-37
#2Peter Eisentraut
peter_e@gmx.net
In reply to: Imran Zaheer (#1)
Re: 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.

#3Daniel Gustafsson
daniel@yesql.se
In reply to: Peter Eisentraut (#2)
Re: Move system identifier generation to a common helper

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