Re: Proposal to add a QNX 6.5 port to PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Baker, Keith [OCDUS Non-J&J]" <KBaker9(at)its(dot)jnj(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal to add a QNX 6.5 port to PostgreSQL
Date: 2014-07-29 23:34:44
Message-ID: 11070.1406676884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Baker, Keith [OCDUS Non-J&J]" <KBaker9(at)its(dot)jnj(dot)com> writes:
> If there are existing tests I can run to ensure the QNX port meets your criteria for robust failure handling in this area I would be happy to run them.
> If not, perhaps someone can provide a quick list of failure modes to consider.
> As-is:
> - starting of a second postmaster fails with message 'FATAL: lock file "postmaster.pid" already exists'
> - Kill -9 of postmaster followed by a pg_ctl start seems to go through recovery, although the original shared memory segments hang out in /dev/shmem until reboot (that could be better).

Unfortunately, that probably proves it's broken rather than that it works.
The behavior we need is that after kill -9'ing the postmaster, subsequent
postmaster start attempts *fail* until all the original postmaster's child
processes are gone. Otherwise you end up with two independent sets of
processes scribbling on the same files (and not sharing shmem either).
Kiss consistency goodbye ...

It's possible that all the children automatically exited, especially if
you had only background processes active; but if you had a live regular
session it would not exit just because the parent process died.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-07-29 23:40:57 Re: Proposal: Incremental Backup
Previous Message Baker, Keith [OCDUS Non-J&J] 2014-07-29 23:23:46 Re: Proposal to add a QNX 6.5 port to PostgreSQL