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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
