Thread: postgresql and encfs?
Has anyone successfully used encfs with postgresq recently?
I'm not sure if this is specifically a postgresql problem, but I'm trying to get postgresql to run on an
encrypted file system that is a copy of my live data directory tree
(after a shutdown, of course) and am getting the following errors in the log:
LOG: database system was shut down at 2011-06-21 23:21:08 CDT
LOG: checkpoint record is at 9/D6A7078
LOG: redo record is at 9/D6A7078; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/6712; next OID: 137017002
LOG: next MultiXactId: 1; next MultiXactOffset: 0
PANIC: could not open file "pg_xlog/00000001000000090000000D" (log file 9, segment 13): Invalid argument
LOG: startup process (PID 21248) was terminated by signal 6
LOG: aborting startup due to startup process failure
The database version here is 8.2.11, running on a Linux Fedora Core 14 server.
The encrypted file system was created and mounted as the postgres user.
I can read the "pg_xlog/00000001000000090000000D" file as the postgres user
and the log entries were written in a directory that is part of the encrypted file system,
so it appears that encfs is working as it should.
Since as far as I can tell the postgres user has full access on that directory once mounted, my best guess is
that postgresql is trying to access the pg_xlog file as some user other than
postgres, Mounting the file system in --public mode doesn't have any impact.
FWIW, the reason I'm doing this is I'm trying to create a copy of a client database I can take with me to
a conference this summer but I'd prefer it to be encrypted in the event the portable drive it is on is lost or stolen.
So far this appears to be the best option available.
I'm testing it to see if performance is going to be a major concern.
--
Mike Nolan
nolan@tssi.com
I'm not sure if this is specifically a postgresql problem, but I'm trying to get postgresql to run on an
encrypted file system that is a copy of my live data directory tree
(after a shutdown, of course) and am getting the following errors in the log:
LOG: database system was shut down at 2011-06-21 23:21:08 CDT
LOG: checkpoint record is at 9/D6A7078
LOG: redo record is at 9/D6A7078; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/6712; next OID: 137017002
LOG: next MultiXactId: 1; next MultiXactOffset: 0
PANIC: could not open file "pg_xlog/00000001000000090000000D" (log file 9, segment 13): Invalid argument
LOG: startup process (PID 21248) was terminated by signal 6
LOG: aborting startup due to startup process failure
The database version here is 8.2.11, running on a Linux Fedora Core 14 server.
The encrypted file system was created and mounted as the postgres user.
I can read the "pg_xlog/00000001000000090000000D" file as the postgres user
and the log entries were written in a directory that is part of the encrypted file system,
so it appears that encfs is working as it should.
Since as far as I can tell the postgres user has full access on that directory once mounted, my best guess is
that postgresql is trying to access the pg_xlog file as some user other than
postgres, Mounting the file system in --public mode doesn't have any impact.
FWIW, the reason I'm doing this is I'm trying to create a copy of a client database I can take with me to
a conference this summer but I'd prefer it to be encrypted in the event the portable drive it is on is lost or stolen.
So far this appears to be the best option available.
I'm testing it to see if performance is going to be a major concern.
--
Mike Nolan
nolan@tssi.com
Michael Nolan <htfoot@gmail.com> writes:
> Has anyone successfully used encfs with postgresq recently?
> PANIC: could not open file "pg_xlog/00000001000000090000000D" (log file 9,
> segment 13): Invalid argument
> The database version here is 8.2.11, running on a Linux Fedora Core 14
> server.
Does it work any better if you set wal_sync_method = fdatasync?
That's been our default on Linux since 8.2.19, because of certain
filesystems failing like this. I'm kind of wondering why you're
not using a more current minor release, anyway, if this is a new
install.
regards, tom lane
On Wed, Jun 22, 2011 at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Nolan <htfoot@gmail.com> writes:
> Has anyone successfully used encfs with postgresq recently?> PANIC: could not open file "pg_xlog/00000001000000090000000D" (log file 9,
> segment 13): Invalid argument> The database version here is 8.2.11, running on a Linux Fedora Core 14Does it work any better if you set wal_sync_method = fdatasync?
> server.
That's been our default on Linux since 8.2.19, because of certain
filesystems failing like this. I'm kind of wondering why you're
not using a more current minor release, anyway, if this is a new
install.
regards, tom lane
Yes, that fixes the problem. I was using that minor release because that's what the production server is still running. For the purposes of this conference, I may use a 9.0.4 server, which I have running as I continue to work on upgrade issues. (I just want to be able to run some ad hoc queries on the database while at that meeting without having to deal with net access problems, so the issues keeping them from running a more current release shouldn't be a factor. With luck, I'll get the budget and approval to schedule the move to a more current release while there.)
As always, you are a font of knowledge, Tom.
--
Mike Nolan