Re: %d in log_line_prefix doesn't work for bg/autovacuum workers

From: Christoph Berg <cb(at)df7cb(dot)de>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date: 2014-05-17 21:16:16
Message-ID: 20140517211616.GC9148@msgid.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Andres Freund 2014-05-17 <20140517203404(dot)GB4484(at)awork2(dot)anarazel(dot)de>
> > For example, if we allow
> > renaming active databases then the subprocesses in a parallel pg_dump or
> > pg_restore could connect to the wrong database, ie not the one the leader
> > process is connected to. The very best-case outcome of that is confusing
> > error messages, and worst-case could be pretty nasty (perhaps even
> > security issues?).
>
> Yea, I am pretty sure there's some nastyness that way. Don't really want
> to go there for a feature that's not even been requested.

Does pg_dumpall protect against connecting to the wrong database if
renames are on the way? To me, this sounds like the same problem as
with pg_dump -j.

> > We could no doubt teach pg_dump and pg_restore to
> > cross-check database OIDs after reconnecting, but lots of other
> > applications could have comparable problems.
>
> I guess pg_dump would have to lock the database before dumping....

Sounds like a sane idea for both.

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-05-17 21:19:30 Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Previous Message Christoph Berg 2014-05-17 21:10:42 Re: %d in log_line_prefix doesn't work for bg/autovacuum workers