From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Dilip Kumar <dilipbalaut@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Ashutosh Sharma <ashu.coek88@gmail.com>,
        Maciek Sakrejda <m.sakrejda@gmail.com>,
        Bruce Momjian <bruce@momjian.us>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Andrew Dunstan <andrew@dunslane.net>,
        Heikki Linnakangas <hlinnaka@iki.fi>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
In-reply-to: <20220804225147.ypcpujdcouhmkggz@awork3.anarazel.de>
References: 
 <CAFiTN-v4u2WJT6y1n4wtM4Z3tffJonT7zuRKegYao9p-Oyb07Q@mail.gmail.com>
 <CAFiTN-thCGvRF0_WftbDc0KFagB3vgHHGrpNdRMJ6vtkObEMoA@mail.gmail.com>
 <20220803160200.GD19644@telsasoft.com> <20220803170118.GG19644@telsasoft.com>
 <20220803182643.a6r2t2jyo5zxx767@awork3.anarazel.de>
 <20220803184857.GI19644@telsasoft.com>
 <CAFiTN-uCLPQf_3JHZwuMdUbMR0+tC8W5fG5-kQUKJR2b=-w-rQ@mail.gmail.com>
 <CAFiTN-v9M6myyLqZt0u5+52dqdpGkGbdjNcM3WMB5KOWcGD2tA@mail.gmail.com>
 <20220804214613.attcw2kktjz2z272@awork3.anarazel.de>
 <3664321.1659650725@sss.pgh.pa.us>
 <20220804225147.ypcpujdcouhmkggz@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 04 Aug 2022 15:51:47 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3681808.1659654848.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 04 Aug 2022 19:14:08 -0400
Message-ID: <3681809.1659654848@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3681809.1659654848%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-04 18:05:25 -0400, Tom Lane wrote:
>> In any case, DROP DATABASE is far from the only place with a problem.

> What other place has a database corrupting potential of this magnitude j=
ust
> because interrupts are accepted?  We throw valid s_b contents away and t=
hen
> accept interrupts before committing - with predictable results. We also =
accept
> interrupts as part of deleting the db data dir (due to catalog access).

Those things would be better handled by moving the data-discarding
steps to post-commit.  Maybe that argues for having an internal
commit halfway through DROP DATABASE: remove pg_database row,
commit, start new transaction, clean up.

			regards, tom lane