[HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

Поиск
Список
Период
Сортировка
От Tom Lane
Тема [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw
Дата
Msg-id 19872.1482338965@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
We have a report in pgsql-general of a dblink query failing withERROR: unknown error
This is, to say the least, unhelpful.  And it violates our error
message style guidelines.

Where that is coming from is a situation where we've failed to extract
any primary message from a remote error.  (I theorize that today's report
is triggered by an out-of-memory situation, but that's only an unsupported
guess at the moment.)

I propose that we should change that string to "could not obtain message
string for error on connection "foo"", or something along that line.

postgres_fdw has the same disease.  It wouldn't have the notion of a named
connection, but maybe we could insert the foreign server name instead.

A possible objection is that if we really are on the hairy edge of OOM,
trying to construct such error strings might push us over the edge and
then you get "out of memory" instead.  But IMO that's not worse; it
could be argued to be a more useful description of the problem.

Comments?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take