Re: Streaming replication and WAL archive interactions

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Borodin Vladimir <root(at)simply(dot)name>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and WAL archive interactions
Date: 2015-05-11 16:00:13
Message-ID: 5550D20D.6090703@iki.fi
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 05/08/2015 04:21 PM, Heikki Linnakangas wrote:
> On 04/22/2015 10:07 AM, Michael Paquier wrote:
>> On Wed, Apr 22, 2015 at 3:38 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> I feel that the best approach is to archive the last, partial segment, but
>>> with the .partial suffix. I don't see any plausible real-wold setup where
>>> the current behavior would be better. I don't really see much need to
>>> archive the partial segment at all, but there's also no harm in doing it, as
>>> long as it's clearly marked with the .partial suffix.
>>
>> Well, as long as it is clearly archived at promotion, even with a
>> suffix, I guess that I am fine... This will need some tweaking on
>> restore_command for existing applications, but as long as it is
>> clearly documented I am fine. Shouldn't this be a different patch
>> though?
>
> Ok, I came up with the attached, which adds the .partial suffix to the
> partial WAL segment that's archived after promotion. I couldn't find any
> natural place to talk about it in the docs, though. I think after the
> docs changes from the main patch are applied, it would be natural to
> mention this in the "Continuous archiving in standby", so I think I'll
> add that later.
>
> Barring objections, I'll push this later tonight.

Applied that part.

> Now that we got this last-partial-segment problem out of the way, I'm
> going to try fixing the problem you (Michael) pointed out about relying
> on pgstat file. Meanwhile, I'd love to get more feedback on the rest of
> the patch, and the documentation.

And here is a new version of the patch. I kept the approach of using
pgstat, but it now only polls pgstat every 10 seconds, and doesn't block
to wait for updated stats.

- Heikki

Attachment Content-Type Size
v3-0001-Make-WAL-archival-behave-more-sensibly-in-standby.patch application/x-patch 31.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-05-11 16:16:32 Re: initdb start server recommendation
Previous Message Tom Lane 2015-05-11 15:34:19 Re: EvalPlanQual behaves oddly for FDW queries involving system columns