Thread: 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