"Interrupt requested" in postgresql-DAY.log
Hi,
I have a PostgreSQL 9.3.4 database running on CentOS 6 with PostGIS 2.1.2. Each night, I run a cron job to dump (pg_dump) a few schemas for development snapshots. Everything runs without error.
However, it seems that the dump process consistently results in a single line in the postgresql-*.log file. Oddly enough, this entry seems to ignore the log_line_prefix configuration parameter.
postgres@db:/var/lib/pgsql/9.3/data $ cat pg_log/postgresql-Fri.log
Interrupt requested
postgres@db:/var/lib/pgsql/9.3/data $ grep log_line_prefix postgresql.conf
log_line_prefix = '< %t > ' # special values:
postgres@db:/var/lib/pgsql/9.3/data $ psql
psql (9.3.4)
Type "help" for help.
postgres=# show log_line_prefix;
log_line_prefix
-----------------
< %t >
(1 row)
postgres=# \q
Any ideas where this could be coming from and why it isn’t prefixed?
Thanks,
Louis
Louis Battuello <louis.battuello@etasseo.com> writes:
I have a PostgreSQL 9.3.4 database running on CentOS 6 with PostGIS 2.1.2. Each night, I run a cron job to dump (pg_dump) a few schemas for development snapshots. Everything runs without error.
However, it seems that the dump process consistently results in a single line in the postgresql-*.log file. Oddly enough, this entry seems to ignore the log_line_prefix configuration parameter.
postgres@db:/var/lib/pgsql/9.3/data $ cat pg_log/postgresql-Fri.log
Interrupt requested
That probably represents some non-Postgres bit of code deciding to bleat
to stdout or stderr. The logging-collector mechanism is designed to catch
such output coming from a backend process, but it can't stick a
log_line_prefix on it.
What exactly is bleating, I can't say. A quick grep confirms that there
is no such string in the Postgres sources, but I dunno about PostGIS.
If you've got any code in plperl, plpython, etc, the culprit might lurk
somewhere there. glibc might even be to blame, though I don't think it
ordinarily prints error messages.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On May 27, 2014, at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Louis Battuello <louis.battuello@etasseo.com> writes:
I have a PostgreSQL 9.3.4 database running on CentOS 6 with PostGIS 2.1.2. Each night, I run a cron job to dump (pg_dump) a few schemas for development snapshots. Everything runs without error.
However, it seems that the dump process consistently results in a single line in the postgresql-*.log file. Oddly enough, this entry seems to ignore the log_line_prefix configuration parameter.
postgres@db:/var/lib/pgsql/9.3/data $ cat pg_log/postgresql-Fri.log
Interrupt requestedThat probably represents some non-Postgres bit of code deciding to bleat
to stdout or stderr. The logging-collector mechanism is designed to catch
such output coming from a backend process, but it can't stick a
log_line_prefix on it.What exactly is bleating, I can't say. A quick grep confirms that there
is no such string in the Postgres sources, but I dunno about PostGIS.
If you've got any code in plperl, plpython, etc, the culprit might lurk
somewhere there. glibc might even be to blame, though I don't think it
ordinarily prints error messages.regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thanks, Tom.
This does in fact look like something new bubbling up from PostGIS 2.1.2 and 2.1.3.
https://github.com/postgis/postgis/blob/svn-2.1/postgis/postgis_module.c
I don’t see it triggered in 2.1.1, so I’ll take my observation over to the GIS folks.
Regards,
Louis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general