| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
| Date: | 2016-02-17 01:37:41 |
| Message-ID: | CAMsr+YFqJCNBjO-T9vsyRQshDN4kRHhhkia_jcYxnRKzL6zocA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 14 February 2016 at 08:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> The concept of a
> lock group is formally separate from the concept of a parallel group
> created by a ParallelContext, but it is not clear that there will ever
> be any other context in which a lock group will be a good idea.
Just coming back to this in terms of what Stephen and I raised: Robert, do
you think this design as it stands can handle cases where a normal
standalone backend gets promoted to a lock-group leader that others can
then join?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-02-17 02:08:37 | pgsql: Make plpython cope with funny characters in function names. |
| Previous Message | Tom Lane | 2016-02-16 20:54:50 | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2016-02-17 02:19:55 | Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
| Previous Message | Craig Ringer | 2016-02-17 01:33:56 | Re: pglogical - logical replication contrib module |