Re: Add Information during standby recovery conflicts - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Add Information during standby recovery conflicts
Date
Msg-id CA+fd4k6msoKMGBxuOvZ8+iC2LAdzWbGZbkYY9r0+z56FVca-AA@mail.gmail.com
Whole thread Raw
In response to Re: Add Information during standby recovery conflicts  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Responses Re: Add Information during standby recovery conflicts
List pgsql-hackers
On Mon, 10 Aug 2020 at 23:43, Drouvot, Bertrand <bdrouvot@amazon.com> wrote:
>
> Hi,
>
> On 7/31/20 7:12 AM, Masahiko Sawada wrote:
> > +   tmpWaitlist = waitlist;
> > +   while (VirtualTransactionIdIsValid(*tmpWaitlist))
> > +   {
> > +       tmpWaitlist++;
> > +   }
> > +
> > +   num_waitlist_entries = (tmpWaitlist - waitlist);
> > +
> > +   /* display wal record information */
> > +   if (log_recovery_conflicts &&
> > (TimestampDifferenceExceeds(recovery_conflicts_log_time,
> > GetCurrentTimestamp(),
> > +                                   DeadlockTimeout))) {
> > +       LogBlockedWalRecordInfo(num_waitlist_entries, reason);
> > +       recovery_conflicts_log_time = GetCurrentTimestamp();
> > +   }
> >
> > recovery_conflicts_log_time is not initialized. And shouldn't we
> > compare the current timestamp to the timestamp when the startup
> > process started waiting?
> >
> > I think we should call LogBlockedWalRecordInfo() inside of the inner
> > while loop rather than at the beginning of
> > ResolveRecoveryConflictWithVirtualXIDs(). In lock conflict cases, the
> > startup process waits until 'ltime', then enters
> > ResolveRecoveryConflictWithVirtualXIDs() after reaching 'ltime'.
> > Therefore, it makes sense to call LogBlockedWalRecordInfo() at the
> > beginning of ResolveRecoveryConflictWithVirtualXIDs(). However, in
> > snapshot and tablespace conflict cases (i.g.
> > ResolveRecoveryConflictWithSnapshot() and
> > ResolveRecoveryConflictWithTablespace()), it enters
> > ResolveRecoveryConflictWithVirtualXIDs() without waits and waits for
> > reaching ‘ltime’ inside of the inner while look. So the above
> > condition could always be false.
>
> That would make the information being displayed after
> max_standby_streaming_delay is reached for the multiple cases you just
> described.

Sorry, it should be deadlock_timeout, not max_standby_streaming_delay.
Otherwise, the recovery conflict log message is printed when
resolution, which seems not to achieve the original purpose. Am I
missing something?

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: "Khanna, Sachin 000"
Date:
Subject: Help needed configuring postgreSQL with xml support
Next
From: Thomas Munro
Date:
Subject: Re: Help needed configuring postgreSQL with xml support