Skip site navigation (1) Skip section navigation (2)

Re: Why isn't stats_temp_directory automatically created?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, 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: 2010-02-26 02:43:44
Message-ID: 201002260243.o1Q2hi003300@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I assume we decided we didn't want this.

---------------------------------------------------------------------------

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.)
> 
> * 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.
> 
> * elog(LOG) is not exactly an adequate response if the final chdir fails
> --- you have just broken the process beyond recovery.  That alone may be
> sufficient reason to reject the attempt to deal with symlinks.  As far
> as pgstat_temp_directory is concerned, I'm not sure of the point of
> making the GUC point to a symlink anyway --- if you have a GUC why not
> just point it where you want the directory to be?
> 
> 			regards, tom lane
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Jeroen VermeulenDate: 2010-02-26 02:48:05
Subject: Re: Avoiding bad prepared-statement plans.
Previous:From: Bruce MomjianDate: 2010-02-26 02:03:01
Subject: Re: A thought: should we run pgindent now?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group