"Steven Flatt" <[EMAIL PROTECTED]> writes:
> On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> What I think might be happening is a three-way deadlock involving these
>> two and a third process that has the desired buffer lock. Have you got
>> anything else that seems to be stuck?
> Don't see a
Russell Smith <[EMAIL PROTECTED]> writes:
> In-equality transformations do not guarantee that y > 1.5x == y/x >
> 1.5. This is only true for x>0, y < 1.5*x for x<0. I have not posted a
> patch as I'm not sure what is the best way to change the example.
Seems a bit nit-picky, but we could chang
"Jan Mate" <[EMAIL PROTECTED]> writes:
> Description:unexpected PARAM_SUBLINK ID
If convenient, please try the 8.2 patch seen here:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c
regards, tom lane
--
Russell Smith wrote:
> SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
>
> A CASE construct used in this fashion will defeat optimization attempts,
> so it should only be done when necessary. (In this particular example,
> it would be best to sidestep the problem by writing y > 1.5
On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, that's not what the backtraces say. The autovac process is trying
> to get super-exclusive lock on a buffer (apparently in relation 16783
> --- what is that?). There's no evidence in the stack trace that the
> TRUNCATE process has any conflict
Hi,
I've had this minor bugbear with this part of the docs for a while and
am finally reporting it.
http://www.postgresql.org/docs/8.3/static/sql-expressions.html (And all
back branch documentation)
SELECT ... WHERE x <> 0 AND y/x > 1.5;
But this is safe:
SELECT ... WHERE CASE WHEN x <> 0
On 1/17/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > This isn't a postgres deadlock per se, but the end result is that two
> > postgres backends are stuck, each waiting on a PGSemaphoreLock that the
> > other presumably has. The processes have been stuck for hours.
>
> Can you reproduce this
"Steven Flatt" <[EMAIL PROTECTED]> writes:
> This isn't a postgres deadlock per se, but the end result is that two
> postgres backends are stuck, each waiting on a PGSemaphoreLock that the
> other presumably has. The processes have been stuck for hours.
No, that's not what the backtraces say. Th
Suresh Gupta VG wrote:
Thanks for your reply.
As per your suggestion, if we remove “CREATE FUNCTION” statement, we
cannot use that function.
Actually, we need this feature.
Can you pls suggest some url or docs to help us in developing the
c-language code to rectify this as we had done earl
"Jan Mate" <[EMAIL PROTECTED]> writes:
> I get the following error:
> ERROR: unexpected PARAM_SUBLINK ID: 3
This is an interesting test case. The problem is coming from the part
of the rule that has
(new.number, new.limited, new."level") IN (SELECT ...)
The parser transforms this to a
"Michael Akinde" <[EMAIL PROTECTED]> writes:
> Description:lo_open leaks memory
Hmm, I cannot replicate any memory leak with your example.
I'm testing 8.2.6 (well, really 8.2 branch tip) not 8.2.5, but I
don't recall that there were any recent fixes in this area.
Perhaps there is some cont
Steven Flatt escribió:
> This isn't a postgres deadlock per se, but the end result is that two
> postgres backends are stuck, each waiting on a PGSemaphoreLock that the
> other presumably has. The processes have been stuck for hours.
Can you reproduce this problem at will?
Are the processes sti
The following bug has been logged online:
Bug reference: 3883
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Autovacuum deadlock with truncate?
Details:
This isn't a postgres deadlock per
The following bug has been logged online:
Bug reference: 3882
Logged by: Jan Mate
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Linux and Mac OS X
Description:unexpected PARAM_SUBLINK ID
Details:
I am trying to create a row versioning
Suresh Gupta VG wrote:
> As per your suggestion, if we remove "CREATE FUNCTION" statement, we
> cannot use that function.
Add the PG_MODULE_MAGIC stuff to your code and recompile it. This is
mentioned in the documentation.
--
Alvaro Herrerahttp://www.CommandProm
Thanks for your reply.
As per your suggestion, if we remove "CREATE FUNCTION" statement, we
cannot use that function.
Actually, we need this feature.
Can you pls suggest some url or docs to help us in developing the
c-language code to rectify this as we had done earlier for pgsql7.4.2.
[EMAIL PROTECTED] (Mischa Sandberg) writes:
>Unfortunately, with multiple jails running PG servers and (due to app
>limitations) all servers having same PGPORT, you get the situation that
>when jail#2 (,jail#3,...) server comes up, it:
>- detects that there is a shm seg with ipc key 5432001
>- che
Suresh Gupta VG wrote:
I had recently upgraded my pgsql 7.4.2 to pgsql 8.2.5 on Solaris 9
Sparc machine. All the installation went normally as per install
documents of Postgresql. In between the installation, I got the
following error. But at the end I could create database and can use
the D
Dear Team,
I had recently upgraded my pgsql 7.4.2 to pgsql 8.2.5 on Solaris 9 Sparc
machine. All the installation went normally as per install documents of
Postgresql. In between the installation, I got the following error. But
at the end I could create database and can use the DB as normal.
-
The following bug has been logged online:
Bug reference: 3881
Logged by: Michael Akinde
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux Debian Etch
Description:lo_open leaks memory
Details:
We are using large objects to store gridd
20 matches
Mail list logo
