Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 15, 2020 at 10:25 AM Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > > Well, if the transaction was declared read-only, then committing it > > (directly or 2PC) shouldn't change anything. This appears to be a > > circular argument. > > I don't think it's a circular argument. Suppose that someone decrees > that, as of 5pm Eastern time, no more read-write transactions are > permitted. And because the person issuing the decree has a lot of > power, everybody obeys. Now, every pg_dump taken after that time will > be semantically equivalent to every other pg_dump taken after that > time, with one tiny exception. That exception is that someone could > still do COMMIT PREPARED of a read-write transaction that was prepared > before 5pm. If the goal of the powerful person who issued the decree > was to make sure that the database couldn't change - e.g. so they > could COPY each table individually without keeping a snapshot open and > still get a consistent backup - they might fail to achieve it if, as > of the moment of the freeze, there are some prepared write > transactions. > > I'm not saying we have to change the behavior or anything. I'm just > saying that there seems to be one, and only one, way to make the > apparent contents of the database change in a read-only transaction > right now. And that's a COMMIT PREPARED of a read-write transaction.
Yeah, allowing a read-only transaction to start and then commit a read-write transaction doesn't seem sensible. I'd be in favor of changing that. Thanks, Stephen
signature.asc
Description: PGP signature