Re: needless complexity in StartupXLOG
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-27T12:23:15Z
Lists: pgsql-hackers
On Mon, Jul 26, 2021 at 4:15 PM Stephen Frost <sfrost@snowman.net> wrote: > All I was really trying to point out above was that the comment might be > improved upon, just so someone understands that we aren't doing a > checkpoint at this particular place, but one will be done later due to > the promotion. Maybe I'm being a bit extra with that, but that was my > thought when reading the code and the use of the promoted flag variable. Yeah, I agree, it confused me too, at first. > Yeah ... not to mention that it really is just incredibly dangerous to > use such an approach for PITR. For my 2c, I'd rather we figure out a > way to prevent this than to imply that we support it when we have no way > of knowing if we actually have replayed far enough to be consistent. > That isn't to say that using snapshots for database backups isn't > possible, but it should be done in-between pg_start/stop_backup calls > which properly grab the returned info from those and store the backup > label with the snapshot, etc. My position on that is that I would not particularly recommend the technique described here, but I would not choose to try to block it either. That's an argument for another thread, though. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Revert "Add new simple TAP test for tablespaces."
- 0c53a6658e47 15.0 cited
-
Remove unnecessary call to ReadCheckpointRecord().
- 1d919de5eb3f 15.0 landed