Re: [bug fix] Suppress "autovacuum: found orphan temp table" message - Mailing list pgsql-hackers

From MauMau
Subject Re: [bug fix] Suppress "autovacuum: found orphan temp table" message
Date
Msg-id 03494F091383441E9F75E4BFA79AF168@maumau
Whole thread Raw
In response to Re: [bug fix] Suppress "autovacuum: found orphan temp table" message  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [bug fix] Suppress "autovacuum: found orphan temp table" message  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
From: "Andres Freund" <andres@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, call this during a post-backend-crash restart* cycle.  The argument for not doing it is
thatsomeone might want to 
 
examine* the temp files for debugging purposes.  This does however mean that* OpenTemporaryFile had better allow for
collisionwith an existing temp* file name.
 

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?

Moreover, as the comment says, the behavior of keeping leftover temp files 
is for debugging by developers.  It's not helpful for users, isn't it?  I 
thought messages of DEBUG level is more appropriate, because the behavior is 
for debugging purposes.

>> In addition, the temp relation files are not replicated to
>> the standby server of streaming replication (this is the customer's
>> case).
>
> So?

Yes, so nobody can convince serious customers that the current behavior 
makes real sense.

Could you please reconsider this?

Regards
MauMau




pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().
Next
From: 土卜皿
Date:
Subject: Re: how to reach D5 in tuplesort.c 's polyphase merge algorithm?