Re: Crash after a call to pg_backup_start()
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Richard Guo <guofenglinux@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2022-10-21T15:07:18Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-assertion-failure-in-do_pg_abort_backup.patch (application/x-patch) patch v1-0001
On Fri, Oct 21, 2022 at 7:06 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Fri, Oct 21, 2022 at 05:53:25PM +0800, Richard Guo wrote: > > Yeah, the two conditions could be both false. How about we update the > > comment a bit to emphasize this? Such as > > > > /* At most one of these conditions can be true */ > > or > > /* These conditions can not be both true */ > > If you do that, it would be a bit easier to read as of the following > assertion instead? Like: > Assert(!during_backup_start || > sessionBackupState == SESSION_BACKUP_NONE); > > Please note that I have not checked in details all the interactions > behind register_persistent_abort_backup_handler() before entering in > do_pg_backup_start() and the ERROR_CLEANUP block used in this > routine (just a matter of some elog(ERROR)s put here and there, for > example). Anyway, yes, both conditions can be false, and that's easy > to reproduce: > 1) Do pg_backup_start(). > 2) Do pg_backup_stop(). > 3) Stop the session to kick do_pg_abort_backup() > 4) Assert()-boom. I'm wondering if we need the assertion at all. We know that when the arg is true or the sessionBackupState is SESSION_BACKUP_RUNNING, the runningBackups would've been incremented and we can just go ahead and decrement it, like the attached patch. This is a cleaner approach IMO unless I'm missing something here. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Fix recently added incorrect assertion
- 8328a15f8f95 16.0 landed