On Wed, Sep 19, 2012 at 5:45 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Sep 17, 2012 at 7:28 PM, <stuart@stuartbishop.net> wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7546
>> Logged by: Stuart Bishop
>> Email address: stuart@stuartbishop.net
>> PostgreSQL version: 9.1.5
>> Operating system: Ubuntu 12.10
>> Description:
>>
>> I have a primary and a hot standby using streaming replication. The hot
>> standby specifies 'hot_standby_feedback=on' with other replication settings
>> set to default.
>>
>> If a vacuum occurs on the primary while pg_dump is dumping a large table,
>> the pg_dump is cancelled, usually with the following error:
>>
>> ERROR: canceling statement due to conflict with recovery
>> DETAIL: User was holding shared buffer pin for too long.
>
> Maybe I'm missing something, but ISTM that hot_standby_feedback doesn't
> eliminate the query cancels caused by buffer pin lock which you encountered.
> It eliminates only the query cancels caused by cleanup of rows. So you might
> need to set max_standby_streaming_delay to -1, to avoid query cancels.
I have also seen the following (but only on production, not with my test case):
ERROR: canceling statement due to conflict with recovery
DETAIL: User was holding a relation lock for too long.
If you are correct, it seems impossible with 9.1 to have reliable long
transactions on a hot standby without allowing the hot standby to lag
behind by the length of the longest transaction.
I was hoping when the docs state "this parameter can be used to
eliminate query cancels caused by cleanup records" that it would cover
all the background maintenance.
Disabling autovacuum during the backup window would be one work around.
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/