From: | "Willy-Bas Loos" <willybas(at)gmail(dot)com> |
---|---|
To: | Chris <dmagick(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: using DROP in a transaction |
Date: | 2008-02-15 08:49:22 |
Message-ID: | 1dd6057e0802150049u7c4e951ate3e080af8ff7d316@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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/
>
From | Date | Subject | |
---|---|---|---|
Next Message | Balázs Klein | 2008-02-15 08:52:03 | Re: dynamic crosstab |
Previous Message | Dave Page | 2008-02-15 08:33:18 | Re: performance issues on windows with 8.3.0? |