From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndQuadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE lock strength reduction patch is unsafe |
Date: | 2014-03-03 15:53:20 |
Message-ID: | 8223.1393862000@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 3 March 2014 15:19, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> What I'm
>> really concerned about is whether there are other things like the
>> SnapshotNow issues that can cause stuff to halt and catch fire. I
>> don't know whether there are or are not, but that's my concern.
> Of course its a concern, I feel it also. But that's why we have beta
> period to handle the unknowns.
I have exactly zero faith that beta testing would catch low-probability
problems in this area. What's needed, and hasn't happened AFAIK, is
detailed study of the patch by assorted senior hackers.
> The question is are there any specific areas of concern here? If not,
> then we commit because we've done a lot of work on it and at the
> moment the balance is high benefit to users against a non-specific
> feeling of risk.
This is backwards. The default decision around here has never been
to commit when in doubt.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-03-03 16:06:45 | Re: ALTER TABLE lock strength reduction patch is unsafe |
Previous Message | Robert Haas | 2014-03-03 15:53:04 | Re: Performance Improvement by reducing WAL for Update Operation |