This was my fault. I'd restored recovery.conf from recovery.done to try to
recover manually after automated recovery failed. Everything's working
after stopping the database and running pgpool online recovery again.
Thanks for the help.
On Sat, Dec 2, 2017 at 1:55 PM, Joshua D. Drake
wrote:
> O
On Sat, Dec 2, 2017 at 11:02 AM, Zach Walton wrote:
> Looking at the startup process:
>
> postgres 16749 4.1 6.7 17855104 8914544 ?Ss 18:36 0:44 postgres:
> startup process recovering 00085B1C0030
>
> Then a few seconds later:
>
> postgres 16749 4.2 7.0 17855104 9294172
On 12/02/2017 11:02 AM, Zach Walton wrote:
Generally this works itself out if I wait (sometimes a really long
time). Is there a configuration option that allows a warm standby to
start without having fully replayed the logs from the master?
* Note: wal_keep_segments is set to 8192 on these s
Looking at the startup process:
postgres 16749 4.1 6.7 17855104 8914544 ?Ss 18:36 0:44 postgres:
startup process recovering 00085B1C0030
Then a few seconds later:
postgres 16749 4.2 7.0 17855104 9294172 ?Ss 18:36 0:47 postgres:
startup process recovering 0
On Fri, Dec 1, 2017 at 4:39 PM, Job wrote:
> Dear guys,
>
> we are using Postgresql 9.6.1 with Rubyrep in order to replicate some
> tables across two different, and remote, database servers.
> Since few weeks sometimes when inserting/updating some rows, the statement
> remains waiting and table s
On Sat, Dec 2, 2017 at 8:02 AM John R Pierce wrote:
> On 12/1/2017 12:44 PM, basti wrote:
> > Replication is no backup.
> > Its more like a RAID.
> >
> > That mean tubles that are delete on master by a mistake there are also
> > delete on slave.
> >
> > correct me if i'am wrong.
>
You have not m
> On 1 Dec 2017, at 22:39, Job wrote:
>
> Dear guys,
>
> we are using Postgresql 9.6.1 with Rubyrep in order to replicate some tables
> across two different, and remote, database servers.
> Since few weeks sometimes when inserting/updating some rows, the statement
> remains waiting and table
