Re: [HACKERS] Interval for launching the table sync worker
В списке pgsql-hackers по дате отправления:
| От | Peter Eisentraut |
|---|---|
| Тема | Re: [HACKERS] Interval for launching the table sync worker |
| Дата | |
| Msg-id | 0c475de6-cbc2-1ec6-2b40-6a21113807de@2ndquadrant.com обсуждение |
| Ответ на | Re: [HACKERS] Interval for launching the table sync worker (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: [HACKERS] Interval for launching the table sync worker
Re: [HACKERS] Interval for launching the table sync worker |
| Список | pgsql-hackers |
On 4/13/17 06:23, Masahiko Sawada wrote: > Attached the latest patch. It didn't actually necessary to change > GetSubscriptionNotReadyRelations. I just changed the logic refreshing > the sync table state list. I think this was the right direction, but then I got worried about having a loop within a loop to copy over the last start times. If you have very many tables, that could be a big nested loop. Here is an alternative proposal to store the last start times in a hash table. (We also might want to lower the interval for the test suite, because there are intentional failures in there, and this patch or one like it will cause the tests to run a few seconds longer.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера