On Sat, 2010-03-27 at 22:39 +, Greg Stark wrote:
On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
If we're pruning an index entry to a heap tuple that has been HOT
pruned wouldn't the HOT pruning record have
On Fri, 2010-03-26 at 16:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote:
When replaying the deletion record, the standby could look at all the
heap tuples whose index pointers are being removed, to see which
On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
It appears that in practice many of the index items point to heap items
that are LP_DEAD. So for the purposes of accessing a heap tuple's xmin,
then we're both right. To the current purpose the tuple has been
removed,
On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
It appears that in practice many of the index items point to heap items
that are LP_DEAD. So for the purposes of accessing a heap tuple's xmin,
then we're both
On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
If we're pruning an index entry to a heap tuple that has been HOT
pruned wouldn't the HOT pruning record have already conflicted with
any queries that could see
On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote:
When replaying the deletion record, the standby could look at all the
heap tuples whose index pointers are being removed, to see which one
was newest.
Long after coding this, I now realise this really is a dumb-ass idea.
There is
Simon Riggs si...@2ndquadrant.com writes:
On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote:
When replaying the deletion record, the standby could look at all the
heap tuples whose index pointers are being removed, to see which one
was newest.
Long after coding this, I now realise
On Sun, 2010-01-31 at 16:53 -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
IIRC it was Greg Stark who suggested last time this was discussed that
we could calculate the exact value for latestRemovedXid in the standby.
When replaying the deletion
Simon Riggs wrote:
XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would
be calculated by inspection of heap tuples.
You might still want to keep the conservative latestRemovedXid value in
the WAL record to avoid the extra work when latestRemovedXid alone allows.
--
Heikki
On Tue, 2010-03-09 at 11:20 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would
be calculated by inspection of heap tuples.
You might still want to keep the conservative latestRemovedXid value in
the WAL record to
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-01-29 at 14:04 -0500, Tom Lane wrote:
WTF? Simon, this seems to be getting way way beyond anything the
community has agreed to. Particularly, inventing GUCs is not something
to be doing without consensus.
If you or anybody else would
On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote:
The commit is a one line change, with parameter to control it, discussed
by Heikki and myself in December 2008. I stand by the accuracy of the
change; the parameter is really to ensure we can test during beta.
Well, I was waiting to see
Simon Riggs wrote:
On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote:
The commit is a one line change, with parameter to control it, discussed
by Heikki and myself in December 2008. I stand by the accuracy of the
change; the parameter is really to ensure we can test during beta.
Well, I was
On Sun, 2010-01-31 at 20:48 +0100, Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote:
The commit is a one line change, with parameter to control it, discussed
by Heikki and myself in December 2008. I stand by the accuracy of the
change;
Simon Riggs si...@2ndquadrant.com writes:
At the moment a btree delete record will cancel every request
1. no matter how long they have been running
2. no matter if they haven't accessed the index being cleaned (they
might later, is the thinking...)
That seems seriously horrid. What is the
On Sun, 2010-01-31 at 15:41 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
At the moment a btree delete record will cancel every request
1. no matter how long they have been running
2. no matter if they haven't accessed the index being cleaned (they
might later, is the
Simon Riggs wrote:
On Sun, 2010-01-31 at 20:48 +0100, Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote:
The commit is a one line change, with parameter to control it, discussed
by Heikki and myself in December 2008. I stand by the accuracy of
On Sun, 2010-01-31 at 22:05 +0100, Stefan Kaltenbrunner wrote:
hmm makes sense from the HS side - but I think to make a case for a GUC
it would help a lot to see actual numbers(as in benchmarks) showing how
much of a hit it is to the master.
Agreed, though my approach to benchmarking was to
Simon Riggs wrote:
On Sun, 2010-01-31 at 22:05 +0100, Stefan Kaltenbrunner wrote:
hmm makes sense from the HS side - but I think to make a case for a GUC
it would help a lot to see actual numbers(as in benchmarks) showing how
much of a hit it is to the master.
Agreed, though my approach
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
IIRC it was Greg Stark who suggested last time this was discussed that
we could calculate the exact value for latestRemovedXid in the standby.
When replaying the deletion record, the standby could look at all the
heap tuples whose
On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote:
IIRC it was Greg Stark who suggested last time this was discussed that
we could calculate the exact value for latestRemovedXid in the
standby. When replaying the deletion record, the standby could look at
all the heap tuples whose
Simon Riggs si...@2ndquadrant.com writes:
Should I revoke this change?
Please. We can always put it back later if nothing better gets
implemented.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, 2010-01-31 at 17:10 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Should I revoke this change?
Please.
Will do, in morning.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Fri, 2010-01-29 at 14:04 -0500, Tom Lane wrote:
sri...@postgresql.org (Simon Riggs) writes:
Log Message:
---
Augment WAL records for btree delete with GetOldestXmin() to reduce
false positives during Hot Standby conflict processing. Simple
patch to enhance conflict
24 matches
Mail list logo
