On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown <t...@linux.com> wrote: > On 27 March 2015 at 04:54, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> Hello, >> >> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund <and...@2ndquadrant.com> >> wrote in <20150326175024.gj...@alap3.anarazel.de> >>> 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.
Hmm. This probably should have been on the open items list. I didn't pay too much attention this to this before because it seemed like Andres and Michael were all over it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
