Re: brin index vacuum versus transaction snapshots

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: brin index vacuum versus transaction snapshots
Дата
Msg-id 20150722180357.GL5596@postgresql.org
обсуждение исходный текст
Ответ на brin index vacuum versus transaction snapshots  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
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
transactionto 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
snapshothasn'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
transactionand             * 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Volatility of pg_xact_commit_timestamp() and pg_last_committed_xact()