From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: some pg_dump query code simplification |
Date: | 2018-08-28 22:10:29 |
Message-ID: | 20180828221029.GP3326@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I wonder- what if we had an option to pg_dump to explicitly tell it what
> > the server's version is and then have TAP tests to run with different
> > versions?
>
> Uh ... telling it what the version is doesn't make that true, so I'd
> have no confidence in a test^H^H^H^Hkluge done that way. The way
> to test is to point it at an *actual* back-branch server.
I certainly agree that this would be ideal, but nonetheless, I've seen
multiple cases where just trying to run the query, even against a
current version, would have shown that it's malformed or has some issue
which needs fixing and today we haven't even got that.
> Andrew has a buildfarm module that does precisely that, although
> I'm not sure what its test dataset is --- probably the regression
> database from each branch. I also have a habit of doing such testing
> manually whenever I touch version-sensitive parts of pg_dump.
I've gotten better about doing that back-branch testing myself and
certainly prefer it, but I think we should also have buildfarm coverage.
I don't think we have the full matrix covered, or, really, anything
anywhere near it, so I'm looking for other options to at least get that
code exercised.
> Dunno about the idea of running the pg_dump TAP tests against back
> branches. I find that code sufficiently unreadable that maintaining
> several more copies of it doesn't sound like fun at all.
I hadn't been thinking we'd need more copies of it, simply a few more
runs which have different version values specified, though even just
doing a pg_dump of the regression suite for each combination would be
something.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-28 22:22:43 | Re: More parallel pg_dump bogosities |
Previous Message | Tom Lane | 2018-08-28 22:05:57 | Re: some pg_dump query code simplification |