Re: log shipping and nextval sequences - Mailing list pgsql-hackers

From Robert Haas
Subject Re: log shipping and nextval sequences
Date
Msg-id C458FDA0-29BF-4116-9F2D-C2FBA3553ABB@gmail.com
Whole thread Raw
In response to Re: log shipping and nextval sequences  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Aug 5, 2009, at 3:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Leonardo Cezar <lhcezar@gmail.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


pgsql-hackers by date:

Previous
From: "Todd A. Cook"
Date:
Subject: Re: slow commits with heavy temp table usage in 8.4.0
Next
From: "Kevin Grittner"
Date:
Subject: Re: Alpha Releases: Docs?