From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Gaab <A(dot)Gaab(at)scanlab(dot)de> |
Cc: | pgsql-sql mailing list <pgsql-sql(at)postgresql(dot)org>, Hans Joachim Münzer <H(dot)Muenzer(at)scanlab(dot)de> |
Subject: | Re: WAL-files restore and nextval('PK') |
Date: | 2010-05-03 13:33:21 |
Message-ID: | 14002.1272893601@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Andreas Gaab <A(dot)Gaab(at)scanlab(dot)de> writes:
> after an WAL-restore of our Postgres DB, we observe seemingly wrong values of our sequences.
> We have two postgres server (8.4) with pgpool in replication mode.
> Recently we tested our restore procedure and played our WAL-files into the second server after an old file-system backup was restored.
> Accidently, we aborted the starting server and had to restart it and therefore started WAL-replay again.
> Now we observe, that the newly restored server has higher values in his sequences as the other server.
It's normal for sequence counters to be a few counts higher after a
crash-and-restart than they would have been if no crash had occurred.
This is an intentional design tradeoff to minimize the WAL overhead
associated with assigning a sequence value. If you find it intolerable
for what you're doing, I believe you can prevent it by adjusting the
sequence parameters to prevent any "caching" of values.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-05-03 15:28:47 | Re: WAL-files restore and nextval('PK') |
Previous Message | Andreas Gaab | 2010-05-03 11:16:31 | WAL-files restore and nextval('PK') |