Jan Wieck wrote:

>> (gdb) frame 2
>> #2  0x00002aaaca4ba348 in _Slony_I_logTrigger (fcinfo=0x9362bd) at 
>> slony1_funcs.c:783
>> 783                             col_value = 
>> slon_quote_literal(SPI_getvalue(old_row, tupdesc, i + 1));
>>
>> (gdb) print *((TriggerData)*fcinfo->context)->tg_relation->rd_rel
>> Cannot access memory at address 0x61746f54222c226d
>
>
> Ugly ... that looks rather ugly. Could be simply due to some pointer 
> value held in a register only due to optimization, and gdb using the 
> still allocated memory location of the variable instead. Well, what about
>
> frame 2
> print tab_id
>
> That "should" give you the tables ID in sl_table.
>
OK now we're getting somewhere :)

print tab_id tells me $1 is 73, and looking in sl_table shows me that's 
our "RoomNight" table.. whose primary "ID" column is specifically 
described as NOT NULL..

Confirming this:

laterooms=# select * from "RoomNight"  WHERE "ID" = NULL;
 ID | BookingID | RoomID | Price | Date | DateBooked | Cancelled | 
GuestName | Adults | Children | AllocationStatusID | SmokingRequest | 
BedRequested | Incomplete | RoomNumber
----+-----------+--------+-------+------+------------+-----------+-----------+--------+----------+--------------------+----------------+--------------+------------+------------
(0 rows)

So there's definately no data stored with a NULL ID - and I tried a 
couple of sample queries to see if I could force a crash...

laterooms=# update "RoomNight" set "Cancelled" = 'f' WHERE "ID" = NULL;
UPDATE 0
laterooms=# update "RoomNight" set "Cancelled" = 'f' WHERE "ID" = 0;
UPDATE 0

Hm, and they execute with zero rows modified, just as I'd expect.

Cheers,
Gavin.