Alvaro Herrera wrote:
> Here's the promised patch.
Pushed to master and 9.5. Thanks for reporting!
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Alvaro Herrera wrote:
> Thankfully I found
> another way to solve it, which is to forgo usage of MVCC here and
> instead use SnapshotAny. There's already a mode in
> IndexBuildHeapRangeScan that uses SnapshotAny, but it needs some tweaks
> to do what we need. I'm going to propose a patch along t
Robert Haas wrote:
> On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
> wrote:
> > I think the only way to close this hole is to have summarize_range()
> > sleep until all open snapshots are gone after inserting the placeholder
> > tuple and before acquiring the snapshot, similarly to how CREATE I
On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
wrote:
>> I think the real solution to this problem is to avoid use of
>> GetTransactionSnapshot(), and instead use GetLatestSnapshot(). As far
>> as I can see, that should completely close the hole. This requires
>> patching IndexBuildHeapRangeSca
Alvaro Herrera wrote:
> Untested patch attached.
That fixes the installcheck failure on my machine.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
> >> I think the real solution to this problem is to avoid use of
> >> GetTransactionSnapshot(), and instead use GetLatestSnapshot(). As far
> >> as I can see, that should completely close the hole. This requires
> >> patching IndexBuildHeapRangeS
Alvaro Herrera wrote:
>> I think the real solution to this problem is to avoid use of
>> GetTransactionSnapshot(), and instead use GetLatestSnapshot(). As far
>> as I can see, that should completely close the hole. This requires
>> patching IndexBuildHeapRangeScan() to allow for that.
>
> Actua
> I think the real solution to this problem is to avoid use of
> GetTransactionSnapshot(), and instead use GetLatestSnapshot(). As far
> as I can see, that should completely close the hole. This requires
> patching IndexBuildHeapRangeScan() to allow for that.
Actually I think there's another pro
Let me explain a bit more what's the mechanism at play.
When scanning a block range to summarize it, we use an MVCC snapshot.
Any tuples that are inserted by transactions that appear as in-progress
to that snapshot will not be seen by that range scan; therefore we need
another mechanism to include
On 31 July 2015 at 15:48, Kevin Grittner wrote:
>
> Reread the thread.
I stand corrected.
> The error is being hit on a VACUUM command
> (which is not, of course in any explicit transaction).
>
Seems like VACUUM only ever needs a read-committed snapshot. Whether it
takes a read-committed or
Simon Riggs wrote:
> On 30 July 2015 at 22:24, Tom Lane wrote:
>> Alvaro Herrera 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 shou
Alvaro Herrera wrote:
> 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 transact
On 30 July 2015 at 22:24, Tom Lane wrote:
> Alvaro Herrera 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 v
Alvaro Herrera 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 transacti
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.
It is po
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
Jeff Janes wrote:
> On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner wrote:
>> Kevin Grittner wrote:
>>
>>> If you run `make installcheck` against a cluster with
>>> default_transaction_isolation = 'repeatable read' you get one
>>> failure:
>>
>>> + ERROR: brin_summarize_new_values() cannot run i
On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner wrote:
> Kevin Grittner wrote:
>
> > If you run `make installcheck` against a cluster with
> > default_transaction_isolation = 'repeatable read' you get one
> > failure:
>
> > + ERROR: brin_summarize_new_values() cannot run in a transaction that
>
Kevin Grittner wrote:
> If you run `make installcheck` against a cluster with
> default_transaction_isolation = 'repeatable read' you get one
> failure:
> + ERROR: brin_summarize_new_values() cannot run in a transaction that has
> already obtained a snapshot
> This is using source at commit 9f
If you run `make installcheck` against a cluster with
default_transaction_isolation = 'repeatable read' you get one
failure:
*** /home/kgrittn/pg/master/src/test/regress/expected/brin.out 2015-07-21
10:21:58.798619111 -0500
--- /home/kgrittn/pg/master/src/test/regress/results/brin.out 2015-07-21
20 matches
Mail list logo
