temp tables failes in transaction mode
Your name : Petter Reinholdtsen
Your email address : pere@td.org.uit.no
System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : RedHat Linux 5.2
PostgreSQL version (example: PostgreSQL-6.5) : PostgreSQL-6.5
Compiler used (example: gcc 2.8.0) : GCC 2.7.2.3
Please enter a FULL description of your problem:
------------------------------------------------
It seems that using a temp table in transaction mode makes the backend
crash. On the other end I get the following message:
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible.
I discovered the problem using update on a temp table, but have
discovered later that select also triggers this bug.
There is no messages in syslog when this happends.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
Enter the following in psql:
BEGIN WORK;
SELECT 'Testing temp tables'::text AS n1, ''::text AS n2
INTO TEMP TABLE testing;
SELECT * FROM testing;
UPDATE testing
SET n1 = SUBSTR(n1, 0, POSITION(' ' in n1)),
n2 = SUBSTR(n1, POSITION(' ' in n1)+1);
SELECT * FROM testing;
COMMIT WORK;
It will crash on the first select, and on the update if the first
select is removed.
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
My workaround will probably to make a permanent table to insert my
values in. Another workaround is to remove 'begin work' and not work
in transaction mode.
Your name : Petter Reinholdtsen
Your email address : pere@td.org.uit.noSystem Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : RedHat Linux 5.2
PostgreSQL version (example: PostgreSQL-6.5) : PostgreSQL-6.5
Compiler used (example: gcc 2.8.0) : GCC 2.7.2.3Please enter a FULL description of your problem:
------------------------------------------------It seems that using a temp table in transaction mode makes the backend
crash. On the other end I get the following message:
I believe this is fixed in 6.5.1.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026I believe this is fixed in 6.5.1.
Nope, it is not. I just tried the same SQL code on my newly upgraded
server. Instead of crashing, it hangs. Server uses 50% CPU and
nothing happends.
I did not upgrade the binary data when upgraded from 6.5 to 6.5.1.
README said binary format hasn't changed.
--
##> Petter Reinholdtsen <## | pere@td.org.uit.no
O- <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/ | Go Mozilla, go! Go!
Import Notes
Resolved by subject fallback
I believe this is fixed in 6.5.1.
Nope, it is not. I just tried the same SQL code on my newly upgraded
server. Instead of crashing, it hangs. Server uses 50% CPU and
nothing happends.I did not upgrade the binary data when upgraded from 6.5 to 6.5.1.
README said binary format hasn't changed.
--
##> Petter Reinholdtsen <## | pere@td.org.uit.no
O- <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/ | Go Mozilla, go! Go!
We have since fixed this, but the fix will only appear in 6.6. It
required quite a bit of changes.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Petter Reinholdtsen <pere@hungry.com> writes:
I believe this is fixed in 6.5.1.
Nope, it is not. I just tried the same SQL code on my newly upgraded
server. Instead of crashing, it hangs. Server uses 50% CPU and
nothing happends.
This bug is still there in REL6_5, but it seems to be fixed in the
current (i.e., 6.6 development) sources. I didn't bother to track
down the exact cause of the crash; I'm sure it is associated with
the temp-table-related fixes that just got done this weekend.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofMon6Sep1999234949+0200199909062149.XAA03289@lee.Cc.Uit.No | Resolved by subject fallback