Skip site navigation (1) Skip section navigation (2)

Re: Last ID Problem

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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/

In response to

Responses

pgsql-novice by date

Next:From: Tom LaneDate: 2005-02-01 07:04:45
Subject: Re: [NOVICE] Last ID Problem
Previous:From: Tom LaneDate: 2005-02-01 05:56:20
Subject: Re: Last ID Problem

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-01 07:04:45
Subject: Re: [NOVICE] Last ID Problem
Previous:From: Tom LaneDate: 2005-02-01 06:28:01
Subject: Re: patch for temporary view from TODO list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group