| From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | simon(at)2ndquadrant(dot)com |
| Cc: | ishii(at)sraoss(dot)co(dot)jp, vik(at)2ndquadrant(dot)fr, chris(dot)travers(at)gmail(dot)com, scottm(at)openscg(dot)com, achill(at)matrix(dot)gatewaynet(dot)com, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Uber migrated from Postgres to MySQL |
| Date: | 2016-08-06 01:36:37 |
| Message-ID: | 20160806.103637.560922897175066279.t-ishii@sraoss.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> Yes, the VACUUM truncation is still an issue. But statements are
> retryable, just like deadlocks.
>
> Unfo the truncation logic always kicks in or small tables of less than
> 16 blocks. It's more forgiving on bigger tables.
Oh, I didn't know that. Thanks for the info.
> Maybe we could defer the truncation on the standby in some cases.
Do we want to add this to the TODO list?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Colin Morelli | 2016-08-06 03:17:27 | Logical Decoding Failover |
| Previous Message | Christian Ohler | 2016-08-05 21:24:28 | Re: Detecting if current transaction is modifying the database |