Re: Parallel pg_dump's error reporting doesn't work worth squat
От | Alvaro Herrera |
---|---|
Тема | Re: Parallel pg_dump's error reporting doesn't work worth squat |
Дата | |
Msg-id | 20160527225918.GA736387@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Parallel pg_dump's error reporting doesn't work worth squat (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Parallel pg_dump's error reporting doesn't work worth squat
|
Список | pgsql-hackers |
Regarding this: > *************** select_loop(int maxFd, fd_set *workerset > *** 1092,1104 **** > --- 1150,1160 ---- > fd_set saveSet = *workerset; > > #ifdef WIN32 > for (;;) > { > /* > * sleep a quarter of a second before checking if we should terminate. > + * XXX this certainly looks useless, why not just wait indefinitely? > */ > struct timeval tv = {0, 250000}; > There's another select_loop() in vacuumdb.c suggesting that the timeout is used to check for cancel requests; as I understood while working on the vacuumdb changes, select() is not interrupted in that case. I suppose that means it's necessary here also. But on the other hand it's quite possible that the original developer just copied what was in pg_dump and that it's not actually needed; if that's the case, perhaps it's better to rip it out from both places. https://www.postgresql.org/message-id/20150122174601.GB1663@alvh.no-ip.org -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: