One more thing came to my mind: WAL records done by the GiST before patch will corrupt GiST after patch if replayed. Is it a problem? May be it's prevented on some higher level?
Best regards, Andrey Borodin, Octonica & Ural Federal University. 2016-07-06 22:11 GMT+05:00 Andrew Borodin <boro...@octonica.com>: > Here is a new patch. Updates: > 1. Uses MAXALIGN to allocate space on page > 2. Uses ItemIdSetNormal in case when ItemId was not normal for some > reasons before call > 3. Improved comments and var names > > Best regards, Andrey Borodin, Octonica & Ural Federal University. > > 2016-07-05 17:54 GMT+05:00 Andrew Borodin <boro...@octonica.com>: >> 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 <boro...@octonica.com>: >>> 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 <alvhe...@2ndquadrant.com>: >>>> 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 http://www.2ndQuadrant.com/ >>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
