On 5/7/22 07:36, Amit Kapila wrote: > On Mon, May 2, 2022 at 6:11 PM Alvaro Herrera <alvhe...@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? >
Why would any of this be needed? ALTER PUBLICATION will invalidate the RelationSyncEntry entries in all walsenders, no? So AFAICS it should be enough to enforce the limitations in get_rel_sync_entry, which is necessary anyway because the subscriber may not be connected when ALTER PUBLICATION gets executed. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
