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.