Andres Freund wrote:
On 2014-05-17 23:35:43 +0200, Christoph Berg wrote:
Fwiw, this wasn't the first time I've heard of that idea, it also
doesn't sound too far-fetched for me. I guess people usually go damn,
I can't rename active dbs, let's try something else instead of
complaining on
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 00:17:46 +0200, Andres Freund wrote:
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
This is basically reintroducing a variable that used to exist and was
intentionally gotten rid of, on the grounds that it'd fail to track
any renaming
Hi,
On 2014-05-17 12:23:51 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 00:17:46 +0200, Andres Freund wrote:
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
This is basically reintroducing a variable that used to exist and was
intentionally gotten rid
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 12:23:51 -0400, Tom Lane wrote:
I think the key issue comes down to this comment in RenameDatabase:
* XXX Client applications probably store the current database somewhere,
* so renaming it could cause confusion. On the other hand,
On 2014-05-17 16:23:26 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 12:23:51 -0400, Tom Lane wrote:
Given that there haven't been complaints in the past ten years about how
you can't rename an active database, I'm OK personally with locking this
down
Re: Tom Lane 2014-05-17 22961.1400343...@sss.pgh.pa.us
I think the key issue comes down to this comment in RenameDatabase:
* XXX Client applications probably store the current database somewhere,
* so renaming it could cause confusion. On the other hand, there may not
* be an
Re: Andres Freund 2014-05-17 20140517203404.gb4...@awork2.anarazel.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
On 2014-05-17 23:10:42 +0200, Christoph Berg wrote:
Given that there haven't been complaints in the past ten years about how
you can't rename an active database, I'm OK personally with locking this
down forever. But I wonder if anyone wants to argue the contrary.
Fwiw, we ran into
Re: Andres Freund 2014-05-17 20140517211930.ga10...@awork2.anarazel.de
On 2014-05-17 23:10:42 +0200, Christoph Berg wrote:
Given that there haven't been complaints in the past ten years about how
you can't rename an active database, I'm OK personally with locking this
down forever. But
On 2014-05-17 23:35:43 +0200, Christoph Berg wrote:
They want to pg_terminate_backend() the sessions on db_old anyway, but
to get that point, you need to be able to rename the db. The
alternative would be to disallow connections to the db (for which
there is no real nice way), kill existing
Hi,
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL || *dbname == '\0')
dbname = _([unknown]);
Andres Freund and...@2ndquadrant.com writes:
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL || *dbname == '\0')
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Not directly related to your gripe, but: where did this padding logic
come from, and what prevents it from creating invalidly-encoded output by
means of truncating multibyte characters in the middle?
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
Not directly related to your gripe, but: where did this padding logic
come from, and what prevents it from creating invalidly-encoded output by
means of
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Ah, you're right, so sprintf shouldn't attempt to truncate the data
anywhere. Nonetheless, this has created a hazard that wasn't there
before: with any padding spec, sprintf has to determine the
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
Ah, you're right, so sprintf shouldn't attempt to truncate the data
anywhere. Nonetheless, this has created a hazard that wasn't there
before: with any
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
But according to previous research, we don't
really guarantee that glibc thinks the encoding is what we think, anyway.
The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and
On 2014-05-16 16:19:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
But according to previous research, we don't
really guarantee that glibc thinks the encoding is what we think, anyway.
The commit messages for
Hi,
On 2014-05-16 19:54:56 +0200, Andres Freund wrote:
Hi,
elog.c's log_line_prefix() processes %d with:
case 'd':
if (MyProcPort)
{
const char *dbname = MyProcPort-database_name;
if (dbname == NULL ||
Andres Freund and...@2ndquadrant.com writes:
It's imo pretty annoying that neither bgworkers nor autovacuum workers
show the proper database in the log. Why don't we just populate a global
variable in InitPostgres() once we're sure which database the backend is
connected to? We could fill fake
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
It's imo pretty annoying that neither bgworkers nor autovacuum workers
show the proper database in the log. Why don't we just populate a global
variable in InitPostgres() once we're sure which
On 2014-05-17 00:17:46 +0200, Andres Freund wrote:
On 2014-05-16 17:48:28 -0400, Tom Lane wrote:
This is basically reintroducing a variable that used to exist and was
intentionally gotten rid of, on the grounds that it'd fail to track
any renaming of the session's current database (cf
23 matches
Mail list logo
