log shipping and nextval sequences

Lists: pgsql-hackers
From: Leonardo Cezar <lhcezar(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: log shipping and nextval sequences
Date: 2009-08-05 18:59:24
Message-ID: 2315783e0908051159t7af908f0kd2aa4b4bcef00327@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:

* Primary server
- Create sequence seq_a;
- Select nextval ( 'seq_a'); # value 1;
- Log shipping;

* Standby server
- Failover;
- Select nextval ( 'seq_a') on standby # value = currval + 31 (written ahead)

AFAIK this occurs because some fetches (log_cnt) are made in advance
and they are recorded in the log and shipping together.
Does it necessary for some kind of overhead or something like that?

Does it make sense to create a GUC to control the log_cnt amount
rather than SEQ_LOG_VALS approach?

version: 8.3.7

regards,

-Leo
--
Leonardo Cezar
http://postgreslogia.wordpress.com
http://www.dextra.com.br/postgres


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Leonardo Cezar <lhcezar(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: log shipping and nextval sequences
Date: 2009-08-05 19:25:43
Message-ID: 27779.1249500343@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Leonardo Cezar <lhcezar(at)gmail(dot)com> writes:
> In warm standby system when we have a filled log segment forwarded to
> archiving, there is an inconsistency on standby next value sequences
> obtained by a call to nextval() function. e.g.:

> * Primary server
> - Create sequence seq_a;
> - Select nextval ( 'seq_a'); # value 1;
> - Log shipping;

> * Standby server
> - Failover;
> - Select nextval ( 'seq_a') on standby # value = currval + 31 (written ahead)

> AFAIK this occurs because some fetches (log_cnt) are made in advance
> and they are recorded in the log and shipping together.
> Does it necessary for some kind of overhead or something like that?

> Does it make sense to create a GUC to control the log_cnt amount
> rather than SEQ_LOG_VALS approach?

No. If your application expects the series not to have gaps, your
application is broken independently of warm standby. The same sort
of advance would happen if the master crashed and restarted.

regards, tom lane


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Leonardo Cezar <lhcezar(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log shipping and nextval sequences
Date: 2009-08-05 22:16:50
Message-ID: C458FDA0-29BF-4116-9F2D-C2FBA3553ABB@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Aug 5, 2009, at 3:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Leonardo Cezar <lhcezar(at)gmail(dot)com> writes:
>> In warm standby system when we have a filled log segment forwarded to
>> archiving, there is an inconsistency on standby next value sequences
>> obtained by a call to nextval() function. e.g.:
>
>> * Primary server
>> - Create sequence seq_a;
>> - Select nextval ( 'seq_a'); # value 1;
>> - Log shipping;
>
>> * Standby server
>> - Failover;
>> - Select nextval ( 'seq_a') on standby # value = currval + 31
>> (written ahead)
>
>> AFAIK this occurs because some fetches (log_cnt) are made in advance
>> and they are recorded in the log and shipping together.
>> Does it necessary for some kind of overhead or something like that?
>
>> Does it make sense to create a GUC to control the log_cnt amount
>> rather than SEQ_LOG_VALS approach?
>
> No. If your application expects the series not to have gaps, your
> application is broken independently of warm standby. The same sort
> of advance would happen if the master crashed and restarted.

Or if you ever roll back a transaction that has done nextval().

...Robert