Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running - Mailing list pgsql-hackers

From MauMau
Subject Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running
Date
Msg-id C5696CDEBEEF4B349ADFAD6EBD4659FF@maumau
Whole thread Raw
In response to Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
From: "Amit Kapila" <amit.kapila16@gmail.com>
> On Fri, Jul 4, 2014 at 7:29 PM, MauMau <maumau307@gmail.com> wrote:
>> [Hypothesis]
>> Why does the connection processing emit WAL?
>>
>> Probably, it did page-at-a-time vacuum during access to pg_database and
> pg_authid for client authentication.  src/backend/access/heap/README.HOT
> describes:
>
> I agree with your analysis that it can happen during connection
> attempt.

Thank you.  I'm relieved the cause seems correct.



>> But the customer could not reproduce the problem when he performed the
> same archive recovery from the same base backup again.  Why?  I guess the
> autovacuum daemon vacuumed the system catalogs before he attempted to
> connect to the database.
>>
> One way to confirm could be to perform the archive recovery by
> disabling autovacuum.

Yeah, I thought of that too.  Unfortunately, the customer deleted the the 
base backup for testing.


> Another thing which I am wondering about is can't the same happen
> even for Read Only transaction (incase someone does Select which
> prunes the page).

I'm afraid about that, too.

Regards
MauMau




pgsql-hackers by date:

Previous
From: Ali Akbar
Date:
Subject: Re: [REVIEW] Re: Fix xpath() to return namespace definitions
Next
From: "MauMau"
Date:
Subject: Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running