On 09.01.2011 07:05, Tom Lane wrote:
I just found out that the "benchmark" test script in
contrib/intarray/bench/ crashes HEAD in gistdoinsert() --- it looks like
it's trying to pop to a stack entry that isn't there.
Run it per the instructions in the intarray documentation:
$ createdb TEST
$ p
Heikki Linnakangas writes:
> On 21.12.2010 20:00, Heikki Linnakangas wrote:
>> One final version, with a bug fix wrt. root page split and some cleanup.
>> I'm planning to commit this before Christmas. It's a big patch, so
>> review would be much appreciated.
> Committed. Phew! Review & testing is
On 21.12.2010 20:00, Heikki Linnakangas wrote:
One final version, with a bug fix wrt. root page split and some cleanup.
I'm planning to commit this before Christmas. It's a big patch, so
review would be much appreciated.
Committed. Phew! Review & testing is of course still appreciated, given
h
On 13.12.2010 20:30, Tom Lane wrote:
Can we fix it so that each child page is updated, and its downlink
inserted, as a separate atomic action? That'd require each intermediate
state to be consistent and crash-safe, but I think you really need the
intermediate states to be consistent anyway becau
Heikki Linnakangas writes:
> On 13.12.2010 19:48, Tom Lane wrote:
>> Yeah. Wouldn't the original page-split record have been carrying full
>> page images already?
> Yes.
> BTW, the original split record doesn't run into the limit because it
> doesn't use the backup-block mechanism, it contains
On 13.12.2010 19:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 13.12.2010 19:19, Greg Stark wrote:
If it's only the backup blocks that matter couldn't you generate noop
WAL records with just the full page image in them. Once all those are
generated then generate the actual split operation
Heikki Linnakangas writes:
> On 13.12.2010 19:19, Greg Stark wrote:
>> If it's only the backup blocks that matter couldn't you generate noop
>> WAL records with just the full page image in them. Once all those are
>> generated then generate the actual split operation and since all the
>> pages hav
On 13.12.2010 19:19, Greg Stark wrote:
On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote:
I think you need to refactor the operation so that there's one WAL
record per child page, or something along that line. I concede this
might be diffcult :-(
If it's only the backup blocks that matter coul
On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote:
> I think you need to refactor the operation so that there's one WAL
> record per child page, or something along that line. I concede this
> might be diffcult :-(
If it's only the backup blocks that matter couldn't you generate noop
WAL records wi
Heikki Linnakangas writes:
> But that creates a new problem: There's a maximum of three backup blocks
> per WAL record, but a GiST page can be split into any number of child
> pages as one operation. You might run out of backup block slots.
> Attached is an updated patch, but that issue with li
On 13.12.2010 15:20, Heikki Linnakangas wrote:
On 13.12.2010 15:04, Robert Haas wrote:
On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas
wrote:
Attached is an updated patch, but that issue with limited number of
backup
blocks needs to be resolved. The straightforward way would be to
change t
On 13.12.2010 15:04, Robert Haas wrote:
On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas
wrote:
Attached is an updated patch, but that issue with limited number of backup
blocks needs to be resolved. The straightforward way would be to change the
WAL format to increase the limit.
Eh, is t
On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas
wrote:
> Attached is an updated patch, but that issue with limited number of backup
> blocks needs to be resolved. The straightforward way would be to change the
> WAL format to increase the limit.
Eh, is that going to bloat WAL?
--
Robert Haa
On Dec 3, 2010, at 4:54 PM, Heikki Linnakangas
wrote:
> Here's an updated patch.
How carefully have you perf-tested this?
> On closer look, supporting the invalid tuples in scans was trivial, so I kept
> that after all. So you can still query an index with invalid tuples. If an
> insert encou
On Wed, Dec 1, 2010 at 4:00 AM, Heikki Linnakangas
wrote:
> On 01.12.2010 04:10, Robert Haas wrote:
>>
>> On Tue, Nov 30, 2010 at 10:26 AM, Heikki Linnakangas
>> wrote:
Does the current code cope with the corruption?
>>>
>>> It's not corruption, but "intended degradation". Yes, the cur
On 01.12.2010 04:10, Robert Haas wrote:
On Tue, Nov 30, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
Does the current code cope with the corruption?
It's not corruption, but "intended degradation". Yes, the current code copes
with it, that's how GiST survives a crash. However, even with the c
On Tue, Nov 30, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
>> Does the current code cope with the corruption?
>
> It's not corruption, but "intended degradation". Yes, the current code copes
> with it, that's how GiST survives a crash. However, even with the current
> code, VACUUM will nag if it
Heikki Linnakangas wrote:
> > Does the current code cope with the corruption?
>
> It's not corruption, but "intended degradation". Yes, the current code
> copes with it, that's how GiST survives a crash. However, even with the
> current code, VACUUM will nag if it finds any invalid tuples with t
On 30.11.2010 16:23, Robert Haas wrote:
On Tue, Nov 30, 2010 at 5:02 AM, Heikki Linnakangas
wrote:
On 30.11.2010 11:55, Heikki Linnakangas wrote:
On 27.11.2010 21:31, Bruce Momjian wrote:
Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
p
On Tue, Nov 30, 2010 at 5:02 AM, Heikki Linnakangas
wrote:
> On 30.11.2010 11:55, Heikki Linnakangas wrote:
>>
>> On 27.11.2010 21:31, Bruce Momjian wrote:
>>>
>>> Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so thi
On 30.11.2010 11:55, Heikki Linnakangas wrote:
On 27.11.2010 21:31, Bruce Momjian wrote:
Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so this does not affect pg_upgrade. However, if there's
any "invalid" keys in the old index b
On 27.11.2010 21:31, Bruce Momjian wrote:
Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so this does not affect pg_upgrade. However, if there's
any "invalid" keys in the old index because of an incomplete insertion,
the new code
Heikki Linnakangas wrote:
> There's no on-disk format changes, except for the additional flag in the
> page headers, so this does not affect pg_upgrade. However, if there's
> any "invalid" keys in the old index because of an incomplete insertion,
> the new code will not understand that. So you s
On 17.11.2010 19:36, Teodor Sigaev wrote:
Hmm, will have to do some benchmarking on that. I'm using the Consistent
function when walking down to check if the downlink needs to be updated,
and assumed that it would be insignificant compared to the cost of
calling Penalty on all the keys on the pag
On 17.11.2010 19:46, Teodor Sigaev wrote:
I disagree with that opinion: if we crash between 2 and 3 then why will
somebody update parent before WAL replay? WAL replay process in this
case should complete child split by inserting "invalid" pointer and tree
become correct again, although it needs t
Sorry, I missed beginning of discussion on GiST, so I read it on the web mail
archive.
You wrote:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00939.php
[skip]
0. (the child page is locked)
1. The parent page is locked.
2. The child page is split. The original page becomes the left ha
Hmm, will have to do some benchmarking on that. I'm using the Consistent
function when walking down to check if the downlink needs to be updated,
and assumed that it would be insignificant compared to the cost of
calling Penalty on all the keys on the page.
Why consistent?! It's impossible - you d
On Tue, Nov 16, 2010 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh. So do the indexes just degrade over time until they eventually
>> need to be REINDEX'd?
>
> At some point you might reach a state where a reindex would be helpful.
> But the same is true of btrees. I don't think this
On 16.11.2010 21:20, Teodor Sigaev wrote:
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf page
Robert Haas writes:
> Oh. So do the indexes just degrade over time until they eventually
> need to be REINDEX'd?
At some point you might reach a state where a reindex would be helpful.
But the same is true of btrees. I don't think this is a serious
objection, at least not unless backed by evide
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf page, on each inner page you will
need to call
On Tue, Nov 16, 2010 at 1:50 PM, Heikki Linnakangas
wrote:
>> If we start to enlarge the bounding boxes on the higher levels of the
>> tree and then crash before inserting the key, is there any mechanism
>> for getting them back down to the minimal size?
>
> No. There's also no mechanism for trimm
On 16.11.2010 20:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
wrote:
BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
perhaps a bit surprising, and probably would be easy to add, but I left it
out for now as it's not strictly necessary.
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
wrote:
> BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
> perhaps a bit surprising, and probably would be easy to add, but I left it
> out for now as it's not strictly necessary.
Seems like it would be good to have
On 16.11.2010 20:01, Tom Lane wrote:
Heikki Linnakangas writes:
2. When a page is split, we mark the new left page with a flag to
indicate that the downlink for the page to the right hasn't been
inserted yet. When the downlink is inserted, the flag is cleared. Again
the purpose is to ensure tha
Heikki Linnakangas writes:
> There are two key changes to the insert algorithm:
> 1. When we walk down the tree searching for a suitable leaf page to
> insert the new tuple to, we update the nodes on the way down so that
> they are consistent with the new key we're inserting. The old GiST
> al
36 matches
Mail list logo
