Re: Why isn't stats_temp_directory automatically created?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why isn't stats_temp_directory automatically created?
Date: 2009-05-04 09:21:57
Message-ID: 49FEB3B5.9060809@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2009-05-04 10:15:09 Re: [HACKERS] high shared buffer and swap
Previous Message Magnus Hagander 2009-05-04 09:11:03 Re: windows doesn't notice backend death