Should XLogInsert() be done only inside a critical section?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Should XLogInsert() be done only inside a critical section?
Date: 2016-04-20 20:44:58
Message-ID: 26698.1461185098@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Over in <17456(dot)1460832307(at)sss(dot)pgh(dot)pa(dot)us> I speculated about whether
we should be enforcing that WAL insertion happen only inside critical
sections. We don't currently, and a survey of the backend says that
there are quite a few calls that aren't inside critical sections.
But there are at least two good reasons why we should, IMO:

1. It's not very clear that XLogInsert will recover cleanly if it's
invoked outside a critical section and hits a failure. Certainly,
if we allow such usage, then every potential error inside that code
has to be analyzed under both critical-section and normal rules.

2. With no such check, it's quite easy for calling code to forget to
create a critical section around code stanzas where one is *necessary*
(because you're changing shared-buffer contents).

Both of these points represent pretty clear hazards for introduction
of future bugs, whether or not there are any such bugs today.

As against this, it could be argued that adding critical sections where
they're not absolutely necessary must make crashing failures more probable
than they need to be. But first you'd have to prove that they're not
absolutely necessary, which I'm unsure about because of point #1.

Anyway, I went through our tree and added START/END_CRIT_SECTION calls
around all XLogInsert calls that could currently be reached without one;
see attached. Since this potentially breaks third-party code I would
not propose back-patching it, but I think it's reasonable to propose
applying it to HEAD.

Thoughts?

regards, tom lane

Attachment Content-Type Size
xloginsert-must-be-in-critical-section.patch text/x-diff 20.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-04-20 21:16:43 Re: Proposal: Remove regress-python3-mangle.mk
Previous Message Yury Zhuravlev 2016-04-20 20:03:07 Re: Proposal: Remove regress-python3-mangle.mk