Re: Command counter increment vs updating an active snapshot

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ozgun Erdogan <ozgune(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Command counter increment vs updating an active snapshot
Date: 2012-04-14 01:11:48
Message-ID: 666.1334365908@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ozgun Erdogan <ozgune(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2012-04-14 01:42:29 Re: Patch: add timing of buffer I/O requests
Previous Message Robert Haas 2012-04-13 22:53:48 Re: BUG #6572: The example of SPI_execute is bogus