From: | Hiroyuki Yamada <yamada(at)kokolink(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: alpha3 release schedule? |
Date: | 2009-12-21 09:42:16 |
Message-ID: | 200912210942.AA00180@silver.kokolink.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>The problem you mention here has been documented and very accessible for
>months and not a single person mentioned it up to now. What's more, the
>equivalent problem happens in the latest production version of Postgres
>- users can delay VACUUM endlessly in just the same way, yet I've not
>seen this raised as an issue in many years of using Postgres. Similarly,
>there are some ways that Postgres can deadlock that it need not, yet
>those negative behaviours are accepted and nobody is rushing to fix
>them, nor demanding that they should be. Few things are theoretically
>perfect on their first release.
>
Sorry for annoying you, at the very first.
Well, this is certainly a well-known problem, but the cursor example
(or deadlock example) reveals that the problem is more severe than
it was considered before, I guess.
Following comments in backup.sgml(which are now replaced by the deadlock example)
> Waits for buffer cleanup locks do not currently result in query
> cancellation. Long waits are uncommon, though can happen in some cases
> with long running nested loop joins.
...refered only to the example where startup process should wait
until the end of one query. And long waits are assumed to be uncommon.
The cursor example shows, however, the waits can be as long as one
transaction, and occur in usual use case. FYI, I wrote a typical freeze
scenario in the mail posted in the original deadlock example thread.
Then the startup process may have to wait until the end of transaction,
and we can not expect when the pin-holder transaction ends.
Also, you mentioned the VACCUM case of the production version, but following
two problems have different impacts.
* One VACUUM process freezes until the end of a certain transaction.
* Startup process(and whole recovery work) freezes until the end of
a certain transaction.
The startup process is the last process to freeze. So I guess
this problem may become must-fix.
Anyway, the patch are committed and alpha 3 are to be released.
Do you think this problem is must-fix for the final release ?
regards,
--
Hiroyuki YAMADA
Kokolink Corporation
yamada(at)kokolink(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-12-21 10:13:02 | Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support |
Previous Message | Hiroyuki Yamada | 2009-12-21 09:38:52 | Re: An example of bugs for Hot Standby |