Thread: Command counter increment vs updating an active snapshot

Command counter increment vs updating an active snapshot

From
Ozgun Erdogan
Date:
Hi all (re-posting from pgsql-general),

I'm looking into Postgres' internals, and had two quick questions that
relate to each other.

(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?

(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.

https://github.com/postgres/postgres/commit/c0b00760365c74308e9e0719c993eadfbcd090c2#diff-6

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?

Thanks,

Ozgun.


Re: Command counter increment vs updating an active snapshot

From
Tom Lane
Date:
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