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

Re: [NOVICE] Last ID Problem

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:08:27
Message-ID: 1107299307.12465.111.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-novice
On Tue, 2005-02-01 at 17:50 -0500, Tom Lane wrote:
> 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.

True, but it still seems rather fragile -- it would be quite easy for
people to get this wrong and not realize it (and then wonder why their
application is silently corrupting data at odd times). Also, it might
constrain out ability to improve how we garbage collect expired tuples
in the future, although that's less of a concern.

> 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.

Agreed. Also, I believe we could do this without needing a protocol
version bump.


In response to

pgsql-novice by date

Next:From: John HansenDate: 2005-02-02 01:36:52
Subject: Re: [NOVICE] Last ID Problem
Previous:From: Tom LaneDate: 2005-02-01 22:50:26
Subject: Re: [NOVICE] Last ID Problem

pgsql-hackers by date

Next:From: Mike RylanderDate: 2005-02-02 01:12:04
Subject: Re: FunctionCallN improvement.
Previous:From: Tom LaneDate: 2005-02-01 22:50:26
Subject: Re: [NOVICE] Last ID Problem

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