"Marc Mamin" <marc@intershop.de> writes:
> I've stumbled on a few entries in my stderr log where the line prefix where
> missing. e.g.:
> 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|DETAIL: Returned type
> character ...
> 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|CONTEXT: PL/pgSQL
> function "bm_ ...
> 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|STATEMENT: Select
> coalesce(colu ...
> => NOTICE: table "sessions_summary_raw_20110815" does not exist, skipping
> => NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
> "pk_sessions_s ...
> => NOTICE: table "sessions_site_summary_raw_20110815" does not exist,
> skipping
> NOTICE entries should moreover not be logged !
> Those entries are coming from db_link.
I guess your test case is looping back to the same Postgres instance?
What I see here is that the target backend (the one connected to by
dblink) logs the warning as expected, and then the dblink one also
prints the warning to stderr. This is because dblink does not override
either PQsetNoticeReceiver or PQsetNoticeProcessor, so libpq provides
its default behavior of printing warnings/notices on stderr.
It'd probably make sense for dblink to supply a notice receiver that
converts the result into an ereport() call, much as it does for actual
error results (in fact it could likely use dblink_res_error for that).
But frankly this is an enhancement request, not a bug. The entire point
of the stderr logging mechanism is to capture random printouts to stderr
that might happen in code called by the backend, and it's doing exactly
what it's supposed to.
regards, tom lane