On Tue, 2007-07-24 at 17:53 -0400, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster