Linked directory or explicit reference

On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa <frio_cervesa@hotmail.com>
wrote:

Hi All;

When doing an initial install of PostgreSQL on RHEL 7 or 8 derived OS via
rpm, what are pros, cons and recommendations of these 2 procedures for
utilizing a second disk?

Secondary SSD or RAID mounted at /disk2.

Option #1

1. install the rpm which creates basic user and home
2. Create symlink /var/lib/pgsql/15/data --> /disk2/data
3. initdb with no special options

Or Option #2

1. install the rpm which creates basic user and home
2. initdb with --pgdata=/disk2/data
Probably using included 'postgresql-12-setup' script

I also link /var/lib/pgsql/data --> ../15/data so automation can
reference postgresql.conf without knowing version (legacy stuff).

In my experience,The PgBackRest restore feature does not like symlinks.

The install is automated with a bash script which handles several options
including whether there is a second disk for DB. Scripting the install with
or without the second disk is straight forward but I'm concerned with
either scenario causing unforeseen differences.

I don't think there's a benefit to using tablespace here but I have no
experience with it. The systemd service is configured with a dependency on
the disk mount so I don't think there are different risks for starting
postgres with missing data directory.

I've run postgres in both scenarios and not had any issues. I'm interested
in comments from others on their experience using these or other options.

Is the mount point just "/disk2" when using "--pgdata=/disk2/data"? I've
gotten "directory not empty" errors when the mount point is
"/Database/x.y/data".

On 4/30/2024 17:31, Ron Johnson wrote:

On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa
<frio_cervesa@hotmail.com> wrote:

Hi All;

When doing an initial install of PostgreSQL on RHEL 7 or 8 derived
OS via rpm, what are pros, cons and recommendations of these 2
procedures for utilizing a second disk?

Secondary SSD or RAID mounted at /disk2.

Option #1

1. install the rpm which creates basic user and home
2. Create symlink /var/lib/pgsql/15/data --> /disk2/data
3. initdb with no special options

Or Option #2

1. install the rpm which creates basic user and home
2. initdb with --pgdata=/disk2/data
Probably using included 'postgresql-12-setup' script

I also link /var/lib/pgsql/data  --> ../15/data so automation can
reference postgresql.conf without knowing version (legacy stuff).

In my experience,The PgBackRest restore feature does not like symlinks.

I hadn't considered that and it's the kind of experience feedback I'm
looking for. It won't be an issue for me though.

The install is automated with a bash script which handles several
options including whether there is a second disk for DB. Scripting
the install with or without the second disk is straight forward
but I'm concerned with either scenario causing unforeseen differences.

I don't think there's a benefit to using tablespace here but I
have no experience with it. The systemd service is configured with
a dependency on the disk mount so I don't think there are
different risks for starting postgres with missing data directory.

I've run postgres in both scenarios and not had any issues. I'm
interested in comments from others on their experience using these
or other options.

Is the mount point just "/disk2" when using "--pgdata=/disk2/data"? 
I've gotten "directory not empty" errors when the mount point is
"/Database/x.y/data".

When linked, it looks like:

[root@test110 pgsql]# ll /var/lib/pgsql/15/data
lrwxrwxrwx. 1 root root 12 May  1 05:21 /var/lib/pgsql/15/data ->
/disk2/data/

I'm not sure what would trigger "directory not empty". When running
initdb there is nothing under data. I could see a problem with a symlink
throwing that message as a catchall though. I haven't run across any
problems yet.

Thank you Ron Johnson for the feedback.

On Thu, May 2, 2024 at 12:50 AM Senor Cervesa <frio_cervesa@hotmail.com>
wrote:
[snip]

I'm not sure what would trigger "directory not empty".

The lost+found directory.