but no database changes have been made since the last CommandCounterIncrement.
This should result in a significant improvement in the number of "commands"
that can typically be performed within a transaction before hitting the 2^32
CommandId size limit. In particular this buys back (and more) the possible
adverse consequences of my previous patch to fix plan caching behavior.
The implementation requires tracking whether the current CommandCounter
value has been "used" to mark any tuples. CommandCounter values stored into
snapshots are presumed not to be used for this purpose. This requires some
small executor changes, since the executor used to conflate the curcid of
the snapshot it was using with the command ID to mark output tuples with.
Separating these concepts allows some small simplifications in executor APIs.
Something for the TODO list: look into having CommandCounterIncrement not do
AcceptInvalidationMessages. It seems fairly bogus to be doing it there,
but exactly where to do it instead isn't clear, and I'm disinclined to mess
with asynchronous behavior during late beta.
inappropriately generic-sounding names. This is more or less free since
we already forced initdb for the next beta, and it may prevent confusion or
name conflicts (particularly at the C-global-symbol level) down the road.
Per my proposal yesterday.
compatibility package. This supports importing dumps from past versions
using tsearch2, and provides the old names and API for most functions
that were changed. (rewrite(ARRAY[...]) is a glaring omission, though.)
Pavel Stehule and Tom Lane
about best practice for including the module creation scripts: to wit
that you should suppress NOTICE messages. This avoids creating
regression failures by adding or removing comment lines in the module
scripts.
Remove setting of search_path in install/uninstall scripts, since unlike
other contrib modules this one does not want to let you change the
installation schema.
itself as libuuid, not libossp-uuid which was the only case expected by
our build support. Install a configure test to determine which name
to use (and to check that the library is present at all).
remove transactions
use create or replace function
make formatting consistent
set search patch on first line
Add documentation on modifying *.sql to set the search patch, and
mention that major upgrades should still run the installation scripts.
Some of these issues were spotted by Tom today.
on CORE previously.
This module offers transaction ID's containing the original XID and the
transaction epoch as a bigint value to the user level. It also provides
a special txid_snapshot data type that contains an entire transactions
visibility snapshot information, which is useful to determine if a
particular txid was visible to a transaction or not.
The module has been tested by porting Slony-I from using its original
xxid data type.
Jan
testing). Combine the formerly independent opclasses for the various
ISN types into opfamilies. The latter causes some extra bleating from
opr_sanity, since the module doesn't provide complete sets of cross-type
operators, but it's still a good idea because it will give the planner
more information to work with. The missing cross-type operators no longer
pose a risk of unexpected planner errors in 8.3, so there's no need to
insist on filling them in (and I gather it wouldn't be very sound
semantically to add them all).
couldn't possibly HAVE_GETOPT. I believe this is the most appropriate
form of the patch submitted 2007-08-07 by Hiroshi Saito, though not
having a Windows build environment I won't know for sure till I see
the buildfarm results.
Tom Lane