Kevin Grittner wrote:
> If you run `make installcheck` against a cluster with
> default_transaction_isolation = 'repeatable read' you get one
> failure:
So there's some code that's specifically intended to handle this case:
/*
* If using transaction-snapshot mode, it would
be possible
* for another transaction to insert a tuple
that's not
* visible to our snapshot if we have already
acquired one,
* when in snapshot-isolation mode; therefore,
disallow this
* from running in such a transaction unless a
snapshot hasn't
* been acquired yet.
*
* This code is called by VACUUM and
* brin_summarize_new_values. Have the error
message mention
* the latter because VACUUM cannot run in a
transaction and
* thus cannot cause this issue.
*/
if (IsolationUsesXactSnapshot() &&
FirstSnapshotSet)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
errmsg("brin_summarize_new_values() cannot run in a transaction that has
already obtained a snapshot")));
However, this comment is full of it because a snapshot is obtained even
for VACUUM. So the fact that brin_summarize_new_values() is mentioned
as being in trouble is just a very minor issue: fixing that would just
be a matter of passing a flag down from the caller into
summarize_range() to indicate whether it's vacuum or the function. The
real problem is that VACUUM should be allowed to run without error.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
