On Sat, Jan 18, 2014 at 11:45 AM, Kevin Grittner wrote:
> Heikki Linnakangas 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 basic approach is sound. The papers on
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 delet
Heikki Linnakangas 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 occurs.
The basic approa
On Sat, Dec 21, 2013 at 5:50 AM, Peter Eisentraut 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 January commitfest.
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 subscripti
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 t
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
Heikki Linnakangas 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 preliminary results, and
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 declare
On Mon, Nov 11, 2013 at 3:03 AM, Heikki Linnakangas
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 time of it if we sta
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 thi
On Sat, Nov 9, 2013 at 12:40 PM, Heikki Linnakangas
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 top (h - X) leve
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.
A
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 18:24, Tom Lane wrote:
Heikki Linnakangas 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
Heikki Linnakangas 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 half-dead, and the parent of
16 matches
Mail list logo
