The following bug has been logged online:
Bug reference: 5151
Logged by: Boris Folgmann
Email address: bo...@folgmann.de
PostgreSQL version: 8.1.15
Operating system: CentOS release 4.8 (Final)
Description:autovacuum process segfaults when max_fsm_pages are too
low
Hi Tom,
Tom Lane schrieb/wrote:
> > Red Hat stopped supporting the RHEL-4 App Stack product awhile ago;
> > since CentOS is evidently copying that, you should not hold your
> > breath waiting for an update :-(. However, as far as I can see
It seems that you are right, and I don't understand how
Hi!
We run a web application based on a complex database using
postgresql-7.2.3-5.80 on Red Hat 8.0.
Generally using pgsql with JDBC is very nice, but from time to time we run
into problems that are caused by something like a silent deadlock, which
means that it isn't reported in the logfile and
Hi!
We run a web application based on a complex database using
postgresql-7.2.3-5.80 on Red Hat 8.0.
Generally using pgsql with JDBC is very nice, but from time to time we run
into problems that are caused by something like a silent deadlock, which
means that it isn't reported in the logfile and
Hi!
I posted a bug report to this list. Did anybody receive it (subject: Silent
Deadlock)? I wanted to use bugzilla instead but couldn't find a link to it
on www.postgresql.org. Please move it to a prominent place, if you still
use it.
I'm also wondering what happened to news.postgresql.org, beca
ion that satisfies the given argument types
You may need to add explicit typecasts
Look closely: postmaster now thinks that the first argument 1.0 is NUMERIC,
but I added only the /25 for the _second_ argument!
cu,
boris
--
Dipl.-Inf. Boris Folgmann mailto:[EMAIL PROTECTED]
Team
Hi,
hubert depesz lubaczewski schrieb/wrote:
generally - order by datname is understood as "order by *variable
datname*". - which is null.
It's clear that it's a shadowing problem. But it's not a "FOR IN EXECUTE"
where a variable makes sense. I mean why is a "ORDER BY variable" valid in
"FOR
