>Following question may be redundant. Just a confirmation.
>
>Deadlock example is catstrophic while it's rather a rare event.
>On the other hand, LockBufferForCleanup() can cause another
>problem.
>
> * One idle pin-holder backend can freeze startup process().
>
>This problem is not catstrophic, but it seems a similar problem
>which StandbyAcquireAccessExclusiveLock() tries to avoid.
>
>...Is this the problem you call "general problem" above ?
>
Here is a typical scenario in which startup process freezes until the end of
a certain transaction.
1. Consider a table A, which has pages with HOT chain tuples old enough to be
vacuumed.
2. Xact 1 in the standby node declares a cursor for table A, fetches the page
which contains the HOT chain, and becomes idle for some reason.
3. Xact 2 in the active node reads the table A and calls heap_page_prune()
for HOT pruning, which create XLOG_HEAP2_CLEAN record.
4. Startup process tries to redo XLOG_HEAP2_CLEAN record, calls
LockBufferForCleanup() and freezes until the Xact 1 ends.
Note that with HOT pruning, we do not need VACUUM command, and most tables,
which has long history of updation, can be table A.
--
Hiroyuki YAMADA
Kokolink Corporation
yam...@kokolink.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
