From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [pgsql-patches] Phantom Command IDs, updated patch |
Date: | 2007-02-08 23:45:38 |
Message-ID: | 21374.1170978338@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I found one more subtle safety issue. The array and hash table for
> phantom command ids is dynamically grown when HeapTupleHeaderSetCmax is
> called. Unfortunately, since HeapTupleHeaderSetCmax is used inside a
> critical sections, running out of memory while trying to grow them would
> cause a PANIC. That's why I moved the SetXmax/SetCmax calls outside
> critical sections in heapam.c. I believe that's safe; if a backend
> aborts after setting the xmax/cmax, no-one is going to care about the
> xid of an aborted transaction in there.
I don't like that one bit; I think a saner solution is to refactor the
API of combocid.c so that we can obtain the required CID before
modifying the page. It'll mean it's not a drop-in replacement for
HeapTupleSetCmax, but all callers of that are going to need a close look
anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-02-09 00:07:10 | Re: HOT for PostgreSQL 8.3 |
Previous Message | Bruce Momjian | 2007-02-08 23:25:06 | Re: [HACKERS] plpgsql, return can contains any expression |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-02-09 00:24:13 | Re: Have psql show current sequnce values - (Resubmission) |
Previous Message | Bruce Momjian | 2007-02-08 23:25:06 | Re: [HACKERS] plpgsql, return can contains any expression |