From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: bogus: logical replication rows/cols combinations |
Date: | 2022-05-03 03:53:04 |
Message-ID: | CAA4eK1Loc39w9Uyb87ZPx0=v85yutu0Co53Tzqd+9inFpPKMQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 2, 2022 at 6:11 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2022-May-02, Amit Kapila wrote:
>
> > 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?
>
Yes, something on these lines. We need a way to get the list of
publications each walsender is publishing data for.
> 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).
>
I think for this we need to check DSM for all the publications and I
feel in general publications should be more than the number of
walsenders, so the previous approach seems better to me. However, any
one of these or similar ideas should be okay.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-05-03 04:04:38 | Re: strange slow query - lost lot of time somewhere |
Previous Message | Tom Lane | 2022-05-03 03:44:32 | Re: failures in t/031_recovery_conflict.pl on CI |