On Thu, Oct 15, 2015 at 12:22 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > 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.
So, are you going to do that? >> - 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. I really, really hope that's not where we end up. Just shoot me now. >> - 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. Cool. > 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. I'm not clear whether you are asking for help with this, or ...? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers