On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > > On 03/11/2015 05:01 AM, Amit Kapila wrote: >> >> >> >> Can't that happen if the source database (new-master) haven't >> received all of the data from target database (old-master) at the >> time of promotion? >> If yes, then source database won't have WAL for truncation and >> the way current mechanism works is must. >> >> Now I think for such a case doing truncation in the target database >> is the right solution, > > > Yeah, that can happen, and truncation is the correct fix for it. The logic is pretty well explained by this comment in filemap.c: > > > * > * If it's the same size, do nothing here. Any locally > * modified blocks will be copied based on parsing the local > * WAL, and any remotely modified blocks will be updated after > * rewinding, when the remote WAL is replayed. > */ >
What about unlogged table, how will they handle this particular case? I think after old-master and new-master got diverged any operations on unlogged table won't guarantee that we can get those modified blocks from new-master during pg_rewind and I think it can lead to a case where unlogged tables have some data from old-master and some data from new master considering user always take of clean shut-down. Typo in patch: + * For our purposes, only files belonging to the main fork are considered + * relation files. Other forks are alwayes copied in toto, because we cannot /alwayes/always With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
