Re: using DROP in a transaction

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(at)gmail(dot)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/
>