Skip site navigation (1) Skip section navigation (2)

Phantom Command IDs, updated patch

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Phantom Command IDs, updated patch
Date: 2007-01-30 11:19:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Here's an updated version of the phantom command ids patch.

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.

Per Tom's suggestion, I replaced the function cache code in fmgr.c and 
similar code in plperl.c, pltcl.c, plpgsql/pl_comp.c and plpython.c to 
use xmin+tid instead of xmin+cmin for the up-to-dateness check. I don't 
have any tcl, perl or python test cases handy to test them, but the 
change is small and essentially same for all of the above. Is there any 
regression tests for the PL languages?

I made cmin and cmax system attributes aliases for the same physical 
commandid field. I support the idea of a complete overhaul of those 
system attributes, but let's do that in a separate patch.

To measure the overhead, I ran a plpgsql test case that updates a single 
row 10000 times in a loop, generating a new phantom command id in each 
iteration. The test took ~5% longer with the patch, so I think that's 
acceptable. I couldn't measure a difference with pgbench (as expected).

I think the patch is ready. Please remove the PHANTOMCID_DEBUG define 
and ifdef blocks before applying.

   Heikki Linnakangas

Attachment: phantomcid-4.patch
Description: text/x-patch (38.5 KB)


pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-01-30 11:19:13
Subject: Re: Bug? CREATE TABLE AS (... UNION ...)
Previous:From: Gregory StarkDate: 2007-01-30 11:00:16
Subject: Bug? CREATE TABLE AS (... UNION ...)

pgsql-patches by date

Next:From: Andrew DunstanDate: 2007-01-30 12:19:33
Subject: Re: Phantom Command IDs, updated patch
Previous:From: Pavan DeolaseeDate: 2007-01-30 11:06:57
Subject: Re: Lock compatibility matrix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group