On Sat, Mar 26, 2016 at 5:04 AM, David Steele <da...@pgmasters.net> wrote: > Hi Thomas, > > On 3/13/16 8:20 PM, Thomas Munro wrote: > >> <...> I will have another look at this in >> a few days but for now I need to do some other things, so I'm posting >> these observations in case they are in some way helpful... > > > It's not clear to me what state this patch should be in but the thread has > been idle for over a week. > > Have you had the chance to take a look as you indicated above?
Here's a summary of where we are today: 1. It looks like we have general consensus that this is a problem and that we should fix it, but not about whether a change should be backpatched, if/when we arrive at an acceptable patch. 2. We have a 1 line patch (+ comments and isolation tests) which covers the cases that I've heard complaints about. These cases all involve either checking if a value already exists with SELECT or computing a new value based on existing values with something like SELECT MAX(id) + 1 and then inserting it in concurrent transactions. 3. In the process of designing isolation tests, I found a case that doesn't cover: where one session simply inserts, while the another checks explicitly whether it's OK to insert, finds that it is, and then tries to do so. I haven't figured out how to detect an SSI conflict before the UCV in this case. Realistically I'm not going to have a solution to the third problem before the 31st. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
