Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alan Nilsson <anilsson(at)apple(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Nix <robert(at)urban4m(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1
Date: 2013-10-27 14:14:58
Message-ID: 13075.1382883298@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alan Nilsson <anilsson(at)apple(dot)com> writes:
> What I am saying is that something changed in 90300 that causes libpq to spew to stdout where it had not in libpq 90102 & 90203.

Well, that's interesting, but the issue is not in libpq, and you've still
provided no information that would help anyone diagnose where it is
(like, say, the query that's producing different results).

> I guess i am blaming the messenger because there should be no messenger. Regardless of how badly I mangle the use of libpq, it should not be sending anything to stdout.

Would you prefer it dumped core? It doesn't have very many choices for
reporting that you've passed invalid arguments. In any case, the short
answer is that if you'd like this code fragment to do X when the query
has returned zero rows, you should explicitly code a test for that.
Otherwise you're at the mercy of somebody else's idea of what to do
with the error condition.

Also, if your gripe is not so much that it resorted to printing a message
as exactly how it printed it, see libpq's options for inserting your own
message processing hooks.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Marcin Mańk 2013-10-27 14:18:39 Re: Unique - first
Previous Message Thomas Kellerer 2013-10-27 13:25:46 Re: Unique - first