Re: Sequences / Replication

From: Alvaro Aguayo Garcia-Rada <aaguayo(at)opensysperu(dot)com>
To: Jonathan Eastgate <jonathan(dot)eastgate(at)simpro(dot)co>
Cc: PostgreSql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Sequences / Replication
Date: 2016-10-20 14:19:25
Message-ID: 1305285516.324703.1476973165273.JavaMail.zimbra@opensysperu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi. If the explanation given on one of the stackoverflow responses is right, then there's no current solution for that.

But I would go a little bit further: is it a real problem? I mean, even being a bug, it does not disrupts the basic behaviour of the sequences: that each successive call to nextval should return a value higher than the previous call. If your application has some problem with it, I would seriously recommend to review your application, as the sequence value skipping can also happen in normal situations, like when calling nextval inside a transaction which is finally rolled back: sequences are not transactional, so thatthat would skip one or more values.

Regards,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51) 954183248
Website: www.ocs.pe

----- Original Message -----
From: "Jonathan Eastgate" <jonathan(dot)eastgate(at)simpro(dot)co>
To: "PostgreSql-general" <pgsql-general(at)postgresql(dot)org>
Sent: Thursday, 20 October, 2016 03:10:53
Subject: Re: [GENERAL] Sequences / Replication

And further to my last post - another post in the forums related to this:

https://devon.so/2015/02/06/as-tale-of-sequences-and-postgresql-replication-9/

Thanks.

*Jonathan J. Eastgate*
Chief Technology Officer | simPRO Software Group
Ph: 1300 139 467 +61 7 3147 8777

<http://simprogroup.com/au/email-redirect>

Keep up to date with simPRO at: http://simprogroup.com/blog
The contents of this email are subject to our email disclaimer
<http://simprogroup.com/au/legal/email-confidentiality-notice>.

On Thu, Oct 20, 2016 at 6:03 PM, Jonathan Eastgate <
jonathan(dot)eastgate(at)simpro(dot)co> wrote:

> Hi everyone.
>
> We're seeing some odd behaviour from a PostgreSQL group - one running as
> primary and the other as a hot slave using streaming replication.
>
> When a failover event occurs and we switch to the hot slave as primary
> sequences in tables jump by 33 - so where the last number allocated in the
> sequence was 100 prior to failover once adding the next entry the sequence
> will produce the number 133.
>
> https://stackoverflow.com/questions/38450394/postgresql-
> sequence-jump-30-or-33-number-with-cache-equals-1
>
> I've found the following post in the forums - but any advice on how to
> resolve or counter this would be appreciated.
>
> Thanks in advance.
>
>
> *Jonathan J. Eastgate*
> Chief Technology Officer | simPRO Software Group
> Ph: 1300 139 467 +61 7 3147 8777
>
> <http://simprogroup.com/au/email-redirect>
>
> Keep up to date with simPRO at: http://simprogroup.com/blog
> The contents of this email are subject to our email disclaimer
> <http://simprogroup.com/au/legal/email-confidentiality-notice>.
>
>

--
--

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Francisco Olarte 2016-10-20 14:24:26 Re: Strange? BETWEEN behaviour.
Previous Message Tom Lane 2016-10-20 14:18:35 Re: make PostgreSQL with TCLSH: No rule to make target