Re: [HACKERS] Correction to comment regarding atomicity of an operation

2012-09-12 Thread Gurjeet Singh
On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch wrote: > On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote: > > Thinking a bit more about the need for locks, I guess even the shared > > variables whose read/write ops are considered atomic need to be protected > > by locks so that the effe

Re: [HACKERS] Correction to comment regarding atomicity of an operation

2012-09-12 Thread Noah Misch
On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote: > Thinking a bit more about the need for locks, I guess even the shared > variables whose read/write ops are considered atomic need to be protected > by locks so that the effects of NUMA architectures can be mitigated. src/backend/stor

Re: [HACKERS] Correction to comment regarding atomicity of an operation

2012-09-12 Thread Gurjeet Singh
On Tue, Sep 11, 2012 at 11:19 PM, Amit Kapila wrote: > On Wednesday, September 12, 2012 5:33 AM Gurjeet Singh wrote: > > ** ** > > ** ** > > > This comment in UpdateFullPageWrites() seems to be inaccurate: > > > * It's safe to check the shared full_page_writes without the lock, > >* b

Re: [HACKERS] Correction to comment regarding atomicity of an operation

2012-09-11 Thread Amit Kapila
On Wednesday, September 12, 2012 5:33 AM Gurjeet Singh wrote: > This comment in UpdateFullPageWrites() seems to be inaccurate: > * It's safe to check the shared full_page_writes without the lock, >* because we assume that there is no concurrently running process which > * can u

[HACKERS] Correction to comment regarding atomicity of an operation

2012-09-11 Thread Gurjeet Singh
This comment in UpdateFullPageWrites() seems to be inaccurate: * It's safe to check the shared full_page_writes without the lock, * because we assume that there is no concurrently running process which * can update it. That assumption does not hold on any sane SMP system. I think