On 27 March 2015 at 04:54, Kyotaro HORIGUCHI <[email protected]> wrote: > Hello, > > At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund <[email protected]> > wrote in <[email protected]> >> I think the problem here is that the *primary* makes no such >> assumptions. Init forks are logged via stuff like >> smgrwrite(index->rd_smgr, INIT_FORKNUM, BTREE_METAPAGE, > .. >> i.e. the data is written out directly to disk, circumventing >> shared_buffers. It's pretty bad that we don't do the same on the >> standby. For master I think we should just add a bit to the XLOG_FPI >> record saying the data should be forced out to disk. I'm less sure >> what's to be done in the back branches. Flushing every HEAP_NEWPAGE >> record isn't really an option. > > The problem exists only for INIT_FORKNUM. So I suppose it is > enough to check forknum to decide whether to sync immediately. > > Specifically for this instance, syncing buffers of INIT_FORKNUM > at the end of XLOG_FPI block in xlog_redo fixed the problem. > > The another (ugly!) solution sould be syncing only buffers for > INIT_FORKNUM and is BM_DIRTY in ResetUnlogggedRelations(op = > UNLOGGED_RELATION_INIT). This is catching-all-at-once solution > though it is a kind of reversion of fast promotion. But buffers > to be synced here should be pretty few.
This bug still exists. Thom -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
