Re: brin index vacuum versus transaction snapshots

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: brin index vacuum versus transaction snapshots
Дата
Msg-id CANP8+jK3Dg16EX338zAErC2MPDf9CPMMLd1AqNeZqe1hYVyGcg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: brin index vacuum versus transaction snapshots  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: brin index vacuum versus transaction snapshots  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On 30 July 2015 at 22:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Kevin Grittner wrote:
>> If you run `make installcheck` against a cluster with
>> default_transaction_isolation = 'repeatable read' you get one
>> failure:

> I am tempted to say that we should just disallow to run vacuum on a
> table containing a brin index in a transaction-snapshot transaction.

Huh?  We don't allow vacuum inside a (user started) transaction now.
What new restriction are you proposing?

 Forgive me, but I believe there is a confusion here. Nobody is changing VACUUM.

The code comment mentioned as "full of it" by Kevin appears to be accurate and appropriate.

The code is called by VACUUM and brin_summarize_new_values(). It can't be VACUUM, as you say and as the comment already says, so it must be the function brin_summarize_new_values().

The test assumes that the default_transaction_isolation is read committed and so the test fails at other levels. If anything, it is the test that is at fault.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: 64-bit XIDs again
Следующее
От: Shay Rojansky
Дата:
Сообщение: Re: Encoding of early PG messages