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

At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane wrote in <24181.1465328...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in > > <17504.1465225...@sss.pgh.pa.us> > >> Uh,

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

Kyotaro HORIGUCHI writes: > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in > <17504.1465225...@sss.pgh.pa.us> >> Uh, what? PQcancel is very carefully coded so that it's safe to use >> in a signal handler. If it's doing mallocs

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

At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in <17504.1465225...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in > > <11515.1464961...@sss.pgh.pa.us> > >> I

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

Kyotaro HORIGUCHI writes: > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in > <11515.1464961...@sss.pgh.pa.us> >> I think that this one: >>> If the target thread is allocating memory from the heap, the heap >>> lock will not be

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

How about silencing the workers on termination? # Build on Windows (with VC?) is very time consuming... At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in <11515.1464961...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > For sure, any of

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

Kyotaro HORIGUCHI writes: > For sure, any of the "dangers" of TerminateThread don't matter > for this case. I think that this one: >> If the target thread is allocating memory from the heap, the heap >> lock will not be released. is potentially a hazard, which

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

At Thu, 2 Jun 2016 12:17:11 -0400, Alvaro Herrera wrote in <20160602161711.GA239156@alvherre.pgsql> > Tom Lane wrote: > > Kyotaro HORIGUCHI writes: > > > Apart from the invalid snapshot problem, I looked the patch > > > previously

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

Tom Lane wrote: > Kyotaro HORIGUCHI writes: > > Apart from the invalid snapshot problem, I looked the patch > > previously mentioned mainly for Windows. > > Thanks for looking! > > > Even though the threads started by beginthread cannot be > > terminated cleanly

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

Kyotaro HORIGUCHI writes: > Apart from the invalid snapshot problem, I looked the patch > previously mentioned mainly for Windows. Thanks for looking! > Even though the threads started by beginthread cannot be > terminated cleanly from outside, but the whole

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

Apart from the invalid snapshot problem, I looked the patch previously mentioned mainly for Windows. At Tue, 31 May 2016 12:29:50 -0400, Tom Lane wrote in <7445.1464712...@sss.pgh.pa.us> > In the patch I posted yesterday, I reversed the order of those two > steps, which

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

At Tue, 31 May 2016 12:29:50 -0400, Tom Lane wrote in <7445.1464712...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in > > <14603.1464369...@sss.pgh.pa.us> > >>

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

Kyotaro HORIGUCHI writes: > At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in > <14603.1464369...@sss.pgh.pa.us> >> Kyotaro HORIGUCHI writes: >>> By the way, the reason of the "invalid snapshot

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

Hello, At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in <14603.1464369...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > By the way, the reason of the "invalid snapshot identifier" is > > that some worker threads try to use it after the

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

Amit Kapila writes: > On Sat, May 28, 2016 at 5:06 AM, Tom Lane wrote: >> It looks like the vacuumdb.c version of this code actually is tied >> into an interrupt handler, but whoever copied it for parallel.c just >> ripped out the CancelRequested

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

On Sat, May 28, 2016 at 5:06 AM, Tom Lane wrote: > > Alvaro Herrera writes: > > Regarding this: > >> + * XXX this certainly looks useless, why not just wait indefinitely? > > > There's another select_loop() in vacuumdb.c suggesting that

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

Alvaro Herrera writes: > Regarding this: >> + * XXX this certainly looks useless, why not just wait >> indefinitely? > There's another select_loop() in vacuumdb.c suggesting that the timeout > is used to check for cancel requests; as I understood while

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

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

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

I wrote: >> BTW, after having spent the afternoon staring at it, I will assert with >> confidence that pg_dump/parallel.c is an embarrassment to the project. > I've done a bit of work on a cosmetic cleanup patch, but don't have > anything to show yet. Attached is the threatened cosmetic cleanup

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

Kyotaro HORIGUCHI writes: > By the way, the reason of the "invalid snapshot identifier" is > that some worker threads try to use it after the connection on > the first worker closed. ... BTW, I don't quite see what the issue is there. The snapshot is exported

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

At Thu, 26 May 2016 10:53:47 -0400, Tom Lane wrote in <5237.1464274...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > >> Next, I got the following behavior for the following command, > >> then freeze. Maybe stopping at the same point with the

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

At Thu, 26 May 2016 12:15:29 -0400, Tom Lane wrote in <8273.1464279...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Wed, 25 May 2016 10:11:28 -0400, Tom Lane wrote in > > <24577.1464185...@sss.pgh.pa.us> > >> The

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

Kyotaro HORIGUCHI writes: > At Wed, 25 May 2016 10:11:28 -0400, Tom Lane wrote in > <24577.1464185...@sss.pgh.pa.us> >> The only case >> that is certain to work is switches before non-switch arguments, and so >> we should not give any

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

Kyotaro HORIGUCHI writes: >> Next, I got the following behavior for the following command, >> then freeze. Maybe stopping at the same point with the next >> paragraph but I'm not sure. The same thing occurs this patch on >> top of the current master but doesn't on

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

> Sounds reasonable. I look into this further. I looked into that and found one problem in the patch. > Next, I got the following behavior for the following command, > then freeze. Maybe stopping at the same point with the next > paragraph but I'm not sure. The same thing occurs this patch on >

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

At Wed, 25 May 2016 10:11:28 -0400, Tom Lane wrote in <24577.1464185...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > I tried it on Windows 7/64 but first of all, I'm surprised to see > > that the following command line gets an error but it

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

Kyotaro HORIGUCHI writes: > I tried it on Windows 7/64 but first of all, I'm surprised to see > that the following command line gets an error but it would be > fine because it is consistent with what is written in the manual. > | >pg_dump

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

At Wed, 25 May 2016 00:15:57 -0400, Tom Lane wrote in <3149.1464149...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Shouldn't archive_close_connection have an assertion (si->AHX != > > NULL) instead of checking "if (si->AHX)" in each path?

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

Kyotaro HORIGUCHI writes: > Shouldn't archive_close_connection have an assertion (si->AHX != > NULL) instead of checking "if (si->AHX)" in each path? I thought about that but didn't see any really good argument for it. It'd be making that function dependent on

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

Hello, # Note for convenience for others: The commit fixing the original # issue is 1aa41e3eae3746e05d0e23286ac740a9a6cee7df. At Mon, 23 May 2016 13:40:30 -0400, Tom Lane wrote in <1336.1464025...@sss.pgh.pa.us> > I wrote: > >> ... the pg_dump process has crashed with a

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

I wrote: >> ... the pg_dump process has crashed with a SIGPIPE without printing >> any message whatsoever, and without coming anywhere near finishing the >> dump. > Attached is a proposed patch for this. It reverts exit_horribly() to > what it used to be pre-9.3, ie just print the message on

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

[ getting back to a complaint I made in December ] I wrote: > ... the pg_dump process has crashed with a SIGPIPE without printing > any message whatsoever, and without coming anywhere near finishing the > dump. > A bit of investigation says that this is because somebody had the bright > idea

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

On 12/23/2015 10:16 AM, Tom Lane wrote: Depending on timing, this scheme might accidentally fail to fail, but it seems fragile as can be. I would bet that it's prone to deadlocks, quite aside from the SIGPIPE problem. Considering how amazingly ugly the underlying code is (exit_horribly is in

[HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

I was in process of testing the proposed patch for bug #13727, and I found that at least on my Linux box, this is the behavior in the failure case without the patch: $ pg_dump "postgres://postgres:phonypassword@localhost/regression" --jobs=9 -Fd -f testdump $ echo $? 141 $ ls testdump toc.dat