Re: Parallel pg_dump's error reporting doesn't work worth squat

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

In response to

Responses

Browse pgsql-hackers by date

  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()