From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Parallel pg_dump's error reporting doesn't work worth squat |
Date: | 2016-05-27 22:59:18 |
Message-ID: | 20160527225918.GA736387@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-27 23:36:17 | Re: Parallel pg_dump's error reporting doesn't work worth squat |
Previous Message | Alvaro Herrera | 2016-05-27 22:34:10 | new PageAddItemFlags() |