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

Re: [NOVICE] Last ID Problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,John Hansen <john(at)geeknet(dot)com(dot)au>, Michael Fuhr <mike(at)fuhr(dot)org>,Mitch Pirtle <mitch(dot)pirtle(at)gmail(dot)com>,Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>,operationsengineer1(at)yahoo(dot)com, pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] Last ID Problem
Date: 2005-02-01 22:50:26
Message-ID: 20733.1107298226@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-novice
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Tue, 2005-02-01 at 11:24 -0300, Alvaro Herrera wrote:
>> How about the TID?

> That wouldn't be sufficiently stable for use by client applications, I
> believe: a concurrent VACUUM FULL could mean your TID no longer points
> at what you think it does.

It'd be safe enough within the same transaction, since VACUUM can't kill
a tuple inserted by an open transaction; nor could VACUUM FULL touch the
table at all, since you'll be holding at least a writer's lock on the
table.

But this is all moot since INSERT/UPDATE RETURNING is really the way to
go, on grounds of functionality, speed, and not breaking backward
compatibility for existing client code.

			regards, tom lane

In response to

Responses

pgsql-novice by date

Next:From: Neil ConwayDate: 2005-02-01 23:08:27
Subject: Re: [NOVICE] Last ID Problem
Previous:From: Neil ConwayDate: 2005-02-01 22:44:47
Subject: Re: [NOVICE] Last ID Problem

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-02-01 23:08:27
Subject: Re: [NOVICE] Last ID Problem
Previous:From: Neil ConwayDate: 2005-02-01 22:44:47
Subject: Re: [NOVICE] Last ID Problem

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