On 02/05/17 05:35, Michael Paquier wrote: > On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: >> On 4/25/17 21:47, Michael Paquier wrote: >>> Attached is an updated patch to reflect that. >> >> I edited this a bit, here is a new version. > > Thanks, looks fine for me. > >> A variant approach would be to prohibit *all* new commands after >> entering the "stopping" state, just let running commands run. That way >> we don't have to pick which individual commands are at risk. I'm not >> sure that we have covered everything here. > > It seems to me that everything is covered. We are taking about > creation and dropping of slots here, where standby snapshots can be > created and SQL queries can be run when doing a tablesync meaning that > FPWs could be taken in the context of the WAL sender. Blocking all > commands would be surely safer I agree, but I see no reason to block > things more than necessary. >
I don't think the code covers all because a) the SQL queries are not covered at all that I can see and b) logical decoding can theoretically do HOT pruning (even if the chance is really small) so it's not safe to start logical replication either. I wonder if this whole prevent thing should just be called unconditionally on walsender that's connected to database (am_db_walsender), because in the WAL logging will only happen there - CREATE_REPLICATION_SLOT PHYSICAL will not WAL log and CREATE_REPLICATION_SLOT LOGICAL can't be run without being connected to db, neither can logical decoding and SQL queries, so that coves all. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
