On Tue, 2007-07-24 at 17:53 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > There is an explicit test for whether the transaction has modified
> > files; if so the commit is always synchronous, even if explicitly
> > requested otherwise. Also, utility commands never perform async commits,
> > so overall there aren't that many of the commonly used DDL commands that
> > could be performed and still have it be an async commit.
>
> Huh? I see neither a reason for these restrictions
So that we don't lose DROP TABLEs, TRUNCATEs for example. If the
database crashed between removing the file and flushing the WAL then the
relfilenode would be incorrectly set for a non-temp table and we would
have no easy way of working out what to do. That seems like a problem to
me, if we let it occur; the patch avoids that trivially.
> nor any way that you
> could enforce them without horrid kluges.
In RecordTransactionCommit we do smgrGetPendingDeletes(), so we know if
there are files to be removed at commit time. If there are files to be
removed then in the async commit patch we override the setting of
synchronous_commit that was requested for that transaction so that the
transaction will always be synchronous.
So this works for DROP TABLE, DROP INDEX and TRUNCATE.
CREATE TABLE would not be such a problem since if we crash between
commit and WAL flush then the reference to the file would not be
present, even if the table would be. Data loss, but no catalog integrity
issue.
We *might* want to override the commit to be synchronous if there is
anything at all in the pending delete list, whether atCommit or atAbort.
This would then work for both CREATE and DROP. An additional smgr call
to do this would be fast and easy, as well as modular since there are
already calls from xact.c to smgr.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
