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

From Bruce Momjian
Subject Re: [pgsql-patches] Phantom Command IDs, updated patch
Date
Msg-id 200702081625.l18GPeQ09861@momjian.us
Whole thread Raw
In response to Phantom Command IDs, updated patch  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: [pgsql-patches] Phantom Command IDs, updated patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [pgsql-patches] Phantom Command IDs, updated patch  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: [pgsql-patches] Phantom Command IDs, updated patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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, I found something odd in your patch.  You had an extra
parentheses at the end of the line in the orginal and new version of the
patch (attached).  I removed it before applying, but I just wanted to
confirm this was OK.

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
***************
*** 162,168 ****
      {
          /* We have a compiled function, but is it still valid? */
          if (!(function->fn_xmin == HeapTupleHeaderGetXmin(procTup->t_data) &&
!               function->fn_cmin == HeapTupleHeaderGetCmin(procTup->t_data)))
          {
              /* Nope, drop the function and associated storage */
              delete_function(function);
--- 162,168 ----
      {
          /* We have a compiled function, but is it still valid? */
          if (!(function->fn_xmin == HeapTupleHeaderGetXmin(procTup->t_data) &&
!               ItemPointerEquals(&function->fn_tid, &procTup->t_self)))
          {
              /* Nope, drop the function and associated storage */
              delete_function(function);

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-patches] Phantom Command IDs, updated patch
Next
From: Alvaro Herrera
Date:
Subject: Re: [pgsql-patches] Phantom Command IDs, updated patch