I find this code pretty unreadable, but possibly lines 315 and 316
should be manipulating newpage->buffer instead of buffer?
You are right, I'll commit changes some later with a lot of additional work..
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
I wrote:
> I'm seeing some problems on Mac OS X, too. The tsearch regression test
> crashed ... which we may not care about much since tsearch is presumably
> going away ... but after that, the postmaster failed to restart:
I tried it again to check that it was reproducible. The tsearch test
cra
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> FYI: we now have at least 4 machines(otter,kingfisher,lionfish,corgi) on
> the buildfarm crashing during testing of GIST-related things in contrib.
I'm seeing some problems on Mac OS X, too. The tsearch regression test
crashed ... which we may no
Oleg Bartunov wrote:
> On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote:
>
>> Teodor Sigaev wrote:
>>
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog record
On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote:
Teodor Sigaev wrote:
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the cleanup step
has everything
Teodor Sigaev wrote:
>> btree manages to avoid calling the index support functions during WAL
>> restore --- can't you do the same? Perhaps you need to be including
>> more information in the initial xlog records, so that the cleanup step
>> has everything it needs. Or resort to brute-force searc
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Rather than eating up the extra flag bit, though, would it be possible
>> to change the tuple to appear to contain a NULL?
> We would like to preserve NULL as non-special value because we hope to add
> support of NULLs to GiST, although it's of low pri
This seems like a good answer --- if you fix up such things during
vacuum then the performance issue won't last too long.
Rather than eating up the extra flag bit, though, would it be possible
to change the tuple to appear to contain a NULL? AFAIK, GiST can't have
a NULL (at least not in the fi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> ... Which ways I see:
> 5 There is one unused bit in IndexTupleData. GiST code can use it as
> mark that this tuple contains incorrect union key. In this case, GiST
> search algorithm should keep it mind that such tuple has incorrect
> value and always sh
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the cleanup step
has everything it needs. Or resort to brute-force search (which is more
or less what bt
Oleg Bartunov writes:
> There is a problem with gist_xlog_cleanup function - we have no
> information about user defined functions and indices, because postmaster
> doesn't started yet and system catalog isn't available. For btree it's not
> necessary, but for GiST we certainly need them.
btree m
There is a problem with gist_xlog_cleanup function - we have no
information about user defined functions and indices, because postmaster
doesn't started yet and system catalog isn't available. For btree it's not
necessary, but for GiST we certainly need them. Is't possible to add
additional hook a
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Ok, I already realized WAL in GiST and tested with online backup. It works.
> Now I need test it on recovery after crash (power loss etc) and there is a
> problem in GiST with incompleted inserts, I hope, I resolved it, but this
> problem, I think, has
Ok, I already realized WAL in GiST and tested with online backup. It works.
Now I need test it on recovery after crash (power loss etc) and there is a
problem in GiST with incompleted inserts, I hope, I resolved it, but this
problem, I think, has the same nature as incompleted splits in btree co
14 matches
Mail list logo
