RE: Exploring sequences (sequence context within a transaction)

From: Nicolas Huillard <nhuillard(at)ghs(dot)fr>
To: "'NetBeans'" <erik(at)cariboulake(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: RE: Exploring sequences (sequence context within a transaction)
Date: 2001-06-12 18:35:44
Message-ID: 01C0F37F.417A3CA0.nhuillard@ghs.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

curval retreives the current value of the sequence FOR THE CURRENT CLIENT.
There is this no concurrency problem : you can call curval on client 1
afeter having generated many values from the sequence, curval will always
return the same value for the same client.

NH

> -----Message d'origine-----
> De: NetBeans [SMTP:erik(at)cariboulake(dot)com]
> Date: mardi 5 juin 2001 09:21
> À: pgsql-general(at)postgresql(dot)org
> Objet: [GENERAL] Exploring sequences (sequence context within a
transaction)
>
> I searched through mailing list archives but was unable to find full
> coverage of this question -- my apologies if this is a reposted question.
>
> As in the FAQ, I am trying to retrieve the value of a sequence value from
a
> newly inserted row. So, first I call something like:
>
> insert into foobar (foo, bar) values (nextval('foobar_foo_seq'),
> 'whatever');
>
> Then, I want to retrieve the value that generated from the sequence and
> inserted into the table, so I use a call to currval:
>
> insert into foobar_rel_table(foo_fk, baz) values
> (currval('foobar_foo_seq', 'something else');
>
> This is (one of the methods that is) prescribed in the FAQ. However, I'm
> concerned that another transaction attempting to insert into the same
table
> might make a call to nextval('foobar_foo_seq') between the two operations
> above. This would mean that my second statement would use the wrong
value
> from the sequence.
> I've tested this scenario with different transaction isolation levels,
and
> it appears that any state changes to sequences become immediately visible
to
> other transactions (obviously, a read-commited type strategy wouldn't
work,
> however, serializing access to sequences, or explicit locking would solve
> this problem).
>
> Has anyone else come across this problem, and is there a workaround? If
> not, are there any alternate suggestions for generating a PK on insert
and
> immediately retrieving it that is free from concurrency issues?
>
> Any help would be appreciated. Thanks! -- Erik
>
> --
> Erik Pearson
> erik(at)cariboulake(dot)com
> http://www.cariboulake.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

Browse pgsql-general by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2001-06-12 18:36:04 Re: Re: New 7.1.2 RPMS -- 7.1.2-2.PGDG
Previous Message Jan Wieck 2001-06-12 18:34:14 Re: Slow DROPing Table