Re: open database on read only file system

[Scott Whitney <scott@xxxxxxxxxxx>]

Yes. This is the proper answer. Mine is shorter, but this is the entire point.

The results you get by enabling PG to run (temporarily) on RO doesn't guarantee production results.

-------- Original message --------
From: "David G. Johnston" <david.g.johnston@xxxxxxxxx> 
Date: 10/07/2016 5:06 PM (GMT-06:00) 
To: xujian <jamesxu@xxxxxxxxxxx> 
Cc: Scott Whitney <scott@xxxxxxxxxxx>, pgsql-admin@xxxxxxxxxxxxxx 
Subject: Re:  open database on read only file system

On Fri, Oct 7, 2016 at 2:46 PM, xujian <jamesxu@xxxxxxxxxxx> wrote:

Thanks Scott. Do you know if there is any way to support read-only FS? for instance patch or extension.

I noticed the error is from file md.c

========

/*

 * mdopen() -- Open the specified relation.

 *

 * Note we only open the first segment, when there are multiple segments.

 *

 * If first segment is not present, either ereport or return NULL according

 * to "behavior".  We treat EXTENSION_CREATE the same as EXTENSION_FAIL;

 * EXTENSION_CREATE means it's OK to extend an existing relation, not to

 * invent one out of whole cloth.

 */

static MdfdVec *

mdopen(SMgrRelation reln, ForkNumber forknum, int behavior)

========

so I changed the file open mode from O_RDWR to O_RDONLY

fd = PathNameOpenFile(path, O_RDONLY | PG_BINARY, 0600);

and it works. I can open the user database, and query table now. Do you think if there is any potential problem of this change?

I just need to open database on read-only file system, and no need any changes on the cluster. thanks

​For some definition of "work" something like this might give you satisfactory results.  You'd likely get more reliable answers if you explain exactly what your intended usage pattern is.

In short - the software has not been designed to operate in production on a read-only file system and likely few people, if anyone, is going to be able to give any kind of assurance that the system won't crash if operated in such a manner.

​You will need to ensure that you have at least one read/write file system setup as a tablespace in the cluster so that large queries can make use of temporary result areas.​

David J. ​

Journyx, Inc.

7600 Burnet Road #300
Austin, TX 78757
www.journyx.com

p 512.834.8888 

f 512-834-8858 

Do you receive our promotional emails? You can subscribe or unsubscribe to those emails at http://go.journyx.com/emailPreference/e/4932/714/