Robert Haas writes:
> On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut
> wrote:
>> Throwing the socket address in there seems a bit distracting and
>> misleading, and it also pushes off the actual information very far to
>> the end. (Also, in some cases the socket path is very long, making the
>>
On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut
wrote:
> I find these new error messages to be more distracting than before in
> some cases. For example:
>
> PG13:
>
> clusterdb: error: could not connect to database typo: FATAL: database
> "typo" does not exist
>
> PG14:
>
> clusterdb: error: co
On 21.01.21 02:33, Tom Lane wrote:
I'd be inclined to spell it "connection to server at ... failed",
but that sort of wording is surely also possible.
"connection to server" rather than "connection to database" works for
me; in fact, I think I like it slightly better.
If I don't hear any oth
On 2021-Jan-26, Tom Lane wrote:
> Alvaro Herrera writes:
> > pgbench has one occurrence of the old pattern in master, in line 6043.
> > However, since doConnect() returns NULL when it gets CONNECTION_BAD,
> > that seems dead code. This patch kills it.
>
> Oh ... I missed that because it wasn't
Alvaro Herrera writes:
> pgbench has one occurrence of the old pattern in master, in line 6043.
> However, since doConnect() returns NULL when it gets CONNECTION_BAD,
> that seems dead code. This patch kills it.
Oh ... I missed that because it wasn't adjacent to the PQconnectdbParams
call :-(.
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 1:54 PM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Well, the patch seems small enough, and I don't think it'll be in any
> > > way helpful to omit that detail.
> >
> > I'm +1 for applying and back-patching that. I still think w
I wrote:
> If I don't hear any other opinions, I'll change these messages to
> "connection to server at socket \"%s\" failed: "
> "connection to server at \"%s\" (%s), port %s failed: "
Done. Also, here is a patch to remove the redundant-seeming prefixes
from our reports of connection failures.
Robert Haas writes:
>>> Maybe it would be better if it said:
>>> connection to database at socket "/tmp/.s.PGSQL.5432" failed: FATAL:
>>> database "rhaas" does not exist
>> I'd be inclined to spell it "connection to server at ... failed",
>> but that sort of wording is surely also possible.
> "c
On Wed, Jan 20, 2021 at 1:54 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jan-20, Robert Haas wrote:
> >> I figured it was something like that. I don't know whether the right
> >> thing is to use something like PQdb() to get the correct database
> >> name, or whether we should go with
Alvaro Herrera writes:
> On 2021-Jan-20, Robert Haas wrote:
>> I figured it was something like that. I don't know whether the right
>> thing is to use something like PQdb() to get the correct database
>> name, or whether we should go with Tom's suggestion and omit that
>> detail altogether, but I
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 1:25 PM Alvaro Herrera
> wrote:
> > That's because pgbench reports the input argument dbname, but since you
> > didn't specify anything, then PQconnectdbParams() uses the libpq
> > behavior. I think we'd have to use PQdb() instead.
>
On Wed, Jan 20, 2021 at 1:25 PM Alvaro Herrera wrote:
> That's because pgbench reports the input argument dbname, but since you
> didn't specify anything, then PQconnectdbParams() uses the libpq
> behavior. I think we'd have to use PQdb() instead.
I figured it was something like that. I don't kn
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
> > Robert Haas writes:
> > > I just made the mistake of trying to run pgbench without first running
> > > createdb and got this:
> >
> > > pgbench: error: connection to database "" failed: could not connect to
On Wed, Jan 20, 2021 at 12:47 PM Tom Lane wrote:
> Fair. One possibility, which'd take a few more cycles in libpq but
> likely not anything significant, is to replace "could not connect to ..."
> with "while connecting to ..." once we're past the connect() per se.
Yeah. I think this is kind of a
Robert Haas writes:
> On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
>> But the 'could not connect to socket' part is a consequence of my
>> recent fiddling with libpq's connection failure reporting, see
>> 52a10224e. We could discuss exactly how that ought to be spelled,
>> but the idea is to
On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
> Robert Haas writes:
> > I just made the mistake of trying to run pgbench without first running
> > createdb and got this:
>
> > pgbench: error: connection to database "" failed: could not connect to
> > socket "/tmp/.s.PGSQL.5432": FATAL: databa
Robert Haas writes:
> I just made the mistake of trying to run pgbench without first running
> createdb and got this:
> pgbench: error: connection to database "" failed: could not connect to
> socket "/tmp/.s.PGSQL.5432": FATAL: database "rhaas" does not exist
> This looks pretty bogus because
I just made the mistake of trying to run pgbench without first running
createdb and got this:
pgbench: error: connection to database "" failed: could not connect to
socket "/tmp/.s.PGSQL.5432": FATAL: database "rhaas" does not exist
This looks pretty bogus because (1) I was not attempting to con
18 matches
Mail list logo