On 05.09.2012 07:55, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
I was worried about that too at first, but Fujii pointed out that's OK: see
last paragraph at
http://archives.postgresql.org/pgsql-hackers/2012-08/msg01203.php.
Mmm, ok.
I'm worried about master-standby-standby setup whe
Heikki Linnakangas writes:
> I was worried about that too at first, but Fujii pointed out that's OK: see
> last paragraph at
> http://archives.postgresql.org/pgsql-hackers/2012-08/msg01203.php.
Mmm, ok.
I'm worried about master-standby-standby setup where the master
disappear, we promote a stand
On 05.09.2012 01:03, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
On 04.09.2012 03:02, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Hmm, I was thinking that when walsender gets the position it can send the
WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the curr
Heikki Linnakangas writes:
> On 04.09.2012 03:02, Dimitri Fontaine wrote:
>> Heikki Linnakangas writes:
>>> Hmm, I was thinking that when walsender gets the position it can send the
>>> WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current
>>> recovery timeline. If it has c
On 04.09.2012 21:56, Peter Eisentraut wrote:
On Tue, 2012-09-04 at 19:34 -0700, Heikki Linnakangas wrote:
The attached patch fixes it for me. It fixes the original problem, by
adding the missing locking and terminating walsenders on a target
timeline change, and also changes the behavior wrt. WA
On Tue, 2012-09-04 at 19:34 -0700, Heikki Linnakangas wrote:
> > The attached patch fixes it for me. It fixes the original problem, by
> > adding the missing locking and terminating walsenders on a target
> > timeline change, and also changes the behavior wrt. WAL segments
> > restored from the arc
On 04.09.2012 17:34, Heikki Linnakangas wrote:
On 04.09.2012 16:50, Tom Lane wrote:
Josh Berkus writes:
Heikki,
It is for 9.2. I'll do a little bit more testing, and barring any
issues, commit the patch. What exactly is the schedule? Do we need
to do
a RC2 because of this?
We're currently s
On 04.09.2012 16:50, Tom Lane wrote:
Josh Berkus writes:
Heikki,
It is for 9.2. I'll do a little bit more testing, and barring any
issues, commit the patch. What exactly is the schedule? Do we need to do
a RC2 because of this?
We're currently scheduled to release next week. If we need to d
On 03.09.2012 17:40, Heikki Linnakangas wrote:
On 03.09.2012 16:26, Heikki Linnakangas wrote:
On 03.09.2012 16:25, Fujii Masao wrote:
On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas
wrote:
Hmm, I was thinking that when walsender gets the position it can send
the
WAL up to, in GetStandbyFlus
Josh Berkus writes:
> Heikki,
>> It is for 9.2. I'll do a little bit more testing, and barring any
>> issues, commit the patch. What exactly is the schedule? Do we need to do
>> a RC2 because of this?
> We're currently scheduled to release next week. If we need to do an
> RC2, we're going to hav
Heikki,
> It is for 9.2. I'll do a little bit more testing, and barring any
> issues, commit the patch. What exactly is the schedule? Do we need to do
> a RC2 because of this?
We're currently scheduled to release next week. If we need to do an
RC2, we're going to have to do some fast reschedulin
On 04.09.2012 15:41, Josh Berkus wrote:
Guys,
Is this a patch to 9.3?
i.e. do we need to delay the release for this?
It is for 9.2. I'll do a little bit more testing, and barring any
issues, commit the patch. What exactly is the schedule? Do we need to do
a RC2 because of this?
- Heikki
On 04.09.2012 03:02, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Hmm, I was thinking that when walsender gets the position it can send the
WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current
recovery timeline. If it has changed, refuse to send the new WAL and
ter
Guys,
Is this a patch to 9.3?
i.e. do we need to delay the release for this?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
Heikki Linnakangas writes:
> Hmm, I was thinking that when walsender gets the position it can send the
> WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current
> recovery timeline. If it has changed, refuse to send the new WAL and
> terminate. That would be a fairly small cha
On 03.09.2012 16:26, Heikki Linnakangas wrote:
On 03.09.2012 16:25, Fujii Masao wrote:
On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas
wrote:
Hmm, I was thinking that when walsender gets the position it can send
the
WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the
current
On 03.09.2012 16:25, Fujii Masao wrote:
On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas wrote:
Hmm, I was thinking that when walsender gets the position it can send the
WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current
recovery timeline. If it has changed, refuse t
On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas wrote:
> On 03.09.2012 10:43, Fujii Masao wrote:
>>
>> On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote:
>>>
>>> On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas
>>> wrote:
Aside from the missing locking, I wonder what that does to
On 03.09.2012 10:43, Fujii Masao wrote:
On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote:
On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote:
Aside from the missing locking, I wonder what that does to a cascaded
standby. If there is an active walsender running while RecoveryTargetTLI
On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote:
> On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote:
>> When a cascading standby launches a new walsender, it fetches the current
>> recovery timeline:
>>
>> /*
>> * Use the recovery target timeline ID during recovery
>>
On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote:
> When a cascading standby launches a new walsender, it fetches the current
> recovery timeline:
>
> /*
> * Use the recovery target timeline ID during recovery
> */
> if (am_cascading_walsender)
>
When a cascading standby launches a new walsender, it fetches the
current recovery timeline:
/*
* Use the recovery target timeline ID during recovery
*/
if (am_cascading_walsender)
ThisTimeLineID = GetRecoveryTargetTLI();
Comment in GetRecoveryT
22 matches
Mail list logo
