On Mon, Aug 8, 2011 at 1:10 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
