| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [HACKERS] parallel.c oblivion of worker-startup failures | 
| Date: | 2017-12-06 14:54:22 | 
| Message-ID: | 22410.1512572062@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm not in love with that part of the fix; the other parts of that if
> statement are just testing variables, and a function call that takes
> and releases an LWLock is a lot more expensive.  Furthermore, that
> test will often be hit in practice, because we'll often arrive at this
> function before workers have actually finished.  On top of that, we'll
> typically arrive here having already communicated with the worker in
> some way, such as by receiving tuples, which means that in most cases
> we already know that the worker was alive at least at some point, and
> therefore the extra test isn't necessary.  We only need that test, if
> I understand correctly, to cover the failure-to-launch case, which is
> presumably very rare.
Maybe track "worker is known to have launched" in the leader's state
someplace?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ildus Kurbangaliev | 2017-12-06 15:07:16 | Re: [HACKERS] Custom compression methods | 
| Previous Message | Peter Eisentraut | 2017-12-06 14:41:57 | Re: [HACKERS] Transaction control in procedures |