Re: remaining open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndQuadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remaining open items
Date: 2015-10-17 13:58:24
Message-ID: 31310.1445090304@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 16 October 2015 at 20:17, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-10-17 14:03:39 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”
Previous Message Tom Lane 2015-10-17 13:39:52 Re: Allow ssl_renegotiation_limit in PG 9.5