Re: remaining open items

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