Re: alpha3 release schedule?

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

In response to

Responses

Browse pgsql-hackers by date

  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