From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: needless complexity in StartupXLOG |
Date: | 2021-07-27 12:23:15 |
Message-ID: | CA+TgmoYPNMPnOHpn1W2vTniBhJM1bNKvw-vM4nQeGF_vvDw=EQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 26, 2021 at 4:15 PM Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-07-27 12:25:31 | Re: Reduce the number of special cases to build contrib modules on windows |
Previous Message | Amit Kapila | 2021-07-27 11:36:37 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |