Re: [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running

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

In response to

Browse pgsql-hackers by date

  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