Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reset 'ps' display just once when resolving VXID conflicts.

  1. pgsql: Reset 'ps' display just once when resolving VXID conflicts.

    Robert Haas <rhaas@postgresql.org> — 2010-12-17T13:34:32Z

    Reset 'ps' display just once when resolving VXID conflicts.

This prevents the word "waiting" from briefly disappearing from the ps
status line when ResolveRecoveryConflictWithVirtualXIDs begins a new
iteration of the outer loop.

Along the way, remove some useless pgstat_report_waiting() calls;
the startup process doesn't appear in pg_stat_activity.

Fujii Masao

Branch
------
master

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=611fed371227f430e71d0ff7fed037f1006b410d

Modified Files
--------------
src/backend/storage/ipc/standby.c |   30 +++++++++++++-----------------
1 files changed, 13 insertions(+), 17 deletions(-)

  2. Re: pgsql: Reset 'ps' display just once when resolving VXID conflicts.

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-12-17T14:52:04Z

    Robert Haas <rhaas@postgresql.org> writes:
> Reset 'ps' display just once when resolving VXID conflicts.
> This prevents the word "waiting" from briefly disappearing from the ps
> status line when ResolveRecoveryConflictWithVirtualXIDs begins a new
> iteration of the outer loop.

I imagine the reason for the original coding was to avoid a useless
gettimeofday kernel call in the common case that there are no
conflicting xacts to wait for.  Could we restore that behavior?

			regards, tom lane

  3. Re: [COMMITTERS] pgsql: Reset 'ps' display just once when resolving VXID conflicts.

    Robert Haas <robertmhaas@gmail.com> — 2010-12-17T16:13:51Z

    On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <rhaas@postgresql.org> writes:
>> Reset 'ps' display just once when resolving VXID conflicts.
>> This prevents the word "waiting" from briefly disappearing from the ps
>> status line when ResolveRecoveryConflictWithVirtualXIDs begins a new
>> iteration of the outer loop.
>
> I imagine the reason for the original coding was to avoid a useless
> gettimeofday kernel call in the common case that there are no
> conflicting xacts to wait for.  Could we restore that behavior?

Something like the attached?

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

  4. Re: [COMMITTERS] pgsql: Reset 'ps' display just once when resolving VXID conflicts.

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-12-17T16:20:27Z

    Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I imagine the reason for the original coding was to avoid a useless
>> gettimeofday kernel call in the common case that there are no
>> conflicting xacts to wait for. Could we restore that behavior?

> Something like the attached?

I would just add the return-at-the-top.  Changing the loop logic is
not necessary --- the loop test is cheap.

			regards, tom lane

  5. Re: [COMMITTERS] pgsql: Reset 'ps' display just once when resolving VXID conflicts.

    Robert Haas <robertmhaas@gmail.com> — 2010-12-17T16:34:48Z

    On Fri, Dec 17, 2010 at 11:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I imagine the reason for the original coding was to avoid a useless
>>> gettimeofday kernel call in the common case that there are no
>>> conflicting xacts to wait for.  Could we restore that behavior?
>
>> Something like the attached?
>
> I would just add the return-at-the-top.  Changing the loop logic is
> not necessary --- the loop test is cheap.

Hmm... that's a fine bit of hairsplitting, but OK.

Done that way, then.

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