Hi Curt,
> On 03. Aug, 2020, at 08:25, Curt Kolovson wrote:
> Thanks, Paul and Michael. I forgot to mention that we're using postgres
> v10.12.
11.6 and 12.3 here.
Also, please don't top-post, thanks.
Cheers,
Paul
Hi Curt, hi Michael,
> On 03. Aug, 2020, at 03:58, Michael Paquier wrote:
>
> On Sat, Aug 01, 2020 at 10:35:37AM -0700, Curt Kolovson wrote:
>> Any info on the reliability of pg_rewind and its limitations would be
>> appreciated.
>
> FWIW, we use it in production to accelerate the redeployment
At Sat, 1 Aug 2020 09:58:05 -0700, Ben Chobot wrote in
>
>
> Alvaro Herrera wrote on 8/1/20 9:35 AM:
> > On 2020-Aug-01, Ben Chobot wrote:
> >
> >> We have a few hundred postgres servers in AWS EC2, all of which do
> >> streaming
> >> replication to at least two replicas. As we've transitioned
On Sat, Aug 01, 2020 at 10:35:37AM -0700, Curt Kolovson wrote:
> When trying to resync an old primary to become a new standby, I have found
> that pg_rewind only works occasionally. How reliable/robust is pg_rewind,
> and what are its limitations? We have observed that approx half our FPIs in
> the
On Wed, 29 Jul 2020 at 09:07, Andres Freund wrote:
> On 2020-07-28 11:54:53 +1200, David Rowley wrote:
> > Is there some reason that we can't consider jitting on a more granular
> > basis?
>
> There's a substantial "constant" overhead of doing JIT. And that it's
> nontrival to determine which part
When trying to resync an old primary to become a new standby, I have found
that pg_rewind only works occasionally. How reliable/robust is pg_rewind,
and what are its limitations? We have observed that approx half our FPIs in
the WALs are due to XLOG/FPI_FOR_HINT. The only reason we've set
wal_log_h
