From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running |
Date: | 2014-07-08 10:43:43 |
Message-ID: | C5696CDEBEEF4B349ADFAD6EBD4659FF@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
> On Fri, Jul 4, 2014 at 7:29 PM, MauMau <maumau307(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2014-07-08 10:50:28 | Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running |
Previous Message | Ali Akbar | 2014-07-08 10:03:19 | Re: [REVIEW] Re: Fix xpath() to return namespace definitions |