mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 03:53:24 +02:00
Use TransactionIdIsInProgress, then TransactionIdDidCommit, to distinguish whether a NOTIFY message's originating transaction is in progress, committed, or aborted. The previous coding could accept a message from a transaction that was still in-progress according to the PGPROC array; if the client were fast enough at starting a new transaction, it might fail to see table rows added/updated by the message-sending transaction. Which of course would usually be the point of receiving the message. We noted this type of race condition long ago in tqual.c, but async.c overlooked it. The race condition probably cannot occur unless there are multiple NOTIFY senders in action, since an individual backend doesn't send NOTIFY signals until well after it's done committing. But if two senders commit in close succession, it's certainly possible that we could see the second sender's message within the race condition window while responding to the signal from the first one. Per bug #9557 from Marko Tiikkaja. This patch is slightly more invasive than what he proposed, since it removes the now-redundant TransactionIdDidAbort call. Back-patch to 9.0, where the current NOTIFY implementation was introduced. |
||
---|---|---|
.. | ||
aggregatecmds.c | ||
alter.c | ||
analyze.c | ||
async.c | ||
cluster.c | ||
collationcmds.c | ||
comment.c | ||
constraint.c | ||
conversioncmds.c | ||
copy.c | ||
createas.c | ||
dbcommands.c | ||
define.c | ||
discard.c | ||
dropcmds.c | ||
event_trigger.c | ||
explain.c | ||
extension.c | ||
foreigncmds.c | ||
functioncmds.c | ||
indexcmds.c | ||
lockcmds.c | ||
Makefile | ||
matview.c | ||
opclasscmds.c | ||
operatorcmds.c | ||
portalcmds.c | ||
prepare.c | ||
proclang.c | ||
schemacmds.c | ||
seclabel.c | ||
sequence.c | ||
tablecmds.c | ||
tablespace.c | ||
trigger.c | ||
tsearchcmds.c | ||
typecmds.c | ||
user.c | ||
vacuum.c | ||
vacuumlazy.c | ||
variable.c | ||
view.c |