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

Re: [pgsql-patches] Phantom Command IDs, updated patch

From: Bruce Momjian <bruce(at)momjian(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-01 03:36:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Your patch has been added to the PostgreSQL unapplied patches list at:

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.


Heikki Linnakangas wrote:
> 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
>    EnterpriseDB

> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Chris DunlopDate: 2007-02-01 04:03:05
Subject: Re: Data archiving/warehousing idea
Previous:From: Bruce MomjianDate: 2007-02-01 02:45:27
Subject: Re: [pgsql-patches] [HACKERS] [Fwd: Index Advisor]

pgsql-patches by date

Next:From: korrydDate: 2007-02-01 04:15:38
Subject: Re: [pgsql-patches] Patch to avoid gprof profilingoverwrites
Previous:From: Bruce MomjianDate: 2007-02-01 02:45:27
Subject: Re: [pgsql-patches] [HACKERS] [Fwd: Index Advisor]

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