ah, of course.
the exclusive lock was preventing tty1 to read "test", and when the lock was gone, so was the table.
I get it. Thanks a lot.
But, what about the "ERROR: tuple concurrently updated" ? (in TTY3)
What should have happened, i guess, is "ERROR: table "test" does not exist, upon " drop table test; --4. ..."
Which tuple was concurrently updated? A pg_catalog entry that administers the table?
WBL
On Fri, Feb 15, 2008 at 5:10 AM, Chris <
dmagick@gmail.com> wrote:
> ==in TTY1==
> --11. expect result at last, value 2 only. (concurrent transaction
> 2 (in TTY3) completes after this, and will delete values 2 and 4
> (added after select was issued) upon commit)
> --11. true result: ERROR: relation <large nr> deleted while still in
> use
The table 'test' which tty1 was looking at (which was dropped in tty2)
doesn't exist any more.
Postgres doesn't look at the name, it looks at the id that is created
behind the scenes.
So in tty1, the id is 'x'.
Then you recreate the table in tty2 which gives it id 'y'.
So tty1 looking at id 'x' doesn't exist any more.
--
Postgresql & php tutorials
http://www.designmagick.com/