Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id BC5F46334D8 for ; Mon, 3 May 2010 10:33:30 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 54103-05 for ; Mon, 3 May 2010 13:33:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 783DE63326A for ; Mon, 3 May 2010 10:33:23 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o43DXLjS014003; Mon, 3 May 2010 09:33:21 -0400 (EDT) To: Andreas Gaab cc: pgsql-sql mailing list , =?iso-8859-1?Q?Hans_Joachim_M=FCnzer?= Subject: Re: WAL-files restore and nextval('PK') In-reply-to: <48DA836F3865C54B8FBF424A3B775AF6010D455863@Exchange-Server> References: <48DA836F3865C54B8FBF424A3B775AF6010D455863@Exchange-Server> Comments: In-reply-to Andreas Gaab message dated "Mon, 03 May 2010 13:16:31 +0200" Date: Mon, 03 May 2010 09:33:21 -0400 Message-ID: <14002.1272893601@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.879 tagged_above=-5 required=5 tests=AWL=0.031, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201005/7 X-Sequence-Number: 34055 Andreas Gaab 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