docs: additional subsection for page-level locks in explicit-locking section
Hi,
While reading through the Explicit Locking section of the manual today,
I felt the last paragraph of section 13.3.2. (Row-level Locks) might
merit its own subsection. It talks about page-level locks as distinct
from table- and row-level locks. Then again, it is just one paragraph,
so maybe this was deliberate and/or rejected before (though I couldn't
find prior discussion off-hand). Proposed patch attached.
Cheers,
Michael
--
Michael Banck
Projektleiter / Berater
Tel.: +49 (2161) 4643-171
Fax: +49 (2161) 4643-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Attachments:
postgresql-sgml.difftext/x-patch; charset=UTF-8; name=postgresql-sgml.diffDownload
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 12b7814..84501e0 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1140,6 +1140,9 @@ ERROR: could not serialize access due to read/write dependencies among transact
will result in disk writes.
</para>
+ <sect2 id="locking-pages">
+ <title>Page-level Locks</title>
+
<para>
In addition to table and row locks, page-level share/exclusive locks are
used to control read/write access to table pages in the shared buffer
On Thu, Jul 3, 2014 at 4:34 AM, Michael Banck <michael.banck@credativ.de> wrote:
Hi,
While reading through the Explicit Locking section of the manual today,
I felt the last paragraph of section 13.3.2. (Row-level Locks) might
merit its own subsection. It talks about page-level locks as distinct
from table- and row-level locks. Then again, it is just one paragraph,
so maybe this was deliberate and/or rejected before (though I couldn't
find prior discussion off-hand). Proposed patch attached.
This seems to make sense. Barring objection, I will commit this only in HEAD.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> wrote:
This seems to make sense. Barring objection, I will commit this
only in HEAD.
I'm inclined to think this is a slight improvement, just for the
sake of consistency with peer level information. You probably
already noticed, but the patch as submitted neglects to close the
prior sect2 block before opening the new one.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 4, 2014 at 12:51 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
Fujii Masao <masao.fujii@gmail.com> wrote:
This seems to make sense. Barring objection, I will commit this
only in HEAD.
Committed.
I'm inclined to think this is a slight improvement, just for the
sake of consistency with peer level information. You probably
already noticed, but the patch as submitted neglects to close the
prior sect2 block before opening the new one.
Yes, thanks for pointing out that!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers