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

Re: Moving snapshot code around

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Pg Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Moving snapshot code around
Date: 2008-03-26 16:31:38
Message-ID: 20080326163138.GB29730@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:

> I think thinking of snapshot.h as an "external" interface is
> wrongheaded.  In the proposed refactoring, snapshot.h is concerned with
> snapshot *management* (creating, copying, deleting) while tqual.h is
> concerned with tuple visibility testing (which requires a snapshot as an
> input, but doesn't do any "management").  They're really entirely
> orthogonal concerns.

Agreed, it makes a lot more sense considered in this light.  I renamed
snapshot.{c,h} into snapmgmt.{c,h}, hopefully making the intent clearer.
I also separated the definition of the snapshot struct to snapshot.h.

This caused the new snapmgmt.h header be required in more files, but I
don't see this as a problem because it means tqual.h is now less
generally included.

Patch committed that way.

One thing I'm unhappy about is that tqual.h needs to be included in
heapam.h (which is included just about everywhere) just to get the
definition of the HTSU_Result enum, which is a bit useless because it is
only used in three switch statements that contain a "default" clause
anyway.  I propose changing the result type of heap_update, heap_delete
and heap_lock_tuple to a plain int.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2008-03-26 16:49:55
Subject: Re: Moving snapshot code around
Previous:From: Zdenek KotalaDate: 2008-03-26 16:24:18
Subject: Re: Script binaries renaming

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