Hi,

When I created the conflict between recovery and many read-only
transactions in the standby server for test purpose, I found that the
keyword "waiting" disappeared from PS display for just a moment
even though the conflict had not been resolved yet. This seems
strange to me.

This problem happens because ResolveRecoveryConflictWithVirtualXIDs
resets PS display for each read-only transactions that recovery
waits for. Why do we need to reset that each time even though
the conflict has not been resolved yet? The attached patch
suppresses such a needless reset. Comments?

BTW, ResolveRecoveryConflictWithVirtualXIDs calls
pgstat_report_waiting(), which is also needless since the startup
process doesn't have the shared memory entry (i.e., MyBEEntry)
for pg_stat_activity. The attached patch removes that call.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Search Discussions

  • Simon Riggs at Dec 11, 2010 at 2:31 pm

    On Thu, 2010-12-09 at 22:13 +0900, Fujii Masao wrote:

    When I created the conflict between recovery and many read-only
    transactions in the standby server for test purpose, I found that the
    keyword "waiting" disappeared from PS display for just a moment
    even though the conflict had not been resolved yet. This seems
    strange to me.

    This problem happens because ResolveRecoveryConflictWithVirtualXIDs
    resets PS display for each read-only transactions that recovery
    waits for. Why do we need to reset that each time even though
    the conflict has not been resolved yet? The attached patch
    suppresses such a needless reset. Comments?
    The reset occurs at most each 500ms, so not much problem there.

    But if it annoys you, it seems OK to change it. Don't see a reason to backpatch though?
    BTW, ResolveRecoveryConflictWithVirtualXIDs calls
    pgstat_report_waiting(), which is also needless since the startup
    process doesn't have the shared memory entry (i.e., MyBEEntry)
    for pg_stat_activity. The attached patch removes that call.
    IIRC that wasn't added by me, so not sure why its there. Not harming anything either.

    --
    Simon Riggs http://www.2ndQuadrant.com/books/
    PostgreSQL Development, 24x7 Support, Training and Services
  • Fujii Masao at Dec 13, 2010 at 3:06 am

    On Sat, Dec 11, 2010 at 11:28 PM, Simon Riggs wrote:
    This problem happens because ResolveRecoveryConflictWithVirtualXIDs
    resets PS display for each read-only transactions that recovery
    waits for. Why do we need to reset that each time even though
    the conflict has not been resolved yet? The attached patch
    suppresses such a needless reset. Comments?
    The reset occurs at most each 500ms, so not much problem there.

    But if it annoys you, it seems OK to change it. Don't see a reason to backpatch though?
    I think that It's worth backpatch to prevent users who observe the
    occurrence of the query conflicts carefully for testing 9.0 from
    getting confusing.

    Regards,

    --
    Fujii Masao
    NIPPON TELEGRAPH AND TELEPHONE CORPORATION
    NTT Open Source Software Center
  • Robert Haas at Dec 17, 2010 at 1:35 pm

    On Sun, Dec 12, 2010 at 10:06 PM, Fujii Masao wrote:
    But if it annoys you, it seems OK to change it. Don't see a reason to backpatch though?
    I think that It's worth backpatch to prevent users who observe the
    occurrence of the query conflicts carefully for testing 9.0 from
    getting confusing.
    I don't think this is important enough to back-patch, but it does seem
    like a good idea in general, so committed, but just to the master
    branch.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 9, '10 at 1:13p
activeDec 17, '10 at 1:35p
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase