On 2014-07-22 10:09:04 +0900, MauMau wrote:
From: Andres Freund and...@2ndquadrant.com
On 2014-07-18 23:38:09 +0900, MauMau wrote:
So, I propose a simple fix to change the LOG level to DEBUG1. I don't
know
which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
include this
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 10:09:04 +0900, MauMau wrote:
Is there any problem if we don't output the message?
Yes. The user won't know that possibly gigabytes worth of diskspace
aren't freed.
RemovePgTempFiles() frees the disk space by removing temp relation
On 2014-07-22 17:05:22 +0900, MauMau wrote:
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 10:09:04 +0900, MauMau wrote:
Is there any problem if we don't output the message?
Yes. The user won't know that possibly gigabytes worth of diskspace
aren't freed.
RemovePgTempFiles()
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 17:05:22 +0900, MauMau wrote:
RemovePgTempFiles() frees the disk space by removing temp relation files
at
server start.
But it's not called during a crash restart.
Yes, the comment of the function says:
* NOTE: we could, but don't,
On 2014-07-22 19:13:56 +0900, MauMau wrote:
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 17:05:22 +0900, MauMau wrote:
RemovePgTempFiles() frees the disk space by removing temp relation files
at
server start.
But it's not called during a crash restart.
Yes, the comment of
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 19:13:56 +0900, MauMau wrote:
But this is true if restart_after_crash = on in postgresql.conf, because
the
crash restart only occurs in that case. However, in HA cluster, whether
it
is shared-disk or replication, restart_after_crash is
On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund and...@2ndquadrant.com wrote:
Yes, so nobody can convince serious customers that the current behavior
makes real sense.
I think you're making lots of noise over a trivial log message.
Could you please reconsider this?
No. Just removing a
On 2014-07-22 09:39:13 -0400, Robert Haas wrote:
On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund and...@2ndquadrant.com wrote:
Yes, so nobody can convince serious customers that the current behavior
makes real sense.
I think you're making lots of noise over a trivial log message.
Could
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund and...@2ndquadrant.com wrote:
No. Just removing a warning isn't the way to solve this. If you want to
improve things you'll actually need to improve things not just stick
your head into the sand.
I've
On 2014-07-22 10:17:15 -0400, Tom Lane wrote:
Or even more to the point, investigate why it's there in the first
place; perhaps there's an actual fixable bug somewhere in there.
I think MauMau's scenario of a failover to another database explains
their existance - there's no step that'd remove
On 2014-07-22 22:18:03 +0900, MauMau wrote:
From: Andres Freund and...@2ndquadrant.com
On 2014-07-22 19:13:56 +0900, MauMau wrote:
But this is true if restart_after_crash = on in postgresql.conf, because
the
crash restart only occurs in that case. However, in HA cluster, whether
it
is
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-22 10:17:15 -0400, Tom Lane wrote:
Or even more to the point, investigate why it's there in the first
place; perhaps there's an actual fixable bug somewhere in there.
I think MauMau's scenario of a failover to another database explains
On 2014-07-23 00:13:26 +0900, MauMau wrote:
Hello, Robert-san, Andres-san, Tom-san,
From: Andres Freund and...@2ndquadrant.com
a) There very well could be a backend reconnecting to that
backendId. Then we potentially might try to remove the temp schema
from two backends - I'm not sure
Hello, Robert-san, Andres-san, Tom-san,
From: Andres Freund and...@2ndquadrant.com
a) There very well could be a backend reconnecting to that
backendId. Then we potentially might try to remove the temp schema
from two backends - I'm not sure that's always going to end up going
well.
From: Andres Freund and...@2ndquadrant.com
On 2014-07-18 23:38:09 +0900, MauMau wrote:
So, I propose a simple fix to change the LOG level to DEBUG1. I don't
know
which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
include this in 9.2.9?
Surely that's the wrong end to
From: Andres Freund and...@2ndquadrant.com
On 2014-07-18 23:38:09 +0900, MauMau wrote:
LOG: autovacuum: found orphan temp table pg_temp_838.some_table in
database some_db
LOG: autovacuum: found orphan temp table pg_temp_902.some_table in
database some_db
So they had server crashes of some
Hi,
On 2014-07-18 23:38:09 +0900, MauMau wrote:
My customer reported a problem that the following message is output too
often.
LOG: autovacuum: found orphan temp table pg_temp_838.some_table in
database some_db
LOG: autovacuum: found orphan temp table pg_temp_902.some_table in
database
17 matches
Mail list logo
