Re: Sequences / Replication - Mailing list pgsql-general
From | Alvaro Aguayo Garcia-Rada |
---|---|
Subject | Re: Sequences / Replication |
Date | |
Msg-id | 1305285516.324703.1476973165273.JavaMail.zimbra@opensysperu.com Whole thread Raw |
In response to | Re: Sequences / Replication (Jonathan Eastgate <jonathan.eastgate@simpro.co>) |
List | 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 behaviourof the sequences: that each successive call to nextval should return a value higher than the previous call. If yourapplication has some problem with it, I would seriously recommend to review your application, as the sequence value skippingcan 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.eastgate@simpro.co> To: "PostgreSql-general" <pgsql-general@postgresql.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.eastgate@simpro.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>. > > -- --
pgsql-general by date: