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 <robertmh...@gmail.com
<mailto:robertmh...@gmail.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/>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index ec5328e..199f38a 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -657,7 +657,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<listitem>
<para>
<literal>Lock</>: The backend is waiting for a heavyweight lock.
- Heayweight locks, also known as lock manager locks or simply locks,
+ Heavyweight locks, also known as lock manager locks or simply locks,
primarily protect SQL-visible objects such as tables. However,
they are also used to ensure mutual exclusion for certain internal
operations such as relation extension. <literal>wait_event</> will
@@ -965,7 +965,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<row>
<entry morerows="15"><literal>LWLockTranche</></entry>
<entry><literal>clog</></entry>
- <entry>Waiting for I/O on a clog (transcation status) buffer.</entry>
+ <entry>Waiting for I/O on a clog (transaction status) buffer.</entry>
</row>
<row>
<entry><literal>commit_timestamp</></entry>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
