Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
От | Tom Lane |
---|---|
Тема | Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION |
Дата | |
Msg-id | 29282.1456420806@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > On 2016-02-25 09:51:49 -0500, Tom Lane wrote: >> Marking pgprocno volatile is silly. What *is* missing is this: >> >> - ProcArrayStruct *arrayP = procArray; >> + volatile ProcArrayStruct *arrayP = procArray; > Well, that'll also force arrayP->numProcs to be loaded from memory every > loop iteration. Not sure if we really want that. I think we do. The entire point here is not to assume that that storage isn't changing. > What bothers me about this right now is that we currently write the > pgprocno array with: > memmove(&arrayP->pgprocnos[index + 1], &arrayP->pgprocnos[index], > (arrayP->numProcs - index) * sizeof(int)); > arrayP->pgprocnos[index] = proc->pgprocno; > arrayP->numProcs++; > afaics there's absolutely no guarantee that memmov() will only use > aligned sizeof(int) writes. Ugh. That's a separate problem, but yes, it's a problem. Seems like we can either (1) get rid of that memmove in favor of a handwritten loop, or (2) give up on unlocked access to the pgprocnos array. Which performance hit would you rather take? regards, tom lane
В списке pgsql-bugs по дате отправления: