Re: tx canceled on standby despite infinite max_standby_streaming_delay

>
> Do you have hot_standby_feedback set to "on" ?
>

It was off. Will research that. Thank you!

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.
>

It's set to the default, which is 30 seconds. For some reason I thought
setting "max_standby_streaming_delay" to -1 would be sufficient.

At a high level, what's the difference between the "archive_delay" and
"streaming_delay"? I will read up on streaming replication in the mean
time.

On Sat, May 14, 2016 at 8:20 PM, Venkata Balaji N <nag1010(at)gmail(dot)com> wrote:

>
> 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
>
>
>