Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Carsten <fcarsten(at)tpg(dot)com(dot)au>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions
Date: 2007-04-18 07:36:18
Message-ID: 20070418073618.GB20431@svr2.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Apr 16, 2007 at 11:56:29PM +0000, Carsten wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3232
> Logged by: Carsten
> Email address: fcarsten(at)tpg(dot)com(dot)au
> PostgreSQL version: 8.2.3
> Operating system: Windows XP SP 2
> Description: Regression: pgsql server startup problem with encrypted
> partitions
> Details:
>
> I am running the following scenario:
>
> * Windows XP SP 2
> * Postgres 8.2.3 installed on a normal Windows partition
> * One highly sensitive database on a seperate table space which is located
> on a TureCrypt partition
> * The TrueCrypt partition only can be mounted after I log into the machine
> (as I have to enter the password)
>
> In the version of PostgreSQL which I was using previously (don't remember
> version number) this scenario worked fine. As long as I didn't try to access
> a database on the encrypted partition before mounting it the pgsql server
> was happy.

That was most likely just pure luck.

> In current version this no longer works. I have to manually restart the
> pgsql server after mounting the encyprted partition to access the database
> on it.
>
> Were there any changes which made the pgsql server stricter in requiring
> that all table-spaces exist on start-up? If yes, any chance of reversing
> this to support databases on encrypted partitions or removable devices?

The PostgreSQL startup process can access pretty much *any* file, depending
on circumstances. I don't see how we can make a guarantee about that.

We do support databases on encrypted partitions or removable drive - but
sticking *parts* of them there and just hopeing that the drive will be
there by the time you access just that part is not a very stable thing to
do. Keep the whole db on it, and make sure it's available before you start
PostgreSQL, andi t should work fine.
(This is simlar to NFS mounted data directories, which do work but only if
you're careful)

Now, you might want to consider using EFS for your encryption. When
properly set up, you won't need to input your password to get it going,
which in turn means that it can start up properly. If you really want the
password input part, set it up so PostgreSQL is started after TrueCrypt.

//Magnus

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Russell Smith 2007-04-18 07:41:26 Re: Grantor name gets lost when grantor role dropped
Previous Message Tom Lane 2007-04-18 05:28:05 Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions