Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
От | Andrew Dunstan |
---|---|
Тема | Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD |
Дата | |
Msg-id | 8b0e21de-c67f-7f4d-e612-077f999f570f@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 5/22/19 9:46 AM, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: >> Trying to do pg_dump[all] on a 9.5 or older server results in spurious >> failures: >> pg_dump: column number -1 is out of range 0..36 >> After looking around, the problem comes from >> check_tuple_field_number(), more specifically from getTables() where >> someone has forgotten to add NULL values for amname when querying >> older server versions. >> Attached is a patch to fix that. I am not seeing other failures with >> an instance that includes all the contents of installcheck, so it >> seems that the rest is fine. > Looks like the right fix. I'm sad that the buildfarm did not catch > this ... why wouldn't the cross-version-upgrade tests have seen it? That's a good question. It's in the output - see for example <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2019-05-22%2017%3A47%3A30&stg=xversion-upgrade-REL9_4_STABLE-HEAD> and scroll down a bit. But since this doesn't cause pg_dumpall to fail, it doesn't on its own cause the buildfarm to fail either, and this is apparently sufficiently benign to allow the tests to succeed. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: