Re: Postgres 8.3 HOT and non-persistent xids

[ Pavan already answered most of this, but ... ]

"Mike C" <smith(dot)not(dot)western(at)gmail(dot)com> writes:
> And for non-persistent transaction ids, the documentation says that
> this is for read-only transactions. What defines a read-only
> transaction for this purpose?

A transaction that has not done anything that requires it to sign an
update with its transaction ID.

> Does postgres check to see if a SELECT
> includes e.g. a sequence change via nextval?

IIRC, nextval() doesn't involve marking anything with one's XID,
because it is not a rollback-able operation. But you are thinking
at quite the wrong level if you suppose that this behavior has anything
to do with "checking a SELECT for a writing operation". The way it
really works is that a backend generates a persistent XID for its
current transaction at the instant that some bit of code first demands
the transaction's XID. Typically this happens because you insert,
update, or delete some tuple, and the XID is needed to set xmin or xmax
of the tuple. There are some other cases, but they are covered by
definition, because there is no way to get the current XID except to ask
that code for it.

> If I mark the transaction
> as readonly using the PG JDBC driver, will that be sufficient?

If this means what I think it means, it's irrelevant. Materializing a
persistent XID is driven off what the transaction *actually* does,
not off whether it's declared to be read-only or not.

regards, tom lane