Robert Haas wrote: > - Oversize item computation needs more testing (c.f. ereport(ERROR) > calls in brin_getinsertbuffer). This is pretty vague, and there's no > thread linked. If there's a stability issue here, presumably it falls > to Alvaro to fix it. But I don't know who added this item or what > really needs to be done.
I added it, sorry it's vague. It means that I should test with values of increasing size and see if all the errors are correctly covered, i.e. we don't get a PANIC because of a failure in PageAddItem. > - DDL deparsing testing module should have detected that transforms > were not supported, but it failed to notice that. There's no thread > linked to this one either, but the description of the issue seems > clear enough. Alvaro, any chance that you can, as the comment says, > whack it until it does? I've been looking at this on and off, without anything useful to share yet. One approach that was suggested (which I don't like much, but I admit is a possible approach) is that we just need to remain vigilant that all features that add DDL properly test the event trigger side of it, just as we remain vigilant about pg_dump support without having any explicit test that it works. > - Strange behavior on track_commit_timestamp. As I've said on the > thread, I think that the idea that the redo routines care about the > value of the GUC at the time redo is performed (rather than at the > time redo is generated), is broken. Fujii's latest post provides some > examples of how this creates weird results. I really think this > should be changed. We have discussed this; Petr is going to post a patch shortly. The other item on me is the documentation patch by Emre Hasegeli for usage of the inclusion opclass framework in BRIN. I think it needs some slight revision by some native English speaker and I'm not completely in love with the proposed third column in the table it adds, but otherwise is factually correct as far as I can tell. -- Á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
