From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mitch Pirtle <mitch(dot)pirtle(at)gmail(dot)com>, operationsengineer1(at)yahoo(dot)com, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Last ID Problem |
Date: | 2005-02-01 06:50:27 |
Message-ID: | 20050201065027.GA53722@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-novice |
On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote:
>
> His point stands though: if you are accessing Postgres through some kind
> of connection-pooling software, currval() cannot be trusted across
> transaction boundaries, since the pool code might give your connection
> to someone else. In this situation the nextval-before-insert paradigm
> is the only way.
I don't disagree with that; if the thread mentioned connection
pooling then I must have overlooked it.
> (But in most of the applications I can think of, your uses of currval
> subsequent to an INSERT ought to be in the same transaction as the
> insert, so are perfectly safe. If your connection pooler takes control
> away from you within a transaction block, you need a less broken
> pooler...)
That's the common situation I was talking about: doing an INSERT
and immediately calling currval(), presumably in the same transaction.
I should have been more clear about that and warned what could
happen in other situations. Thanks.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-02-01 07:04:45 | Re: [NOVICE] Last ID Problem |
Previous Message | Tom Lane | 2005-02-01 06:28:01 | Re: patch for temporary view from TODO list |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-02-01 07:04:45 | Re: [NOVICE] Last ID Problem |
Previous Message | Tom Lane | 2005-02-01 05:56:20 | Re: Last ID Problem |