From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: group locking: incomplete patch, just for discussion |
Date: | 2014-11-03 18:06:39 |
Message-ID: | CA+TgmoaHf7uBLKvX1Uy6EmMvdA8MDAWH2kFBmvY+Eht=stGiOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 3, 2014 at 1:02 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> OK, I think I'm happy with this as a general point.
Cool!
> How will we automatically test this code?
Good question. I can see two possible approaches:
1. We write a test_group_locking harness along the lines of
test_shm_mq and test_decoding and put that in contrib.
2. We wait until higher-level facilities built on top of this are
available and get regression test coverage of this code via those
higher-level modules.
Personally, I can't imagine debugging this code without writing some
kind of test harness that only does locking; I don't want my locking
bugs to be mixed with my planner and executor bugs. But I could go
either way on actually putting that code in contrib.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-11-03 18:56:26 | Re: Let's drop two obsolete features which are bear-traps for novices |
Previous Message | Simon Riggs | 2014-11-03 18:02:20 | Re: group locking: incomplete patch, just for discussion |