Re: remaining open items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: remaining open items
Date
Msg-id 31310.1445090304@sss.pgh.pa.us
Whole thread Raw
In response to Re: remaining open items  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 16 October 2015 at 20:17, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> - 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.

> I share your pain, but the latter appears to be the only actionable
> proposal at present.

I had the idea that the test suite would consist of "run the standard
regression tests with a DDL deparsing hook installed, and see if it fails
anywhere".  This would not prove that the deparsing logic is right,
certainly, but it would at least catch errors of omission for any DDL
tested in the regression tests, which we could hope is pretty much
everything.

> Why do we need to fix DDL when pg_dump remains annoying in the same way?

It is not true that we have no test coverage for pg_dump: the pg_upgrade
test exercises pg_dump too.  The difficulty with pg_dump is that this
approach only tests dumping of objects that are left behind at the end of
the regression tests, and we get too many submissions from neatniks who
think that test cases ought to delete all the objects they create.  But
that is just a matter of needing to formulate test cases with this in
mind.

> Why do we need to fix it now? Surely this will break things in later
> releases, but not in 9.5, since we aren't ever going to add DDL to 9.5
> again.

This is a fair point.  We still need a test methodology here, but it's
not clear why it needs to be regarded as a 9.5 blocker.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow ssl_renegotiation_limit in PG 9.5
Next
From: Tom Lane
Date:
Subject: Re: Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”