Re: tx canceled on standby despite infinite max_standby_streaming_delay

Поиск
Список
Период
Сортировка
От Jay Howard
Тема Re: tx canceled on standby despite infinite max_standby_streaming_delay
Дата
Msg-id CAAcb1Yzwo4v5tcNp0BnEzhpeGULixC0831BTjfGAN_eSRdq-Cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tx canceled on standby despite infinite max_standby_streaming_delay  (Venkata Balaji N <nag1010@gmail.com>)
Ответы Re: tx canceled on standby despite infinite max_standby_streaming_delay  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
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@gmail.com> wrote:

On Sat, May 14, 2016 at 12:27 PM, Jay Howard <jhoward@alumni.utexas.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
 


В списке pgsql-general по дате отправления:

Предыдущее
От: Charles Clavadetscher
Дата:
Сообщение: Ascii Elephant for text based protocols
Следующее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Ascii Elephant for text based protocols