From: | Ron <rjpeace(at)earthlink(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 15,000 tables |
Date: | 2005-12-02 08:15:00 |
Message-ID: | 6.2.5.6.0.20051202030859.0360c1a8@earthlink.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda pgsql-performance |
Agreed, and I apologize for the imprecision of my post below.
I should have written:
"Best practice seems to be to use a journaling fs and log metadata
only and put it on separate dedicated spindles."
I've seen enough HD failures that I tend to be paranoid and log the
metadata of fs dedicated to WAL as well, but that may very well be overkill.
Ron
At 01:57 PM 12/1/2005, Tom Lane wrote:
>Ron <rjpeace(at)earthlink(dot)net> writes:
> > Agreed. Also the odds of fs corruption or data loss are higher in a
> > non journaling fs. Best practice seems to be to use a journaling fs
> > but to put the fs log on dedicated spindles separate from the actual
> > fs or pg_xlog.
>
>I think we've determined that best practice is to journal metadata only
>(not file contents) on PG data filesystems. PG does expect the filesystem
>to remember where the files are, so you need metadata protection, but
>journalling file content updates is redundant with PG's own WAL logging.
>
>On a filesystem dedicated to WAL, you probably do not need any
>filesystem journalling at all --- we manage the WAL files in a way
>that avoids changing metadata for a WAL file that's in active use.
>A conservative approach would be to journal metadata here too, though.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Soto Cordones - Venezuela | 2005-12-02 11:28:50 | Re: Como verificar los Querys que se estan ejecutando en Pg |
Previous Message | ramirex | 2005-12-02 03:20:10 | Re: alter de una tabla |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2005-12-02 13:02:16 | Re: 15,000 tables |
Previous Message | Luke Lonergan | 2005-12-02 08:06:43 | Re: Database restore speed |