Tom Lane wrote:
While investigating Satoshi Okada's bug report here
...
What I am thinking of doing to fix the problem is to introduce
a new LWLock that RecordTransactionCommit will take a shared lock on
before writing its WAL record, and not release until it has updated
pg_clog. Checkpoint start will acquire the lock exclusively just long
enough to do its step 1 (establish REDO point). This is slightly
annoying since it means one more high-traffic lock to grab during
commit, but I don't see any other good solution.
Please forgive me to give my potentially irrelevant comments. I am not too familiar with the internals of the postgresql.
It seems to me this is an interesting phenomena of interactions between frequent events of transaction commits and infrequent events of system checkpoints. A potential alternative solution to adding a new shared lock to the frequent commit operation is to let the infrequent checkpoint operation take more overhead. I suppose acquiring/releasing an extra lock for each commit would incur extra performance overhead, even when the lock is not contented. On the other hand, let the checkpoing operation acquire some existing locks (exclusively) to effectively disallowing committing transactions to interfere with the checkpoint process might be a better solution since it incur higher overhead only when necessary.
Of course, this after all might be "pre-mature" optimization. Just my $0.02.
Thanks,
-Min
-- Rong: Life is all about running after a busy agenda! How frustrating! Min: That's right! You can either deal with things as quick as possible or to create less items on the agenda to begin with.
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
