Обсуждение: Re: Postgresql 7.3 on Red Hat Enterprise 5 (Problem with SEMMNI, SEMMNS)
Thank you for comments, did I mention the system is a beast? # cat /proc/sys/kernel/shmmax 68719476736 It can not be the resource limit, it has to be something else. I assume this version of postgres is incompatible with RedHatES 5. Changing to a newer version of postgres is not an option for now. It would take too much time to rewrite theapplication to work with the changes introduced in the lastest realeses. I have tried PG 7.3.17 version an it works fine,I just can not use it. -- Darek Czarkowski
Darek Czarkowski <dczarkowski@infinitesource.ca> writes: > It can not be the resource limit, it has to be something else. I assume thi= > s version of postgres is incompatible with RedHat ES 5. Changing to a newer= > version of postgres is not an option for now. It would take too much time = > to rewrite the application to work with the changes introduced in the laste= > st realeses. I have tried PG 7.3.17 version an it works fine, I just can no= > t use it. What changes would those be? If your app works on 7.3.4 it should work with 7.3.17. regards, tom lane
On 9/6/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Darek Czarkowski <dczarkowski@infinitesource.ca> writes: > > It can not be the resource limit, it has to be something else. I assume thi= > > s version of postgres is incompatible with RedHat ES 5. Changing to a newer= > > version of postgres is not an option for now. It would take too much time = > > to rewrite the application to work with the changes introduced in the laste= > > st realeses. I have tried PG 7.3.17 version an it works fine, I just can no= > > t use it. > > What changes would those be? If your app works on 7.3.4 it should work > with 7.3.17. Actually, from what he wrote, I take it that 7.3.17 works fine, but some insane policy where he works demands he use 7.3.4
"Scott Marlowe" <scott.marlowe@gmail.com> writes: > On 9/6/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What changes would those be? If your app works on 7.3.4 it should work >> with 7.3.17. > Actually, from what he wrote, I take it that 7.3.17 works fine, but > some insane policy where he works demands he use 7.3.4 Nah, if they were that troglodytic they'd hardly let him use an OS as newfangled as RHEL-5 (even RHEL-4 shipped with PG 7.4.x). I read him to say that PG 7.4 and up contain changes that break his app, which could be a fair complaint. But if it doesn't work on 7.3.latest then there's something pretty wrong with it. regards, tom lane
I am sorry, it seams that my last replay never reached the list. I was looking for the list of changes for each version, but this document is bundled with the source. I believe it is thefix introduced in version 7.3.5: "* Fix insertion of expressions containing subqueries into rule bodies" Above line is from HISTORY file, and our application is just abusing this feature. Upgrade to newest version of Postgresis on our development list for the last few years, but we are just too busy with new projects, and don't have enoughresources to commit to it. You have to understand that an upgrade would halt any development for an unspecified time. Getting new version of operating system is not that much of a problem, we trust Redhat to deliver reliable operating system,and we do build PostgresSQL from source anyway. I have settled for 250 connections and 810 shared buffers, this is just to get the server ready for deployment. Rising anyof the settings makes postmaster fail. I think there must be something that makes Postgres register server settings incorrectlybecause they exceed the available resources as compared to average system from the time of the release of thedatabase. regards, Darek Czarkowski
Darek Czarkowski <dczarkowski@infinitesource.ca> writes: > I am sorry, it seams that my last replay never reached the list. > I was looking for the list of changes for each version, but this document i= > s bundled with the source. I believe it is the fix introduced in version 7.= > 3.5: > "* Fix insertion of expressions containing subqueries into rule bodies" > Above line is from HISTORY file, and our application is just abusing this f= > eature. BTW, I checked the CVS logs, and AFAICT this entry refers to the bug and patch shown in this thread: http://archives.postgresql.org/pgsql-general/2003-10/msg00888.php I'd be interested to know how your application is depending on the ability to get an "ExecEvalExpr: unknown expression type 108" failure. regards, tom lane
Tom Lane wrote: > Darek Czarkowski <dczarkowski@infinitesource.ca> writes: > >> I am sorry, it seams that my last replay never reached the list. >> I was looking for the list of changes for each version, but this document i= >> s bundled with the source. I believe it is the fix introduced in version 7.= >> 3.5: >> "* Fix insertion of expressions containing subqueries into rule bodies" >> Above line is from HISTORY file, and our application is just abusing this f= >> eature. >> > > BTW, I checked the CVS logs, and AFAICT this entry refers to the bug > and patch shown in this thread: > http://archives.postgresql.org/pgsql-general/2003-10/msg00888.php > I'd be interested to know how your application is depending on the > ability to get an "ExecEvalExpr: unknown expression type 108" failure. > > regards, tom lane > > I am not sure what exactly are you looking for? No one is writing code that depends on failures :-) -- Darek Czarkowski
Darek Czarkowski <dczarkowski@infinitesource.ca> writes: > Tom Lane wrote: >> BTW, I checked the CVS logs, and AFAICT this entry refers to the bug >> and patch shown in this thread: >> http://archives.postgresql.org/pgsql-general/2003-10/msg00888.php >> I'd be interested to know how your application is depending on the >> ability to get an "ExecEvalExpr: unknown expression type 108" failure. > I am not sure what exactly are you looking for? No one is writing code > that depends on failures :-) I'm looking for the reason you're not using 7.3.something-recent, because that one isn't a good reason... regards, tom lane