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
On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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 those
Robert Haas wrote:
On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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,
Alvaro Herrera alvhe...@2ndquadrant.com 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
On 30 July 2015 at 22:24, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@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
Alvaro Herrera alvhe...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com wrote:
On 30 July 2015 at 22:24, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Kevin Grittner wrote:
If you run `make installcheck` against a cluster with
default_transaction_isolation = 'repeatable read' you get one
On 31 July 2015 at 15:48, Kevin Grittner kgri...@ymail.com 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
Kevin Grittner wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
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
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
Alvaro Herrera alvhe...@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
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
Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner kgri...@ymail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
If you run `make installcheck` against a cluster with
default_transaction_isolation = 'repeatable read' you get one
failure:
+ ERROR:
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
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
Kevin Grittner kgri...@ymail.com 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
On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner kgri...@ymail.com wrote:
Kevin Grittner kgri...@ymail.com 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
20 matches
Mail list logo
