Re: Control File - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: Control File
Date
Msg-id 443F6E6A.2060001@pse-consulting.de
Whole thread Raw
In response to Re: Control File  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
Jim C. Nasby wrote:
> On Thu, Apr 13, 2006 at 04:39:59AM -0400, Bruce Momjian wrote:
> 
>>Tom Lane wrote:
>>
>>>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>
>>>>Bruno Almeida do Lago wrote:
>>>>
>>>>>After that night, I started to ask myself if PostgreSQL should not have a
>>>>>control file to check if expected datafiles are where they should be and
>>>>>JUST warn about missing ones?
>>>
>>>>I don't think this happens frequently enough to add code for it.
>>>
>>>I think we saw it happen once to Joe Conway's DB.  But I see no
>>>particular reason why Postgres needs a feature for this --- you can
>>>stick a test into your database start script if you need it.
>>
>>Right, that is the only other time I remember it.
> 
> 
> The difference now is that we have tablespaces, which makes this
> scenario more likely. Previously I suspect common practice was to either
> leave everything in $PGDATA, or at most to move pg_xlog somewhere else
> and symlink it in, and I'm guessing that the databse will complain
> loudly if it can't find pg_xlog. So I suspect this will become far more
> common. As for adding checks to startup scripts, that's a PITA because
> those scripts will have no idea of where tablespaces might be defined,
> so you'd have to hard-code that info in.

... And we don't have startup scripts in win32. If tablespaces are used 
there, they may well reside on some kind of detachable media (SAN)

Regards,
Andreas




pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries
Next
From: Bruce Momjian
Date:
Subject: Re: OS cached buffers (was: Support Parallel Query Execution