"Keith Worthington" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to