Re: using DROP in a transaction

Поиск
Список
Период
Сортировка
Искать
От
Willy-Bas Loos
Тема
Re: using DROP in a transaction
Дата
Msg-id
1dd6057e0802150049u7c4e951ate3e080af8ff7d316@mail.gmail.com
Ответ на
Список
Дерево обсуждения
using DROP in a transaction "Willy-Bas Loos" <willybas@gmail.com>
Re: using DROP in a transaction Tom Lane <tgl@sss.pgh.pa.us>
Re: using DROP in a transaction "Willy-Bas Loos" <willybas@gmail.com>
Re: using DROP in a transaction "Willy-Bas Loos" <willybas@gmail.com>
Re: using DROP in a transaction Chris <dmagick@gmail.com>
Re: using DROP in a transaction "Willy-Bas Loos" <willybas@gmail.com>
Re: using DROP in a transaction Chris <dmagick@gmail.com>
Re: using DROP in a transaction "Willy-Bas Loos" <willybas@gmail.com>
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/

В списке pgsql-general по дате отправления
От: Dave Page
Дата:
От: Balázs Klein
Дата:
Сообщение: Re: dynamic crosstab
FAQ