Re:

The slave doesn't "turn off" the master. The trigger file is intended to be touched _when the master is down_.

Since the master never WENT down (or came back up) and the trigger file was touched, the slave got promoted.

You'll need to stop the slave, run your select pg_startbackup(), rsync, etc to get your slave back to slave mode.

----- Original Message -----

> There IS a trigger file, which does appear to have been "touch"ed. But the
> problem is that a fail-over hasn't really occurred since the original
> read/write primary continues to be a fully functioning read/write machine.
> But it's no longer replicating to the erstwhile standby, which has become
> read/write. Bottom line, I now have 2 read/write machines, but with no
> replication between them.
> On Friday, April 25, 2014 1:43 PM, Scott Whitney <scott(at)journyx(dot)com> wrote:
> Sounds like you might have a "trigger_file" set in your recovery.conf. Do
> you? That or someone is issuing a pg_ctl promote command.

> > I'm using PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc
> > (GCC)
> > 4.1.2 20070115 (SUSE Linux), 64-bit.
>

> > I set up streaming replication for a read/write primary and a read/only
> > standby. The replication works fine for a while, and then out of the blue
> > BOTH machines become read/write, but with no replication from the original
> > primary to the newly read/write standby.
>

> > The only log entry that seems relevant is as follows:
> > FATAL,57P01,"terminating walreceiver process due to administrator
> > command",,,,,,,,"ProcessWalRcvInterrupts, walreceiver.c:150",""
>

> > Any help/guidance would be appreciated. Thanks in advance.
>