| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "'Jonathan Eastgate *EXTERN*'" <jonathan(dot)eastgate(at)simpro(dot)co>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Sequences / Replication |
| Date: | 2016-10-21 10:17:42 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B5395F128@ntex2010a.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Jonathan Eastgate wrote:
> 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.
That is working as expected.
When nextval() is called, a number of sequence numbers are reserved (by default one,
you can set this with the CACHE clause of CREATE SEQUENCE). If the transaction is aborted,
these entries won't be used.
So if there were 30 inserting transactions when your server went down that got aborted,
that would explain the behaviour quite nicely.
This should not be a problem.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaisingkar, Piyush | 2016-10-21 12:25:54 | sending records from one function to other with dblink |
| Previous Message | wd | 2016-10-21 07:51:11 | Re: Postgres upgrade from 9.4.9 to 9.6 using pg_upgrade error |