Hello, Robert-san, Andres-san, Tom-san,
From: "Andres Freund"
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. There's already a race win
On 2014-07-23 00:13:26 +0900, MauMau wrote:
> Hello, Robert-san, Andres-san, Tom-san,
>
> From: "Andres Freund"
> >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
Andres Freund 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
> their existance
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"
> >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-
Robert Haas writes:
> On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund 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 studied this area of the code before,
On 2014-07-22 09:39:13 -0400, Robert Haas wrote:
> On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund 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 pl
On Tue, Jul 22, 2014 at 6:23 AM, Andres Freund 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 warning isn't the
From: "Andres Freund"
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 set to off, isn't
it
On 2014-07-22 19:13:56 +0900, MauMau wrote:
> From: "Andres Freund"
> >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 f
From: "Andres Freund"
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, call this during a po
On 2014-07-22 17:05:22 +0900, MauMau wrote:
> From: "Andres Freund"
> >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
From: "Andres Freund"
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 files at
server start.
On 2014-07-22 10:09:04 +0900, MauMau wrote:
> >From: "Andres Freund"
> >>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 i
From: "Andres Freund"
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 tackle this from. Hiding
From: "Andres Freund"
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 form befor
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
17 matches
Mail list logo
