Re: Command counter increment vs updating an active snapshot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Command counter increment vs updating an active snapshot
Date
Msg-id 666.1334365908@sss.pgh.pa.us
Whole thread Raw
In response to Command counter increment vs updating an active snapshot  (Ozgun Erdogan <ozgune@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
Next
From: Greg Stark
Date:
Subject: Re: Patch: add timing of buffer I/O requests