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
|
| Список | 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: