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 <[EMAIL PROTECTED]> 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/ >
