Re: bogus: logical replication rows/cols combinations
От | Amit Kapila |
---|---|
Тема | Re: bogus: logical replication rows/cols combinations |
Дата | |
Msg-id | CAA4eK1Le0Z6W_+oY+M4vV=fjwFMJRg3WguPr3LQAfEqATrSLbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bogus: logical replication rows/cols combinations (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: bogus: logical replication rows/cols combinations
|
Список | pgsql-hackers |
On Mon, May 2, 2022 at 6:11 PM Alvaro Herrera <alvherre@alvh.no-ip.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? 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. > While thinking about using DSM here, I came across one of your commits f2f9fcb303 which seems to indicate that it is not a good idea to rely on it but I think you have changed dynamic shared memory to fixed shared memory usage because that was more suitable rather than DSM is not portable. Because I see a commit bcbd940806 where we have removed the 'none' option of dynamic_shared_memory_type. So, I think it should be okay to use DSM in this context. What do you think? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: