On 2013-07-24 16:15:59 +0300, Heikki Linnakangas wrote:
> >For DROP DATABASE, without something like incomplete actions,
> >piggybacking on the commit record doesn't solve the issue of
> >CHECKPOINTS
> >either, because the commit record you piggybacked on could have
> >committed before a checkpoint, while you still were busy deleting all
> >the files.
>
> That's no different from CREATE TABLE / INDEX and DROP TABLE /
> INDEX. E.g. If you crash after CREATE TABLE but before COMMIT, the
> file is leaked. But it's just a waste of space, everything still
> works.
Imo it's not really the same. For one, spurious files left over by
CREATE TABLE are handled when assigning future relfilenodes (see
GetNewRelFileNode()), we don't do the same for databases and
tablespaces afaik.
Furthermore, I don't think there's such a big issue with DROP TABLE
unless maybe you've created the relation in the same transaction that
you're dropping it. Sure, there's the issue with a checkpoint in the
wrong place, but other than that we're going to remove the file when
replaying the commit record.
We also should never end up with an inconsistent state between catalog
and filesystem.
> It would be nice to fix that leak, for tables and indexes too...
Agreed.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services