| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: group locking: incomplete patch, just for discussion |
| Date: | 2014-11-20 17:12:12 |
| Message-ID: | 1416503532.2998.231.camel@jeff-desktop |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2014-11-20 at 11:22 -0500, Robert Haas wrote:
> 2. Propagate pre-existing locks from the user backend to all the workers.
>
> I initially proposed #1, but now I think #2 solves more of the
> problems for less code.
OK. The primary concern with that is unintended consequences. But it's
reasonable for you to ask for something more concrete. I will think on
this more.
A few things I'm thinking about now:
* What do you mean by "pre-existing"? Locks existing prior to what
event? (I don't think that's exactly what you meant.)
* What's the conceptual difference between granting locks that would
otherwise conflict with another process in the group (which is what this
proposal is about) and having exactly the same set of locks? Is there
any?
* Let's say you have processes A1 and A2 in one group, and B. A1 and B
both have an AccessShare lock, and A2 tries to acquire an exclusive
lock. B is waiting on A2. That's still a deadlock, right?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-11-20 17:19:54 | Re: group locking: incomplete patch, just for discussion |
| Previous Message | Heikki Linnakangas | 2014-11-20 17:06:38 | Re: WAL format and API changes (9.5) |