On Sat, Aug 30, 2014 at 7:04 AM, Chris Hundt wrote:
> (One of Patrick's coworkers here; thanks a lot for your assistance)
>
> Just in case you wanted this as well, I ran
>
> psql 'replication=1 dbname=XXX host=127.0.0.1 port=5432 user=XXX
> password=XXX' -c 'IDENTIFY_SYSTEM;'
>
> (5432 is the stu
(One of Patrick's coworkers here; thanks a lot for your assistance)
Just in case you wanted this as well, I ran
psql 'replication=1 dbname=XXX host=127.0.0.1 port=5432 user=XXX
password=XXX' -c 'IDENTIFY_SYSTEM;'
(5432 is the stuck replica and 5445 is the pipe to the working replica)
syst
On Fri, Aug 29, 2014 at 3:46 PM, Andres Freund
wrote:
> [FWIW: proper quoting makes answering easier and thus more likely]
>
> On 2014-08-29 15:37:51 -0700, Patrick Krecker wrote:
> > I ran the following on the local endpoint of spiped:
> >
> > while [ true ]; do psql -h localhost -p 5445 judicat
[FWIW: proper quoting makes answering easier and thus more likely]
On 2014-08-29 15:37:51 -0700, Patrick Krecker wrote:
> I ran the following on the local endpoint of spiped:
>
> while [ true ]; do psql -h localhost -p 5445 judicata -U marbury -c "select
> modtime, pg_last_xlog_receive_location()
On Fri, Aug 29, 2014 at 2:11 PM, Andres Freund
wrote:
> On 2014-08-29 13:04:43 -0700, Patrick Krecker wrote:
> > Hi Craig -- Sorry for the late response, I've been tied up with some
> other
> > things for the last day. Just to give some context, this is a machine
> that
> > sits in our office and
On 2014-08-29 13:04:43 -0700, Patrick Krecker wrote:
> Hi Craig -- Sorry for the late response, I've been tied up with some other
> things for the last day. Just to give some context, this is a machine that
> sits in our office and replicates from another read slave in production via
> a tunnel set
Hi Craig -- Sorry for the late response, I've been tied up with some other
things for the last day. Just to give some context, this is a machine that
sits in our office and replicates from another read slave in production via
a tunnel set up with spiped. The spiped tunnel is working and postgres is
On 08/28/2014 09:39 AM, Patrick Krecker wrote:
> We have a periodic network connectivity issue (unrelated to Postgres)
> that is causing the replication to fail.
>
> We are running Postgres 9.3 using streaming replication. We also have
> WAL archives available to be replayed with restore_command.
We have a periodic network connectivity issue (unrelated to Postgres) that
is causing the replication to fail.
We are running Postgres 9.3 using streaming replication. We also have WAL
archives available to be replayed with restore_command. Typically when I
bring up a slave it copies over WAL arch
