Re: Command counter increment vs updating an active snapshot

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Command counter increment vs updating an active snapshot
Дата
Msg-id 666.1334365908@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Command counter increment vs updating an active snapshot  (Ozgun Erdogan <ozgune@gmail.com>)
Список pgsql-hackers
Ozgun Erdogan <ozgune@gmail.com> writes:
> (1) What's the difference between advancing the command counter and
> updating an active snapshot? For example, I see that DefineRelation()
> increments the command counter, but explain.c / copy.c explicitly
> calls UpdateActiveSnapshotCommandId(). Is that because the latter call
> intends to make its changes visible to other concurrent processes?

No, that's all local.  CommandCounterIncrement automatically propagates
the new command counter into a couple of "standard" snapshots that are
meant to be always up-to-date, but if you want a stacked ActiveSnapshot
to follow suit you need to call UpdateActiveSnapshotCommandId.

> (2) The following change in pquery.c asserts that, if more than one
> utility statement exists in portal statements, they all have to be
> Notify statements.

That's because the only way that can happen is expansion of a rule, and
the only type of utility command allowed in rules is Notify.

> When I modify the code so that one statement in portal->stmts gets
> translated into four separate statements that all depend on each other
> (one planned, two utility, and another planned statement) and remove
> the assertion, all four statements still run fine.
> Looking into the code, I understand this isn't the expected behavior
> in terms of snapshot handling. In what scenarios can I expect our code
> to break?

[ shrug... ]  You expect an answer to that when you haven't shown us
the code?  But in general I'd be really wary of putting most utility
statements into a portal along with DML.  The kindest thing to be said
about that is that it's utterly untested.  Notify is pretty safe because
it doesn't affect the state of the database in any way that DML
statements would care about; this isn't the case for most others.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Patch: add timing of buffer I/O requests