On 2022-May-02, Amit Kapila wrote:
> We don't do that currently but we can as mentioned in my previous
> email [1]. Let me write the relevant part again. We need to expose all
> publications for a walsender, and then we can find the exact set of
> publications where the current publication is used with other
> publications and we can check only those publications. So, if we have
> three walsenders (walsnd1: pub1, pub2; walsnd2 pub2; walsnd3: pub2,
> pub3) in the system and we are currently altering publication pub1
> then we need to check only pub3 for any conflicting conditions.
Hmm ... so what happens in the current system, if you have a running
walsender and modify the publication concurrently? Will the subscriber
start getting the changes with the new publication definition, at some
arbitrary point in the middle of their stream? If that's what we do,
maybe we should have a signalling system which disconnects all
walsenders using that publication, so that they can connect and receive
the new definition.
I don't see anything in the publication DDL that interacts with
walsenders -- perhaps I'm overlooking something.
> I think it is possible to expose a list of publications for each
> walsender as it is stored in each walsenders
> LogicalDecodingContext->output_plugin_private. AFAIK, each walsender
> can have one such LogicalDecodingContext and we can probably share it
> via shared memory?
I guess we need to create a DSM each time a walsender opens a
connection, at START_REPLICATION time. Then ALTER PUBLICATION needs to
connect to all DSMs of all running walsenders and see if they are
reading from it. Is that what you have in mind? Alternatively, we
could have one DSM per publication with a PID array of all walsenders
that are sending it (each walsender needs to add its PID as it starts).
The latter might be better.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
