Re: pg_rewind in contrib
| От | Amit Kapila |
|---|---|
| Тема | Re: pg_rewind in contrib |
| Дата | |
| Msg-id | CAA4eK1K2nLoH_=oq4x=-srMr8Z9MLGT3Uhn+Ha3nRNkH6WqtfQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_rewind in contrib (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Список | pgsql-hackers |
On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas <hlinnaka@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?
>
> 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
В списке pgsql-hackers по дате отправления: