Re: [HACKERS] Limit GIST_MAX_SPLIT_PAGES to XLR_MAX_BLOCK_ID

[Gurjeet Singh]

(adding Heikki, since that macro was touched by his commit 04e298b8)

Does my previous description of the problem make sense, or am I fretting
over something that's a non-issue.

Best regards,


On Sun, Sep 20, 2015 at 7:03 PM, Gurjeet Singh  wrote:

> Gin code respects the XLR_MAX_BLOCK_ID when
> calling XLogEnsureRecordSpace(). But it appears that the Gist code does not
> try to limit its block-id consumption to XLR_MAX_BLOCK_ID.
>
> The GIST_MAX_SPLIT_PAGES is hard-coded at 75, but XLogEnsureRecordSpace()
> would reject a request of more than 32 (XLR_MAX_BLOCK_ID).
>
> The attached patch redefines GIST_MAX_SPLIT_PAGES so that in case of a
> split, gistplacetopage() now throws an error when the block-ids needed
> exceed 32.
>
> I have used Min(75, XLR_MAX_BLOCK_ID) as the macro expansion, but I
> believe it can be set to plain XLR_MAX_BLOCK_ID.
>
>
> --
> Gurjeet Singh http://gurjeet.singh.im/
>



-- 
Gurjeet Singh http://gurjeet.singh.im/

[HACKERS] Limit GIST_MAX_SPLIT_PAGES to XLR_MAX_BLOCK_ID

[Gurjeet Singh]

Gin code respects the XLR_MAX_BLOCK_ID when
calling XLogEnsureRecordSpace(). But it appears that the Gist code does not
try to limit its block-id consumption to XLR_MAX_BLOCK_ID.

The GIST_MAX_SPLIT_PAGES is hard-coded at 75, but XLogEnsureRecordSpace()
would reject a request of more than 32 (XLR_MAX_BLOCK_ID).

The attached patch redefines GIST_MAX_SPLIT_PAGES so that in case of a
split, gistplacetopage() now throws an error when the block-ids needed
exceed 32.

I have used Min(75, XLR_MAX_BLOCK_ID) as the macro expansion, but I believe
it can be set to plain XLR_MAX_BLOCK_ID.


-- 
Gurjeet Singh http://gurjeet.singh.im/


gist_limit_blockid_to_XLR_MAX_BLOCK_ID.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers