Re: pg_rewind in contrib

On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)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