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 17:37:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > 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'd have gone with snapmgr.h/c for consistency with existing filenames
> (bufmgr, lmgr, etc).

Doh!  Sorry.  We're at the best time for changing the name, since the
file has no history.  Shall I?

> > 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.
> I don't like that very much.  What about just moving the HTSU_Result
> enum's declaration somewhere else?  Two possibilities are heapam.h
> itself, or the new snapshot.h file (which'd then have to be included
> by heapam.h, but it seems lightweight enough that that's not too
> terrible).

Well, heapam.h includes a lot of other headers, so it doesn't look a
good candidate to me.  I think snapshot.h is a reasonably good

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-03-26 17:50:20
Subject: Re: Auto Partitioning Patch - WIP version 1
Previous:From: Tom LaneDate: 2008-03-26 16:49:55
Subject: Re: Moving snapshot code around

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