Re: A Rant on lock_timeout
On Fri, Oct 4, 2019 at 01:35:57PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/runtime-config-client.html > Description: > > Hello, > > I was looking explicitly for information on the default value of > lock_timeout and what it does. I got this paragraph: > > "Abort any statement that waits longer than the specified number of > milliseconds while attempting to acquire a lock on a table, index, row, or > other database object. The time limit applies separately to each lock > acquisition attempt. The limit applies both to explicit locking requests > (such as LOCK TABLE, or SELECT FOR UPDATE without NOWAIT) and to > implicitly-acquired locks. If log_min_error_statement is set to ERROR or > lower, the statement that timed out will be logged. A value of zero (the > default) turns this off." > > Unfortunately, the crucial bit for me is in a sentence that hardly could be > any more obscure: `A value of zero (the default) turns this off.` Before > this sentence there are multiple statements; what exactly does `this` refers > to? Does a value of zero turns of logging of timed out statements mentioned > in the previous sentence? Would it be hard to put it like `A default value > of zero means a statement will wait indefinitely to acquire a lock`. > I believe the sole purpose of a technical document is to be precise. If I > had to suggest setting this parameter as a solution to a critical issue of > connections piling up waiting on locks and depleting connection pools, I can > never be confident knowing that the current default value turns something > off. I completely agree. I have applied the attached patch to all supported doc versions to move the mention of log_min_error_statement to a more logical location. Thanks for the report. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Invalid website links
On Sun, Oct 6, 2019 at 09:56:41AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/gin-intro.html > Description: > > Chapter 66.1: "The GIN implementation in PostgreSQL is primarily maintained > by Teodor Sigaev and Oleg Bartunov. There is more information about GIN on > their website." - website is pointing to: > http://www.sai.msu.su/~megera/wiki/Gin which is invalid and responds with > "Site cannot be reached" Uh, I just tested it and it worked for me. Text starts as: Gin for PostgreSQL Gin was sponsored by jfg://networks (http://www.jfg-networks.com/) This is an original documentation and may be outdated. Actual version of documentation is available from http://www.postgresql.org/docs/current/static/gin-extensibility.html Can you please retest? Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: grammar mistake in java8-date-time.html ?
On Sun, Oct 6, 2019 at 02:40:19PM -0400, Tom Lane wrote: > PG Doc comments form writes: > > I think that there's a grammar error in the following doc url: > > https://jdbc.postgresql.org/documentation/head/java8-date-time.html > > It says: "Also note that all OffsetDateTime instances will have be in UTC > > (have offset 0)." > > I suspect that it was supposed to read: "will be". > > You'd need to report this to the JDBC project --- this list is just > for documentation issues in core Postgres. Yes, please email pgsql-j...@postgresql.org. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: I'm surprised to see the word master here
On Mon, Oct 7, 2019 at 10:49:54AM +1300, Mike Taves wrote: > On Sat, 5 Oct 2019 at 10:57, Bruce Momjian wrote: > > With master/standby-replica-slave, it is clear what multi-master is, and > > what master/replica is. If you start using active-active, is it > > active/replica? The full choices are: ... > > There are more choices. Coming from a different corner of computing, > we have changed these computing resource names to other > anthropomorphic titles found around office environments: "manager" and > either "worker" or "agent". With these names, some derived terms are > "multi-manager" and "standby-replica-worker". I think the problem is that "worker" doesn't have the idea that it is a copy of the primary, which replica and standby kind of do. On the other hand, worker and slave seem almost identical, and you are right they don't have the concept of being a copy either. :-( I guess I was hoping to move to a term that had _copy_ built into the term. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Ambiguous language in Table 8.13. Special Date/Time Inputs [EXT]
On Thu, Jul 11, 2019 at 10:42:35AM -0400, Bruce Momjian wrote: > On Thu, Jul 11, 2019 at 09:34:58AM +0100, David Harper wrote: > > > One really simple way to make it shorter is to say "00:00", leaving > > > out the seconds. > > > > That’s a good solution. It removes the long-standing ambiguity without > > looking too ugly. > > OK, how is this patch? Doc patch applied to all current branches. Thanks for the report. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Synchronous Multimaster Replication
On Sat, Sep 28, 2019 at 09:47:40AM -0400, Bruce Momjian wrote: > On Sun, Sep 15, 2019 at 04:37:18PM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: > > https://www.postgresql.org/docs/11/different-replication-solutions.html > > Description: > > > > Not sure if this is an error but I was wondering about this sentence: "In > > fact, write performance is often worse than that of a single server". Isn't > > syncronous multimaster write performance always (rather than "often") worse > > than that of a single (non-distributed) server? > > Very good point. I have improved the text with the attached patch. I > also clarified the asynchronous case. Patch applied thorough all current versions of the Postgres docs. Thanks for the report. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
