Here is a patch with updated WAL behavior.

I'm not certain about MAXALIGN for size of appended tuple. Currently
if anyone calls PageIndexTupleOverwrite() with unalligned tuple it
will ereport(ERROR).
I suspect that it should allign size instead.

Also I suspect that PageIndexTupleOverwrite() should make a call to
ItemIdSetNormal() to pretend it is generic function and not just a
private part of GiST.

Best regards, Andrey Borodin, Octonica & Ural Federal University.

2016-07-04 22:59 GMT+05:00 Andrew Borodin <>:
> Thank you, Alvaro.
> Yes, now I see. I'll update gistRedoPageUpdateRecord() to work
> accordingly with patched gistplacetopage().
> Also, i've noticed that PageAddItem uses MAXALIGN() macro to calculate
> tuple size. So, PageIndexTupleOverwrite should behave the same.
> About PageIndexDeleteNoCompact() in BRIN. I do not see why
> PageIndexDeleteNoCompact() is not a good solution instead of
> PageIndexTupleOverwrite? Will it mark tuple as unused until next
> PageAddItem will use it's place?
> Best regards, Andrey Borodin, Octonica & Ural Federal University.
> 2016-07-04 22:16 GMT+05:00 Alvaro Herrera <>:
>> Andrew Borodin wrote:
>>> Thank you, Amit.
>>> Currently, if WAL reconstruct page in another order it won't be a problem.
>> We require that replay of WAL leads to identical bytes than the
>> original.  Among other things, this enables use of a tool that verifies
>> that WAL is working correctly simply by comparing page images.  So
>> please fix it instead of just verifying that this works for GiST.
>> By the way, BRIN indexes have a need of this operation too.  The current
>> approach is to call PageIndexDeleteNoCompact followed by PageAddItem.
>> I suppose it would be beneficial to use your new routine there too.
>> --
>> Álvaro Herrera      
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment: PageIndexTupleOverwrite v3.patch
Description: Binary data

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to