Re: remove flatfiles.c

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:

> > Regarding sync commits that previously happen and now won't, I think the
> > only case worth worrying about is the one in vacuum.c.  Do we need a
> > ForceSyncCommit() in there?  I'm not sure if vacuum itself already
> > forces sync commit.
> 
> Hmm, I had been assuming we wouldn't need that anymore.

The comment in user.c and dbcommands.c says

    /*     * Force synchronous commit, thus minimizing the window between     * creation of the database files and
commitalof the transaction. If     * we crash before committing, we'll have a DB that's taking up disk     * space but
isnot in pg_database, which is not good.     */    ForceSyncCommit();
 

so I think those ones are still necessary.  There's another call in
RenameDatabase() which I don't think needs a sync commit (because it
won't change the dir name), and one in vacuum.c:
   /*
!    * If we were able to advance datfrozenxid, mark the flat-file copy of
!    * pg_database for update at commit, and see if we can truncate pg_clog.
!    * Also force update if the shared XID-wrap-limit info is stale.    */   if (dirty ||
!TransactionIdLimitIsValid())
-   {
-       database_file_update_needed();       vac_truncate_clog(newFrozenXid);
-   } }

AFAICT this doesn't need a sync commit.  (Right now, VACUUM FULL forces
one, but lazy vacuum doesn't).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support