Guy thanks for your replies.
You are right about the strange
I found the problem and is related to the peculiar setup we have on this
appliance. PGDATA exists on a mounted partition but we somehow managed
to create an older version of PGDATA under the mount point.
So sometimes postgres would load the data from the unmounted PGDATA and
sometimes from the mounted partition.
It' s a pretty unlikely scenario and I burned lots of braincells trying
to figure it out.
So not really a postgres problem but rather our peculiar setup.
On 02/13/2014 10:39 AM, Luca Ferrari wrote:
> On Wed, Feb 12, 2014 at 6:59 AM, Theodotos Andreou
> <theo@theo-andreou.org> wrote:
>> I have a weird problem. Sometimes when the machine is restarted, there is no
>> $PGDATA/postmaster.pid file. So when I try to restart postgres (service
>> postgresql restart) I get the following error:
>>
> It is not clear what the real problem is. After a machine reboot it is
> normal that there is no pid file, meaning a clean shutdown happened
> (from the PostgreSQL perspective). After a full start, if the
> PostgreSQL process is configured for automatic start, a pid file
> should exist. I suspect the problem is related to some ubuntu booting
> script that will place the pid file somewhere else from where the
> pg_ctl expects to find it.
>
>> An even scarier side-effect of this is that the data, when this happens, are
>> older than the most recent data in the database.
>>
> This does not make sense at all. How do you know that data is older?
> And most notably: is data stable? I mean, could it be some kind of
> snapshotting of the database filesystem (as other suggested) or sounds
> like a data corruption?
>
>
>> Also postgres is installed on a customer appliance that may experience
>> frequent reboots and even abrupt poweroffs! Is postgres in general ideal for
>> this situation? Is there an optimal configuration for this scenario?
> PostgreSQL is reliable, but even a reliable system can crash when
> running on a totally unreliable piece of hardware. I suggest investing
> in some good platform to avoid stressing the database with resumes.
> However, in such scenario, I will choose a sync of all commits and
> short checkpoints, but this will lead to bad performances.
>
> Luca
>
>
