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
