Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE

Поиск
Список
Период
Сортировка
От Bernd Helmle
Тема Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE
Дата
Msg-id FF3CF50F040B5D1AE1381AB1@localhost
обсуждение исходный текст
Ответ на Re: [GENERAL] Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs

--On 4. November 2014 17:18:14 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yeah, and I think that it's entirely reasonable for rewriting ALTER TABLEs
> to update the xmin of the rewritten tuples; after all, the output data
> could be arbitrarily different from what the previous transactions put
> into the table.  But that is not the question here.  If the COPY blocks
> until the ALTER completes --- as it must --- why is its execution snapshot
> not taken *after* the lock is acquired?

COPY waits in DoCopy() but its snapshot gets acquired in PortalRunUtility()
earlier. SELECT has it's lock already during transform/analyse phase and
its snapshot is taken much later.  Looks like we need something that
analyses a utility statement to get its lock before executing.

--
Thanks

    Bernd


В списке pgsql-bugs по дате отправления:

Предыдущее
От: drickner@indy.rr.com
Дата:
Сообщение: BUG #11872: row height is not quite tall eneough
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ltree::text not immutable?