Re: Why isn't stats_temp_directory automatically created? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Why isn't stats_temp_directory automatically created?
Date
Msg-id 49FEB3B5.9060809@hagander.net
Whole thread Raw
In response to Re: Why isn't stats_temp_directory automatically created?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> Here is the revised patch; If stats_temp_directory indicates the symlink,
>> we pursue the chain of symlinks and create the referenced directory.
> 
> I looked at this patch a bit.  I'm still entirely unconvinced that we
> should be doing this at all --- if the directory is not there, there's
> a significant probability that there's something wrong that is beyond
> the backend's ability to understand or correct.  However, even ignoring
> that objection, the patch is not ready to commit for a number of
> reasons:
> 
> * Repeating the operation every time the stats file is written doesn't
> seem like a particularly good idea; it eats cycles, and if the directory
> disappears during live operation then there is *definitely* something
> fishy going on.  Can't we fix it so that the work is only done when the
> path setting changes?  (In principle you could do it in
> assign_pgstat_temp_directory(), but I think something would be needed to
> ensure that only the stats collector process actually tries to create
> the directory.  Or maybe it would be simplest to try to run the code only
> when we get a failure from trying to create the stats temp file.)

My idea was to have it run when it tries to create the temp file and
fails. Seems simpler than in the assign hook.


> * I don't think the mkdir_p code belongs in fd.c.  It looks like
> you copied-and-pasted it from initdb.c, which isn't any good either;
> we don't want to maintain multiple copies of this.  Maybe a new
> src/port/ file is indicated.

Yes, that's what I thought as well. How about src/port/dirmod.c though -
it has rename/unlink/symlink now which seem at least remotely related.

//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: windows doesn't notice backend death
Next
From: Martijn van Oosterhout
Date:
Subject: Re: high shared buffer and swap