| From: | Konstantin Evteev <konst583(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Using standby for read-only queries in production and DML operations on primary. |
| Date: | 2018-02-14 11:21:37 |
| Message-ID: | CAAqA9PT4THfg5ytsj7sLyd4g-4vo5xEfBxYoB-pC8G4MsEskAg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hello!
There is a problem connected with using standby for read-only queries in
production and DML operations on primary.
On primary we use alter table command with statement_timeout and
deadlock_timeout values about 10 - 50 ms with rertry until it would
successfully be executed.
But the same locks would be replayed on standby - without timeouts.
So there we see locks and our standby pools are overflowed - it is an
incident/lsr/problem for users.
There is a workaround to have 2 standbies:
Before altering table on primary pause 1st standby and switch read only
queries to it.
Then alter table and wait until it would be replicated to 2-nd standby.
Switch read only queries to 2-nd standby and remove pause from 1-st.
--
Konstantin Evteev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Edson Carlos Ericksson Richter | 2018-02-14 13:00:28 | Re: execute block like Firebird does |
| Previous Message | Alban Hertroys | 2018-02-14 08:22:11 | Re: Table Partitioning: Sequence jump issue 10 in 10 with serial datatype |