Re: remaining open items

On Thu, Oct 15, 2015 at 12:22 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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