Re: Add timeline to partial WAL segments

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Add timeline to partial WAL segments
Дата
Msg-id c615e1a4-04d8-c7d0-c252-fb3e6b874b28@pgmasters.net
обсуждение исходный текст
Ответ на Re: Add timeline to partial WAL segments  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Add timeline to partial WAL segments  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 12/15/18 1:56 AM, Michael Paquier wrote:
> On Fri, Dec 14, 2018 at 06:05:18PM -0500, David Steele wrote:
>> On 12/14/18 3:26 PM, Robert Haas wrote:
>>> The new TLI is the only thing that is guaranteed to be unique with
>>> each new promotion, and I would guess that it is therefore the right
>>> thing to use to disambiguate them.
>>
>> This is the conclusion we came to after a few months of diagnosing and
>> working on this problem.
> 
> Hm.  Okay.  From that point of view I think that we should also make
> pg_receivewal able to generate the same kind of segment format when it
> detects a timeline switch for the last partial segment of the previous
> timeline.  Switching to a new timeline makes the streaming finish, so we
> could use that to close properly the WAL segment with the new name.  At
> the same time it would be nice to have a macro able to generate a
> partial segment name and also check after it.

Or perhaps just always add the timeline to the .partial?  That way it 
doesn't need to be renamed later.  Also, there would be a consistent 
name, rather than sometimes .partial, sometimes .<timelime>.partial.

>> The question in my mind: is it safe to back-patch?
> 
> That's unfortunately a visibility change, meaning that any existing
> backup solution able to handle .partial segments would get broken in a
> minor release.  From that point of view this should go only on HEAD.

That means every archive command needs to deal with this issue on its 
own.  It's definitely not a trivial thing to do.

It's obviously strong to call this a bug, but there's very clearly an 
issue here.  I wonder if there is anything else we can do that would work?

> The other patch to reorder the priority of the .ready files could go
> down without any problem though.

Glad to hear it.

-- 
-David
david@pgmasters.net


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Change pgarch_readyXlog() to return .history files first
Следующее
От: Surafel Temesgen
Дата:
Сообщение: START/END line number for COPY FROM