On 12/17/2013 04:55 AM, Jim Nasby wrote:
On 11/9/13, 10:02 AM, Heikki Linnakangas wrote:
3. Another approach would be to get rid of the can't delete
rightmost child limitation. We currently have that limitation
because it ensures that we never need to change the high-key of a
page. If we delete
On Sat, Jan 18, 2014 at 11:45 AM, Kevin Grittner kgri...@ymail.com wrote:
Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's a patch implementing this scheme.
I thought I'd weigh in here too, since this is closely tied to the
page split patch, which is dependent on this patch.
The
Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's a patch implementing this scheme.
This patch fixes a race condition bug in btree entry deletion. The
bug seems to rarely be encountered in practice; or at least it is
generally not recognized as the cause of index corruption when
that
On Sat, Dec 21, 2013 at 5:50 AM, Peter Eisentraut pete...@gmx.net wrote:
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th, if it is not resolved before then.
Uh, it's already in the
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th, if it is not resolved before then.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's a patch implementing this scheme.
I've read through the papers on the btree technique, read the
thread, and have been reviewing the patch. It will take me another
day or two to complete a close review and testing, but I wanted to
give
On 11/9/13, 10:02 AM, Heikki Linnakangas wrote:
3. Another approach would be to get rid of the can't delete rightmost child
limitation. We currently have that limitation because it ensures that we never need to
change the high-key of a page. If we delete a page that is the rightmost child of
On 12/17/2013 03:57 AM, Kevin Grittner wrote:
I agree with others that this patch is not suitable for
back-patching. I wonder whether some other solution might be worth
back-patching, since it is clearly a bug. The never delete
internal pages might be safe enough to consider. It would lead to
On 11/13/13, 11:04 AM, Heikki Linnakangas wrote:
Here's a patch implementing this scheme.
Compiler warnings:
nbtpage.c: In function ‘_bt_pagedel’:
nbtpage.c:1695:24: warning: ‘metad’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
nbtpage.c:1414:18: note: ‘metad’ was
On Mon, Nov 11, 2013 at 3:03 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10.11.2013 01:47, Robert Haas wrote:
I think we've tried pretty hard to avoid algorithms where the maximum
number of lwlocks that must be held at one time is not a constant, and
I think we're in for a bad
On 10.11.2013 01:47, Robert Haas wrote:
I think we've tried pretty hard to avoid algorithms where the maximum
number of lwlocks that must be held at one time is not a constant, and
I think we're in for a bad time of it if we start to deviate from that
principal. I'm not sure what to do about
The B-tree page deletion algorithm has a race condition. We don't allow
a page to be deleted if it's the rightmost child of its parent, but that
situation can change after we check for it.
Problem
---
We check that the page to be deleted is not the rightmost child of its
parent, and then
Heikki Linnakangas hlinnakan...@vmware.com writes:
2. The second-simplest solution I see is to keep locked the whole chain
of pages that will be deleted, and delete all of them as one atomic
WAL-logged operation. Ie. the leaf page, and all the parent pages above
it that will become
On 09.11.2013 18:24, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
2. The second-simplest solution I see is to keep locked the whole chain
of pages that will be deleted, and delete all of them as one atomic
WAL-logged operation. Ie. the leaf page, and all the parent pages
On 09.11.2013 18:49, Heikki Linnakangas wrote:
We could just punt if more than X pages would need to be changed. That
would mean that we never delete pages at the top (h - X) levels of the
tree. In practice that should be fine if X is high enough.
As a data point, GIN list page deletion holds 16
On 09.11.2013 19:18, Heikki Linnakangas wrote:
On 09.11.2013 18:49, Heikki Linnakangas wrote:
We could just punt if more than X pages would need to be changed. That
would mean that we never delete pages at the top (h - X) levels of the
tree. In practice that should be fine if X is high enough.
On Sat, Nov 9, 2013 at 12:40 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 09.11.2013 19:18, Heikki Linnakangas wrote:
On 09.11.2013 18:49, Heikki Linnakangas wrote:
We could just punt if more than X pages would need to be changed. That
would mean that we never delete pages at the
17 matches
Mail list logo
