On Tue, Feb 23, 2021 at 3:58 AM Andres Freund <and...@anarazel.de> wrote: > > > At first this seems to be a significant issue. But on the other hand, if > you were to shut the cluster down in this situation (or disconnect all > sessions), you have broken cluster on your hand - without logical > decoding being involved. As it turns out, we need to read pg_class to > log in... And I can't remember this being reported to be a problem? >
I don't remember seeing such a report but I think that is a reason enough (leaving aside logical decoding of 2PC) to either disallow locking catalog tables or at least document it in some way. > > Perhaps all that we need to do is to disallow 2PC prepare if [user] > catalog tables have been locked exclusively? > Right, and we have discussed this during development [1][2]. We thought either we disallow this operation or will document it. I thought of doing this along with a core-implementation of Prepare waiting to get it logically replicated. But at this stage, I think if the user wants he can do a similar thing in his application where after prepare it can wait for the transaction to get logically replicated (if they have their own replication solution based on logical decoding) and then decide whether to rollback or commit. So, maybe we should either disallow this operation or at least document it. What do you think? > Similar to how we're > disallowing preparing tables with temp table access. > Yeah, we disallow other things like pg_export_snapshot as well in a Prepared transaction, so we can probably disallow this operation as well. [1] - https://www.postgresql.org/message-id/CAA4eK1JeeXOwD6rYnhSOYk5YN-fUTmxe1GkTpN2-BvgnKN6gZg%40mail.gmail.com [2] - https://www.postgresql.org/message-id/CAMGcDxf83P5SGnGH52=_0wrp9po6urwcmrwaa0nxktzvir2...@mail.gmail.com -- With Regards, Amit Kapila.
