>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 yam...@kokolink.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
