OCD questions about LWTRANCHE_REPLICATION_ORIGIN

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: OCD questions about LWTRANCHE_REPLICATION_ORIGIN
Date: 2018-02-12 01:35:24
Message-ID: CAEepm=2kDJW9ZgnVgFvfnGLwvO_oJqKbFsDyZheRqh4DN6h1Yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Just curious about a harmless inconsistency, really: why does
src/backend/replication/logical/origin.c bother to copy
LWTRANCHE_REPLICATION_ORIGIN into shm and then LWLockRegisterTranche()
in every process from the shm copy? I guess because it used to
allocate the tranche ID dynamically with LWLockNewTrancheId(), but it
doesn't anymore. So my questions are:

1. Why shouldn't we just call
LWLockRegisterTranche(LWTRANCHE_REPLICATION_ORIGIN,
"replication_origin") and get rid of "tranche_id" in shm?

2. What is our basis for registering some built-in LWLock tranches in
XXXShmemInit() and the rest in RegisterLWLockTranches()? Why
shouldn't we just move this one over to RegisterLWLockTranches()?
Then it'd be easier to verify that we've registered them all.

Come to think of it, I suppose someone might even argue that we should
have lwtranchenames.txt, much like lwlocknames.txt, that would produce
the enumerators and register the display name for all built-in
tranches. And then a hypothetical cross-check script that runs under
check-world as previously mooted could verify that every display name
mentioned in there is also mentioned in monitoring.sgml. I say that
as someone who recently screwed up and forgot to register the display
name of a new built-in tranche[1]...

[1] https://www.postgresql.org/message-id/CAEepm%3D1WM%3D02cKT7hinnx8xRhN2QdF%2BWfE6gk5oMPorwLi%2BXiA%40mail.gmail.com

--
Thomas Munro
http://www.enterprisedb.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Mat Arye 2018-02-12 02:50:32 Minor version upgrades and extension packaging
Previous Message Sand Stone 2018-02-12 01:14:38 Fwd: persistent read cache