Re: Moving pg_xlog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: KeithW(at)narrowpathinc(dot)com
Cc: "PostgreSQL Perform" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Moving pg_xlog
Date: 2005-06-01 20:30:54
Message-ID: 18210.1117657854@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Keith Worthington" <keithw(at)narrowpathinc(dot)com> writes:
> On Wed, 01 Jun 2005 12:19:40 -0400, Tom Lane wrote
>> Put the xlog anywhere BUT there!!!!!!!!!

> Is there a convention that most people follow. It would seem that
> anywhere in the installation directory is a bad idea. From what I
> have read on other threads it does not want to be in the database
> directory since in most cases that would put it on the same disk as
> the database.

I don't know of any fixed convention. The way I would be inclined to do
it, given that I wanted the data on disk 1 (with mount point /disk1) and
xlog on disk 2 (with mount point /disk2) is to create postgres-owned
directories /disk1/postgres/ and /disk2/postgres/, and then within those
put the data directory (thus, /disk1/postgres/data/) and xlog directory
(/disk2/postgres/pg_xlog/). Having an extra level of postgres-owned
directory is handy since it makes it easier to do database admin work
without being root --- once you've created those two directories and
chown'd them to postgres, everything else can be done as the postgres user.

Now that I think about it, you were (if I understood your layout
correctly) proposing to put the xlog on your system's root disk.
This is probably a bad idea for performance, because there will always
be other traffic to the root disk. What you are really trying to
accomplish is to make sure the xlog is on a disk spindle that has no
other traffic besides xlog, so that the disk heads never have to move
off the current xlog file. The xlog traffic is 100% sequential writes
and so you can cut the seeks involved to near nil if you can dedicate
a spindle to it.

> I am assuming due to lack of reaction that the symbolic link is not an issue.
> Is there a cleaner or more appropriate way of moving the pg_xlog.

No, that's exactly the way to do it.

> Finally, am I correct in assuming that as long as the postmaster is shut down
> moving the log is safe?

Right. You can move the data directory too if you want. AFAIR the only
position-dependent stuff in there is (if you are using tablespaces in
8.0) the tablespace symlinks under data/pg_tblspc/. You can fix those
by hand if you have a need to move a tablespace.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Brad Nicholson 2005-06-01 20:31:38 Re: Moving pg_xlog
Previous Message Casey Allen Shobe 2005-06-01 20:19:13 Performance nightmare with dspam (urgent)