Date: Fri, 20 Feb 2015 22:48:09 +0000 (UTC)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
To: Drazen Kacar <drazen.kacar@oradian.com>,
 "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Message-ID: <1328517318.859752.1424472489522.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
 <CAFxrd3tm_1_4UUL4ULnPzB04JJbvM1FdHpOMuF3fC7dW_8kJ2Q@mail.gmail.com>
References: 
 <CAFxrd3tm_1_4UUL4ULnPzB04JJbvM1FdHpOMuF3fC7dW_8kJ2Q@mail.gmail.com>
Subject: Re: Query cancellation on hot standby because of buffer
 pins
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Length: 1116
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Drazen Kacar <drazen.kacar@oradian.com> wrote:

> I'm seeing query cancellation on hot standby (Postgres 9.3.4,
> configured with hot_standby_feedback=on) because of buffer pins
> being held for too long.
>
> Database message looks like this:
>
> ERROR: canceling statement due to conflict with recovery
> DETAIL: User was holding shared buffer pin for too long.
> STATEMENT: ...

It would be helpful to see what that statement was that you
replaced with the ellipsis.

I you don't already have log_autovacuum_min_duration set to 0 (or
something very close to it) on the primary, I recommend you set
that; it would be useful to see if this corresponds to a vacuum on
the table.

What is your maintenance_work_mem setting on the primary? Does
increasing it change the behavior? (You may want to jack that up
really high for diagnostic purposes.)

If you can associate the problem with a particular table, seeing
the definition of that table wouldn't hurt, either.


Oh, and please update to 9.3.6; there are some nasty bugs fixed.


--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin