37.10.3
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/xfunc-c.html Description: There is mention to macro PG_ARGNULL_xxx() which I cannot locate. Aren't you talking of PG_ARGISNULL(n) ?
68.2.1
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/storage-toast.html Description: ALTER TABLE ... SET (toast_tuple_target = N) is not documented in "ALTER TABLE" SQL commands section.
optionally schema-qualified for table_name
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/sql-altersequence.html Description: Although I can see that table_name in OWNED BY clause can be optionally schema-qualified by á…źcarefully reading "The specified table must have the same owner and be in the same schema as the sequence.", it would be good if "optionally schema-qualified" is explicitly noted somehow like other pages such as CREATE TABLE and CREATE VIEW. The same applies to CREATE SEQUENCE page.
Re: Move description of general lock behaviour out of the "13.3.1. Table-level Locks section"
On Mon, Feb 3, 2020 at 05:04:00PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.4/explicit-locking.html > Description: > > Hi > > The "13.3.1. Table-level Locks" subsection mentions the following: "Once > acquired, a lock is normally held till end of transaction." (maybe we should > also squeeze a "...till the end of a transaction" in there) According to a Sorry for the delay in replying. Yes, this wording needs improvement, which I have done in the attached patch. > helpful stranger on IRC, this behavior is also true for row-level locks. > > Since this sentence also applies to the row-level locks described in the > following subsection 13.3.2 I think it would be more fitting to move the > paragraph containing this sentence to the introduction of the topic in > section "13.3. Explicit Locking". This would then read something like: Uh, we can't move that paragraph up because Page-Level Locks and Advisory Locks aren't always released on transaction end or rollback. What I did do was to mention that row-level locks are released in a similar way to table-level locks. Patch attached. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index f8c9655111..95465d581b 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -1039,9 +1039,9 @@ ERROR: could not serialize access due to read/write dependencies among transact -Once acquired, a lock is normally held till end of transaction. But if a +Once acquired, a lock is normally held until the end of the transaction. But if a lock is acquired after establishing a savepoint, the lock is released -immediately if the savepoint is rolled back to. This is consistent with +immediately if the savepoint is rolled back. This is consistent with the principle that ROLLBACK cancels all effects of the commands since the savepoint. The same holds for locks acquired within a PL/pgSQL exception block: an error escape from the block @@ -1178,7 +1178,10 @@ ERROR: could not serialize access due to read/write dependencies among transact conflicting locks on the same row, even in different subtransactions; but other than that, two transactions can never hold conflicting locks on the same row. Row-level locks do not affect data querying; they - block only writers and lockers to the same row. + block only writers and lockers to the same + row. Row-level locks are released at transaction end or during + savepoint rollback, just like table-level locks. +
Re: 68.2.1
On Thu, 2020-03-12 at 08:07 +, PG Doc comments form wrote: > ALTER TABLE ... SET (toast_tuple_target = N) is not documented in "ALTER > TABLE" SQL commands section. No, but the documentation for the SET clause references the "Storage Parameter" section of CREATE TABLE, and it is referenced there. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
Re: 37.10.3
On Thu, 2020-03-12 at 06:34 +, PG Doc comments form wrote: > There is mention to macro PG_ARGNULL_xxx() which I cannot locate. Aren't you > talking of PG_ARGISNULL(n) ? Indeed. Here is a patch for that. Yours, Laurenz Albe diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index d9afd3be4d..7c3cfb0115 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -2241,7 +2241,7 @@ PG_FUNCTION_INFO_V1(funcname); PG_GETARG_xxx() macro that corresponds to the argument's data type. In non-strict functions there needs to be a previous check about argument null-ness - using PG_ARGNULL_xxx(). + using PG_ARGISNULL_xxx(). The result is returned using a PG_RETURN_xxx() macro for the return type.
Re: btree index maximum row size
On Mon, Feb 3, 2020 at 07:09:19PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/limits.html > Description: > > Appendix K (PostgreSQL Limits) - doesn't mention the (btree) index row size > limits. I think that it should. Sorry for the delay in replying. We do get questions about the btree length limit occasionally, but practically the length limit usually isn't a problem. Unless you need ordered data, a hash index is a better choice for long values than btree because the hashes are much shorter. Expression indexes can also help. What is your use-case for indexing very long values? -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: btree index maximum row size
On Thu, Mar 12, 2020 at 5:17 PM Bruce Momjian wrote: > Sorry for the delay in replying. We do get questions about the btree > length limit occasionally, but practically the length limit usually > isn't a problem. Technically the limitation is documented elsewhere, since it is a limitation of the B-Tree access method specifically. However, I think that there is a good practical argument to be made for including it here as well. -- Peter Geoghegan
