Alexey Beschiokov <proforg@maloletka.ru> writes:
> postgresql server crushes on some inserts / upates statements.
I've applied the attached patch as a temporary stopgap for this.
regards, tom lane
Index: execMain.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/executor/execMain.c,v
retrieving revision 1.256.2.1
diff -c -r1.256.2.1 execMain.c
*** execMain.c 14 Nov 2005 17:43:12 -0000 1.256.2.1
--- execMain.c 19 Nov 2005 20:52:37 -0000
***************
*** 1446,1451 ****
--- 1446,1461 ----
setLastTid(&(tuple->t_self));
/*
+ * KLUGE SOLUTION for bug found post 8.1 release: if the tuple toaster
+ * fired on the tuple then it changed the physical tuple inside the
+ * tuple slot, leaving any extracted information invalid. Mark the
+ * extracted state invalid just in case. Need to fix things so that
+ * the toaster gets to run against the tuple before we materialize it,
+ * but that's way too invasive for a stable branch.
+ */
+ slot->tts_nvalid = 0;
+
+ /*
* insert index entries for tuple
*/
if (resultRelInfo->ri_NumIndices > 0)
***************
*** 1700,1705 ****
--- 1710,1725 ----
(estate->es_processed)++;
/*
+ * KLUGE SOLUTION for bug found post 8.1 release: if the tuple toaster
+ * fired on the tuple then it changed the physical tuple inside the
+ * tuple slot, leaving any extracted information invalid. Mark the
+ * extracted state invalid just in case. Need to fix things so that
+ * the toaster gets to run against the tuple before we materialize it,
+ * but that's way too invasive for a stable branch.
+ */
+ slot->tts_nvalid = 0;
+
+ /*
* Note: instead of having to update the old index tuples associated with
* the heap tuple, all we do is form and insert new index tuples. This is
* because UPDATEs are actually DELETEs and INSERTs, and index tuple
