From: David Steele <david@pgbackrest.org>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Bug in recovery of drop database?
Date: Fri, 07 Feb 2025 14:16:39 +0000 (UTC)
Message-ID: <b10fc6a3-b14c-4150-83e6-fc025cd3a80e@pgbackrest.org> (raw)
In-Reply-To: <c1c2c818-888a-45d8-8994-4ed591cc11ed@pgbackrest.org>
References: <43f0c3df-a23c-4159-9610-934d3dceb80c@pgbackrest.org>
<73f2e462-d767-4248-98ed-9c0fcdac10bf@pgbackrest.org>
<cv3jqr2n6o4jgp6f6mvscecno3i4ps5hgbs57h72djw47vjzu7@uvmkcshcspyv>
<c1c2c818-888a-45d8-8994-4ed591cc11ed@pgbackrest.org>
On 2/6/25 14:28, David Steele wrote:
> On 2/6/25 13:05, Andres Freund wrote:
>
>> IOW, while the two-step-drop-database is an issue, even without it, your
>> reproducer doesn't seem like it actually would work, even if it were a
>> single
>> step, to implement the below scenario:
>
> The repro works almost every time for me on all six active branches. It
> hasn't worked a few times, but in those cases I suspect I accidentally
> skipped a step. I'm running it manually each time.
Sorry, I misunderstood you here -- I thought you were saying the
reproducer doesn't work as is, which was confusing since it definitely does.
But I think it would work just fine if recovery was able stop before the
drop database. The timestamp is gathered before the drop database so I'd
expect that timestamp to get me recovered to before the drop database
whether it is inclusive or not. Certainly that's what the users expect
and that's what happens if I add another transaction before the drop
database.
Time-targeted recovery, which is by far the most common, doesn't always
work as one would hope depending on what WAL records are available to
guide recovery. The test scenarios that users setup are usually very
misleading because the lack of organic database activity often leads to
unexpected results.
I think in a database with normal activity this condition would be
fairly hard to hit, but that doesn't make it any less a bug. And the
fact that it is so easy to hit in common test scenarios makes users
worry about whether Postgres is able to recover consistently. I've seen
two reports of this recently which likely means even more people are
running into it.
Regards,
-David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: david@pgbackrest.org, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
Subject: Re: Bug in recovery of drop database?
In-Reply-To: <b10fc6a3-b14c-4150-83e6-fc025cd3a80e@pgbackrest.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox