Thread: Sequence Incrementing by 2 insted of 1
Our internal task database is doing something odd in that the sequence is incrementing by 2 instead of 1 and I can't findany reason why I have checked the sequence itself to see if it had somehow got set to increment by 2 but no. The table in question has a number of both beforeand after triggers that do various bits of business logic as well as some rewrite rules to track field changes. Using 8.3.0. Can anyone think of a reasonwhy? --
David, 28.04.2009 07:48: > Our internal task database is doing something odd in that the > sequence is incrementing by 2 instead of 1 and I can't find any > reason why I have checked the sequence itself to see if it had > somehow got set to increment by 2 but no. The table in question has a > number of both before and after triggers that do various bits of > business logic as well as some rewrite rules to track field changes. > Using 8.3.0. Can anyone think of a reason why? > My first guess would be rolled back transactions Thomas
In response to David : > Our internal task database is doing something odd in that the sequence is incrementing by 2 instead of 1 and I can't findany reason why I have checked the > sequence itself to see if it had somehow got set to increment by 2 but no. The table in question has a number of both beforeand after triggers that do > various bits of business logic as well as some rewrite rules to track field changes. Using 8.3.0. Can anyone think of areason why? Wild guess: there are an other call to nextval() in one of the triggers. But without the code it is hard to guess... Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
Looked for that can't find anything and there is no reason why someone would have added that. On Tue, Apr 28, 2009 at 08:24:46AM +0200, A. Kretschmer wrote: > In response to David : > > Our internal task database is doing something odd in that the sequence is incrementing by 2 instead of 1 and I can'tfind any reason why I have checked the > > sequence itself to see if it had somehow got set to increment by 2 but no. The table in question has a number of bothbefore and after triggers that do > > various bits of business logic as well as some rewrite rules to track field changes. Using 8.3.0. Can anyone think ofa reason why? > > Wild guess: there are an other call to nextval() in one of the triggers. > But without the code it is hard to guess... > > > Regards, Andreas > -- > Andreas Kretschmer > Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) > GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > --
On Tue, Apr 28, 2009 at 12:38 AM, David <david@vanlaatum.id.au> wrote:
> Looked for that can't find anything and there is no reason why someone would have added that.
Well, unless you've got some example code for us to look at, it's
kinda hard to tell you what's wrong.
Often, you see people do something like this:
insert into autoincrementingtable values (DEFAULT, 'a', 500);
select nextval('autoinctable_seq');
yada yada yada
or something like that. i.e. there's an implicit call to the nextval
with the insert, and another explicit one somewhere in your code.
Ok got permission to send the code I think I have got all the relevent bits.
On Tue, Apr 28, 2009 at 01:01:39AM -0600, Scott Marlowe wrote:
> On Tue, Apr 28, 2009 at 12:38 AM, David <david@vanlaatum.id.au> wrote:
> > Looked for that can't find anything and there is no reason why someone would have added that.
>
> Well, unless you've got some example code for us to look at, it's
> kinda hard to tell you what's wrong.
>
> Often, you see people do something like this:
>
> insert into autoincrementingtable values (DEFAULT, 'a', 500);
> select nextval('autoinctable_seq');
> yada yada yada
>
> or something like that. i.e. there's an implicit call to the nextval
> with the insert, and another explicit one somewhere in your code.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Attachment
David wrote: > the sequence is incrementing by 2 instead of 1 and I can't > find any reason why I have checked the > sequence itself to see if it had somehow got set to increment > by 2 but no. > The table in question has a number of both before and after triggers > that do various bits of business logic as well as some rewrite rules > to track field changes. > Using 8.3.0. Can anyone think of a reason why? I'd say rewrite rules are your prime suspect. Check out for example: http://archives.postgresql.org/pgsql-sql/2007-03/msg00334.php Cordialement, -- Daniel
Cool thanks that makes sense was hard to pin down because we didn't notice for a while. On Tue, Apr 28, 2009 at 09:31:26AM +0200, Daniel Verite wrote: > David wrote: > > >the sequence is incrementing by 2 instead of 1 and I can't > >find any reason why I have checked the > >sequence itself to see if it had somehow got set to increment > >by 2 but no. > >The table in question has a number of both before and after triggers > >that do various bits of business logic as well as some rewrite rules > >to track field changes. > >Using 8.3.0. Can anyone think of a reason why? > > I'd say rewrite rules are your prime suspect. > Check out for example: > http://archives.postgresql.org/pgsql-sql/2007-03/msg00334.php > > Cordialement, > -- > Daniel > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > --
On 2009-04-28, David <david@vanlaatum.id.au> wrote: > Our internal task database is doing something odd in that the sequence is incrementing by 2 instead of 1 and I can't findany reason why I have checked the > sequence itself to see if it had somehow got set to increment by 2 but no. The table in question has a number of both beforeand after triggers that do > various bits of business logic as well as some rewrite rules to track field changes. Using 8.3.0. Can anyone think of areason why? possibly a rule involves the the sequence, thus it's value is computed twice.
On 2009-04-28, David <david@vanlaatum.id.au> wrote:
> Ok got permission to send the code I think I have got all the relevent bits.
>
>CREATE TABLE currentcall (
> cadc_taskno integer DEFAULT nextval(('currentcall_cadc_taskno_seq'::text)::regclass) NOT NULL,
> coversight character varying(4),
...
>CREATE RULE currentcall_insert AS ON INSERT TO currentcall DO INSERT INTO
> taskchangelog (tasknum, newstatus, newtech, status, newpriority,
> newestcomplete, newclass, newnewtask) VALUES (new.cadc_taskno,
^^^^^^^^^^^^^^^
> new.cstatus, new.ctechalloc, new.ccustcomment, new.cfprior,
> new.cestcomplete, new.cjobclass, (new.cnewtask = 'Y'::bpchar));
if you're inserting DEFAULT into the cadc_taskno column (or not
explicitly setting that column) the re-writer will substitute
nextval(('currentcall_cadc_taskno_seq'::text)::regclass)
And that will be evaluated once for the insert and again for the rule.
this is documented somewhere.... I think