Re: bogus: logical replication rows/cols combinations
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-05-07T05:36:02Z
Lists: 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.
Commits
-
Prohibit combining publications with different column lists.
- fd0b9dcebda7 15.0 landed
-
Extend pg_publication_tables to display column list and row filter.
- 0ff20288e1cb 15.0 landed
-
Remove dynamic_shared_memory_type=none
- bcbd940806a2 12.0 cited