On May 27, 2014, at 10:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Louis Battuello <louis.battue...@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 >
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
