From: | Venkata Balaji N <nag1010(at)gmail(dot)com> |
---|---|
To: | Jay Howard <jhoward(at)alumni(dot)utexas(dot)net> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: tx canceled on standby despite infinite max_standby_streaming_delay |
Date: | 2016-05-15 01:20:27 |
Message-ID: | CAEyp7J981eSgASkOZRmm-wtn0PowBp2DG-zc0d08a0eBDht5Rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, May 14, 2016 at 12:27 PM, Jay Howard <jhoward(at)alumni(dot)utexas(dot)net>
wrote:
> I'm seeing long-running transactions (pg_dump) canceled on the standby
> when there are a lot of inserts happening on the master. This despite my
> having set max_standby_streaming_delay to -1 on the standby.
>
Do you have hot_standby_feedback set to "on" ?
What is the parameter max_standby_archive_delay configured to ? This will
pause WAL archives from being applied when queries are executed on the
standby database.
> Why might that happen?
>
> This is pg 9.3.12. When it happens I see:
>
> pg_dump: Dumping the contents of table "TABLE" failed: PQgetResult()
> failed.
> pg_dump: Error message from server: ERROR: canceling statement due to
> conflict with recovery
> DETAIL: User query might have needed to see row versions that must be
> removed.
> pg_dump: The command was: COPY public.TABLE (COLUMNS) TO stdout;
>
I suspect this is due to the clean up by VACUUM on primary.
Regards,
Venkata B N
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Venkata Balaji N | 2016-05-15 08:33:38 | Re: Streaming replication, master recycling |
Previous Message | David G. Johnston | 2016-05-14 21:44:48 | Re: How to use row values as function parameters |