From: | Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Date: | 2016-03-15 13:17:10 |
Message-ID: | 56E80B56.5070308@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Here's a small docpatch to fix two typos in the new documentation.
Regards,
Thomas
Le 11/03/2016 07:19, Amit Kapila a écrit :
> On Fri, Mar 11, 2016 at 12:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com
> <mailto:robertmhaas(at)gmail(dot)com>> wrote:
> >
> >
> > Committed with some further editing. In particular, the way you
> > determined whether we could safely access the tranche information for
> > any given ID was wrong; please check over what I did and make sure
> > that isn't also wrong.
> >
>
> There are few typos which I have tried to fix with the attached
> patch. Can you tell me what was wrong with the way it was done in patch?
>
>
> @@ -4541,9 +4542,10 @@ AbortSubTransaction(void)
> */
> LWLockReleaseAll();
> +pgstat_report_wait_end();
> +pgstat_progress_end_command();
> AbortBufferIO();
> UnlockBuffers();
> -pgstat_progress_end_command();
> /* Reset WAL record construction state */
> XLogResetInsertion();
> @@ -4653,6 +4655,9 @@ AbortSubTransaction(void)
> */
> XactReadOnly = s->prevXactReadOnly;
> +/* Report wait end here, when there is no further possibility of wait */
> +pgstat_report_wait_end();
> +
> RESUME_INTERRUPTS();
> }
>
> AbortSubTransaction() does call pgstat_report_wait_end() twice, is
> this intentional? I have kept it in the end because there is a chance
> that in between API's can again set the state to wait and also by that
> time we have not released buffer pins and heavyweight locks, so not
> sure if it makes sense to report wait end at that stage. I have
> noticed that in WaitOnLock(), on error the wait end is set, but now
> again thinking on it, it seems it will be better to set it in
> AbortTransaction/AbortSubTransaction at end. What do you think?
>
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>
>
>
Attachment | Content-Type | Size |
---|---|---|
waitevent_docpatch.diff | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-03-15 13:18:30 | Re: Minor bug affecting ON CONFLICT lock wait log messages |
Previous Message | Craig Ringer | 2016-03-15 13:04:12 | Re: Timeline following for logical slots |