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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-patches by date

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