Обсуждение: 2nd nested trasanctions supporting patch

Поиск
Список
Период
Сортировка

2nd nested trasanctions supporting patch

От
Alvaro Herrera
Дата:
Hackers,

This is the second patch for the nested transactions stuff.  This one
removes the global variables used in Snapshots (QuerySnapshot,
SerializableSnapshot, SnapshotDirty, RecentXmin, RecentGlobalXmin and
ReferentialIntegritySnapshotOverride) and puts the whole bunch in a
single struct.

It also adds some accesor functions so that other functions can read and
modify what they need.

This patch is not as simple as the previous one but is not rocket
science either.  Please review it, and apply if there are no objections.
As before, there is no change in functionality nor regression tests
failed.

Both patches can be applied separately, there's no dependence between
them.

BTW, I've been using CVSup (thanks to Joe Conway) because I've found it
very helpful.  Because of this I think in the previous patch there was
some weird update of the $Header$ which should be innoffensive, and also
the "RCS file: " line points to something that's probably different from
CVS.  I expect that it shouldn't cause any problem, but if there is just
tell me and I'll resubmit.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended."  (Gerry Pourwelle)

Вложения

Re: 2nd nested trasanctions supporting patch

От
Jan Wieck
Дата:
Alvaro Herrera wrote:
>
> Hackers,
>
> This is the second patch for the nested transactions stuff.  This one
> removes the global variables used in Snapshots (QuerySnapshot,
> SerializableSnapshot, SnapshotDirty, RecentXmin, RecentGlobalXmin and
> ReferentialIntegritySnapshotOverride) and puts the whole bunch in a
> single struct.
>
> It also adds some accesor functions so that other functions can read and
> modify what they need.

What's the performance impact caused by the accessor functions? I
thought most of the tuple visibility code is done in macros for some
reason.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Re: 2nd nested trasanctions supporting patch

От
Alvaro Herrera Munoz
Дата:
On Mon, Apr 28, 2003 at 09:29:55AM -0400, Jan Wieck wrote:
> Alvaro Herrera wrote:

> > It also adds some accesor functions so that other functions can read and
> > modify what they need.
>
> What's the performance impact caused by the accessor functions? I
> thought most of the tuple visibility code is done in macros for some
> reason.

Oh, I dunno.  But actually the only macro I removed was IsSnapshotDirty.
All the others accessor functions are there to provide access to
now-local, previously-global variables that were accessed directly.  I
think everything can be converted macros if there's need.  I'll try to
do some performance measurements.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La verdad no siempre es bonita, pero el hambre de ella si"


Re: 2nd nested trasanctions supporting patch

От
Alvaro Herrera
Дата:
On Sun, Apr 27, 2003 at 11:44:00PM -0400, Alvaro Herrera wrote:

Hackers,

> This is the second patch for the nested transactions stuff.  This one
> removes the global variables used in Snapshots (QuerySnapshot,
> SerializableSnapshot, SnapshotDirty, RecentXmin, RecentGlobalXmin and
> ReferentialIntegritySnapshotOverride) and puts the whole bunch in a
> single struct.

In a private email exchange with Manfred he has suggested several
useful ideas regarding these patches, so I will be working on them and
I will post updated versions whenever they are ready.  In the meantime,
please disregard the posted versions.  Althought I think the first one
(stack-ification of the deferred trigger queue) will be quite similar to
the posted patch, the second will probably disappear.

Thanks for your attention and sorry for being so slow,

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)