Tom Lane wrote:
Unfortunately, there isn't any pre-existing lock that will serve.
A transaction that is between XLogInsert'ing its COMMIT record and
updating the shared pg_clog data area does not hold any lock that
could be used to prevent a checkpoint from starting. (Or it didn't
until yesterday'
"Min Xu (Hsu)" <[EMAIL PROTECTED]> writes:
> 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 opera
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 sta
While investigating Satoshi Okada's bug report here
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00510.php
I realized that it actually represents a crash-safety risk that has
existed since 7.2.
Allow me to refresh your memory about the principles of write-ahead
logging. The one that e
