Re: Re: Server tries to read a different config file than it is supposed to - Mailing list pgsql-general

From Tom Lane
Subject Re: Re: Server tries to read a different config file than it is supposed to
Date
Msg-id 1223.1432501178@sss.pgh.pa.us
Whole thread Raw
In response to Re: Server tries to read a different config file than it is supposed to  (twoflower <standa.kurik@gmail.com>)
Responses Re: Server tries to read a different config file than it is supposed to  (twoflower <standa.kurik@gmail.com>)
List pgsql-general
twoflower <standa.kurik@gmail.com> writes:
> I was doing this after I upgraded to 9.4.2, yes. As for the shut down: I
> suspect the server was rebooted without explicitly stopping Postgres. Not
> sure how this plays out in terms of cleanliness. This is everything relevant
> in the log file after I ran the start script:
> 2015-05-23 10:36:39.999 GMT [2102][0]: [1] LOG: database system was
> interrupted; last known up at 2015-05-23 08:59:41 GMT
> 2015-05-23 10:36:40.053 GMT [2102][0]: [2] FATAL: could not open file
> "/storage/postgresql/9.4/data/postgresql.conf": Permission denied
> 2015-05-23 10:36:40.054 GMT [2100][0]: [3] LOG: startup process (PID 2102)
> exited with exit code 1
> 2015-05-23 10:36:40.054 GMT [2100][0]: [4] LOG: aborting startup due to
> startup process failure

Yeah, so this is long after the real config file has been read.

I think that that unwritable postgresql.conf file had probably been
hanging around in your data directory for some time.  It was not causing
any particular problem until we decided we ought to fsync everything in
the data directory after a crash.  So this is indeed the same case
Christoph was complaining about.  But really you should remove that file
not just change its permissions; as is it's just causing confusion.

> I also tried the same situation on two other Ubuntu servers with the same
> version of Postgres (also upgraded to 9.4.2) and the same directory layout -
> made *postgresql.conf* in the data directory unaccessible, even renamed it,
> and everything worked fine. The only difference is that these are
> streaming-replicated standby servers. They also had been restarted without
> explicitly terminating Postgres.

Hm.  I wonder why we aren't fsync'ing on crash restart on standby servers
as well.

            regards, tom lane


pgsql-general by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
Next
From: Scott Marlowe
Date:
Subject: Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"