On Mon, Aug 8, 2011 at 1:10 PM, Andres Freund <andres@anarazel.de> wrote:
> There doesn't seem to have been any activity to inlude it in 3.1. The merge
> window for 3.1 just ended. The next one will open for about a week after the
> release.
> Its also not yet included in linux-next which is a "preview" for the currently
> worked on release + 1. A release takes roughly 3 months.
OK. If it doesn't get into Linux 3.2 we had better start thinking
hard about a workaround on our side. I am not too concerned about
people hitting this with PostgreSQL 9.1 or prior, because you'd
basically need a workload targeted to exercise the problem, which
workload is not that similar to the way people actually do things in
real life. However, in PostgreSQL 9.2devel, it's going to be much
more of a real-world problem, so I'd hate to wait until after our
feature freeze and then decide we've got a problem we have to fix.
> For upstreaming somebody needs to be persistent enough to convince one of the
> maintainers of the particular area to include the code so that linus then can
> pull that.
> I guess citing your numbers would go a long way in that direction. Naturally
> it would be even better to inlcude results with the patch applied.
> My largest machine I can reboot often enough to test such a thing has only two
> sockets (4cores E5520). I guess you cannot reboot your loaned machine with a
> new kernel easily?
Not really. I do have root access to a 64-core box at the moment, and
I could probably get permission to reboot it, but if it didn't come
back on-line that would be awkward.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
