CatalogCacheFlushRelation (formerly called SystemCacheRelationFlushed)
how to distinguish tuples it should flush from those it needn't; this
means a relcache flush event now only removes the catcache entries
it ought to, rather than zapping the caches completely as it used to.
Testing with the regression tests indicates that this considerably
improves the lifespan of catcache entries. Also, rearrange catcache
data structures so that the limit on number of cached tuples applies
globally across all the catcaches, rather than being per-catcache.
It was a little silly to have the same size limit on both, say,
pg_attribute caches and pg_am caches (there being only four possible
rows in the latter...). Doing LRU removal across all the caches
instead of locally in each one should reduce cache reload traffic
in the more heavily used caches and improve the efficiency of
cache memory use.
TopTransactionContext, rather than using Dllist. This simplifies and
speeds up the code, and eliminates a former risk of coredump when
out of memory (since the old code didn't bother to check for malloc
failure). It also moves us one step closer to retiring Dllist...
detected sooner in backend startup, and is treated as an expected error
(it gives 'Sorry, too many clients already' now). This allows us not
to have to enforce the MaxBackends limit exactly in the postmaster.
Also, remove ProcRemove() and fold its functionality into ProcKill().
There's no good reason for a backend not to be responsible for removing
its PROC entry, and there are lots of good reasons for the postmaster
not to be touching shared-memory data structures.
rules and triggers by OID. So, even though we have no cross-references
in the system catalogs to pg_rewrite.oid or pg_trigger.oid, we'd better
have unique indexes on them. Put back pg_rewrite_oid_index, which I
mistakenly removed a few days ago, and add pg_trigger_oid_index.
Tom Lane). For the moment, only the OID/name variants are provided.
I didn't force initdb, but the additions to the 'privileges' regress
test won't pass until you do one.
database, including system catalogs (but not the shared catalogs,
since they don't really belong to his database). This is per recent
mailing list discussion. Clean up some other code that also checks
for database ownerness by introducing a test function is_dbadmin().
inet(text), cidr(text): convert a text value into inet/cidr
set_masklen(inet): set masklen on the inet value
Patch also contains regression checks for these functions.
Alex Pilosov
datatypes, not only strings. parse_hook is useless for bool, I suppose,
but it seems possibly useful for int and double to apply variable-specific
constraints that are more complex than simple range limits. assign_hook
is definitely useful for all datatypes --- we need it right now for bool
to support date cache reset when changing Australian timezone rule setting.
Also, clean up some residual problems with the reset all/show all patch,
including memory leaks and mistaken reset of PostPortNumber. It seems
best that RESET ALL not touch variables that don't have SUSET or
USERSET context.
manipulation of rtable/jointree by planner. Rewriter was generating
actions that shared rtable/jointree substructure, which caused havoc
when planner got to the later actions that it'd already mucked up.
It "make"s and "make check"s clean against current cvs tip.
There are now both Text and Name variants, and the regression test support
is rolled into the patch. Note that to be complete wrt Name based variants,
there are now 12 user visible versions of has_table_privilege:
has_table_privilege(Text usename, Text relname, Text priv_type)
has_table_privilege(Text usename, Name relname, Text priv_type)
has_table_privilege(Name usename, Text relname, Text priv_type)
has_table_privilege(Name usename, Name relname, Text priv_type)
has_table_privilege(Text relname, Text priv_type) /* assumes current_user */
has_table_privilege(Name relname, Text priv_type) /* assumes current_user */
has_table_privilege(Text usename, Oid reloid, Text priv_type)
has_table_privilege(Name usename, Oid reloid, Text priv_type)
has_table_privilege(Oid reloid, Text priv_type) /* assumes current_user */
has_table_privilege(Oid usesysid, Text relname, Text priv_type)
has_table_privilege(Oid usesysid, Name relname, Text priv_type)
has_table_privilege(Oid usesysid, Oid reloid, Text priv_type)
For the Text based inputs, a new internal function, get_Name is used
(shamelessly copied from get_seq_name in sequence.c) to downcase if not
quoted, or remove quotes if quoted, and truncate. I also added a few test
cases for the downcasing, quote removal, and Name based variants to the
regression test.
Joe Conway
pg_database now has unique indexes on oid and on datname.
pg_shadow now has unique indexes on usename and on usesysid.
pg_am now has unique index on oid.
pg_opclass now has unique index on oid.
pg_amproc now has unique index on amid+amopclaid+amprocnum.
Remove pg_rewrite's unnecessary index on oid, delete unused RULEOID syscache.
Remove index on pg_listener and associated syscache for performance reasons
(caching rows that are certain to change before you need 'em again is
rather pointless).
Change pg_attrdef's nonunique index on adrelid into a unique index on
adrelid+adnum.
Fix various incorrect settings of pg_class.relisshared, make that the
primary reference point for whether a relation is shared or not.
IsSharedSystemRelationName() is now only consulted to initialize relisshared
during initial creation of tables and indexes. In theory we might now
support shared user relations, though it's not clear how one would get
entries for them into pg_class &etc of multiple databases.
Fix recently reported bug that pg_attribute rows created for an index all have
the same OID. (Proof that non-unique OID doesn't matter unless it's
actually used to do lookups ;-))
There's no need to treat pg_trigger, pg_attrdef, pg_relcheck as bootstrap
relations. Convert them into plain system catalogs without hardwired
entries in pg_class and friends.
Unify global.bki and template1.bki into a single init script postgres.bki,
since the alleged distinction between them was misleading and pointless.
Not to mention that it didn't work for setting up indexes on shared
system relations.
Rationalize locking of pg_shadow, pg_group, pg_attrdef (no need to use
AccessExclusiveLock where ExclusiveLock or even RowExclusiveLock will do).
Also, hold locks until transaction commit where necessary.
directory (which can be made a symlink to put temp files on another disk).
Add code to delete leftover temp files during postmaster startup.
Bruce, with some kibitzing from Tom.
should be computed from total number of distinct values in whole
relation, not # distinct values we expect to have after restriction
clauses are applied.
for GRANT/REVOKE is now just that, not "CHANGE".
On the way, migrate some of the aclitem internal representation away from
the parser and build a real parse tree instead. Also add some 'const'
qualifiers.
appropriate pin-count manipulation, and instead use ReleaseAndReadBuffer.
Make use of the fact that the passed-in buffer (if there is one) must
be pinned to avoid grabbing the bufmgr spinlock when we are able to
return this same buffer. Eliminate unnecessary 'previous tuple' and
'next tuple' fields of HeapScanDesc and IndexScanDesc, thereby removing
a whole lot of bookkeeping from heap_getnext() and related routines.
checkpoint's redo pointer, not its undo pointer, per discussion in
pghackers a few days ago. No point in hanging onto undo information
until we have the ability to do something with it --- and this solves
a rather large problem with log space for long-running transactions.
Also, change all calls of write() to detect the case where write
returned a count less than requested, but failed to set errno.
Presume that this situation indicates ENOSPC, and give the appropriate
error message, rather than a random message associated with the previous
value of errno.
copy PUBLIC access rights into each newly created ACL entry. Instead
treat each ACL entry as independent flags. Also clean up some ugliness
in acl.h API.
WHERE (a = 1 or a = 2) and b = 42
and an index on (a,b), include the clause b = 42 in the indexquals
generated for each arm of the OR clause. Essentially this is an index-
driven conversion from CNF to DNF. Implementation is a bit klugy, but
better than not exploiting the extra quals at all ...
of costsize.c routines to pass Query root, so that costsize can figure
more things out by itself and not be so dependent on its callers to tell
it everything it needs to know. Use selectivity of hash or merge clause
to estimate number of tuples processed internally in these joins
(this is more useful than it would've been before, since eqjoinsel is
somewhat more accurate than before).
conditional rules (rules with WHERE clauses). We cannot support these
since there's noplace to hang a condition on a utility statement.
We caught the other case (attempt to attach a condition at rewrite time)
awhile ago, but this one escaped notice until now.
(vs. at the end of a normal sort). This ensures that explicit sorts
yield the same ordering as a btree index scan. To be really sure that
that equivalence holds, we use the btree entries in pg_amop to decide
whether we are looking at a '<' or '>' operator. For a sort operator
that has no btree association, we put the nulls at the front if the
operator is named '>' ... pretty grotty, but it does the right thing in
simple ASC and DESC cases, and at least there's no possibility of getting
a different answer depending on the plan type chosen.
Use --enable-nls to turn it on; see installation instructions for details.
See developer's guide how to make use of it in programs and how to add
translations.
psql sources have been almost fully prepared and an incomplete German
translation has been provided. In the backend, only elog() calls are
currently translatable, and the provided German translation file is more
of a placeholder.
given values that compare as unordered, make sure we reply that they
are equal, which is better than giving an arbitrary answer --- at least
it doesn't depend on which one is passed as which arg.
right, but it failed to get the padding case right.
This was obscured by subsequent application of bpchar() in all but one
regression test case, and that one didn't fail in an obvious way ---
trailing blanks are hard to see. Add another test case to make it
more obvious if it breaks again.
calls. This has never actually cached anything, because postgres.c does
each fastpath call as a separate transaction command, and so fastpath.c
would always decide that its cache was outdated. If it had worked, it
would now be failing for calls of oldstyle functions due to dangling
pointers in the FmgrInfo struct. Rip it out for simplicity and bug-
proofing.
report on old-style functions invoked by RI triggers. We had a number of
other places that were being sloppy about which memory context FmgrInfo
subsidiary data will be allocated in. Turns out none of them actually
cause a problem in 7.1, but this is for arcane reasons such as the fact
that old-style triggers aren't supported anyway. To avoid getting burnt
later, I've restructured the trigger support so that we don't keep trigger
FmgrInfo structs in relcache memory. Some other related cleanups too:
it's not really necessary to call fmgr_info at all while setting up
the index support info in relcache entries, because those ScanKeyEntry
structs are never used to invoke the functions. This should speed up
relcache initialization a tiny bit.
because cached fmgr info contained reference to a shorter-lived data
structure. Also guard against possibility that fmgr_info could fail,
leaving an incomplete entry present in the hash table.
when added by alter table add constraint. The first file
patches backend/commands/command.c and the latter is a patch
to the alter table regression test.
Stephan Szabo
basically want your guys feedback. I have sprinkled some of my q's thru
the text delimited with the @@ symbol. It seems to work perfectly.
[ Removed @@ comments because patch was reviewed. ]
At the moment it does CHECK constraints only, with inheritance. However,
due to the problem mentioned before with the mismatching between inherited
constraints it may be wise to disable the inheritance feature for a while.
it is written in an extensible fashion to support future dropping of other
types of constraint, and is well documented.
Please send me your comments, check my use of locking, updating of
indices, use of ERROR and NOTICE, etc. and I will rework the patch based
on feedback until everyone
is happy with it...
Christopher Kings
from an empty text string. This makes them consistent with the de facto
behavior of type char's I/O conversion functions, and avoids generating
text values with embedded nulls, which confuse many text operators.
the same tuple slot that the raw tuple came from, because that slot has
the wrong tuple descriptor. Store it into its own slot with the correct
descriptor, instead. This repairs problems with SPI functions seeing
inappropriate tuple descriptors --- for example, plpgsql code failing to
cope with SELECT FOR UPDATE.
Python) to support shared extension modules, I have learned that Guido
prefers the style of the attached patch to solve the above problem.
I feel that this solution is particularly appropriate in this case
because the following:
PglargeType
PgType
PgQueryType
are already being handled in the way that I am proposing for PgSourceType.
Jason Tishler
it does not support 64bit integers. AFAIK that's the default data type for
OIDs, so I am not surprised that this does not work. Use gcc instead.
BTW., 7.1 does not compile as is with gcc either, I believed the
required patches made it into the 7.1.1 release but obviously I missed
the deadline.
Since the ports mailing list does not seem to be archived I have attached
a copy of the patch (for 7.1 and 7.1.1).
I've just performed a build of a Watcom compiled version and found a couple
of bugs in the watcom specific part of that patch. Please use the attached
version instead.
Tegge, Bernd
to do that, but inconsistently.) Make bit type reject too short input,
too, per SQL. Since it no longer zero pads, 'zpbit*' has been renamed to
'bit*' in the source, hence initdb.
- New functions to create a portal using a prepared/saved
SPI plan or lookup an existing portal by name.
- Functions to fetch/move from/in portals. Results are placed
in the usual SPI_processed and SPI_tuptable, so the entire
set of utility functions can be used to gain attribute access.
- Prepared/saved SPI plans now use their own memory context
and SPI_freeplan(plan) can remove them.
- Tuple result sets (SPI_tuptable) now uses it's own memory
context and can be free'd by SPI_freetuptable(tuptab).
Enhancement of PL/pgSQL
- Uses generic named portals internally in FOR ... SELECT
loops to avoid running out of memory on huge result sets.
- Support for CURSOR and REFCURSOR syntax using the new SPI
functionality. Cursors used internally only need no explicit
transaction block. Refcursor variables can be used inside
of explicit transaction block to pass cursors between main
application and functions.
Jan
create_index_paths are not immediately discarded, but are available for
subsequent planner work. This allows avoiding redundant syscache lookups
in several places. Change interface to operator selectivity estimation
procedures to allow faster and more flexible estimation.
Initdb forced due to change of pg_proc entries for selectivity functions!
/*
* parse function
* This code is confusing because the database can accept
* relation.column, column.function, or relation.column.function.
* In these cases, funcname is the last parameter, and fargs are
* the rest.
*
* It can also be called as func(col) or func(col,col).
* In this case, Funcname is the part before parens, and fargs
* are the part in parens.
*
*/
Node *
ParseFuncOrColumn(ParseState *pstate, char *funcname, List *fargs,
bool agg_star, bool agg_distinct,
int precedence)
PageGetFreeSpace() was being called while not holding the buffer lock, which
not only could yield a garbage answer, but even if it's the right answer there
might be less space available after we reacquire the buffer lock.
Also repair potential deadlock introduced by my recent performance improvement
in RelationGetBufferForTuple(): it was possible for two heap_updates to try to
lock two buffers in opposite orders. The fix creates a global rule that
buffers of a single heap relation should be locked in decreasing block number
order. Currently, this only applies to heap_update; VACUUM can get away with
ignoring the rule since it holds exclusive lock on the whole relation anyway.
However, if we try to implement a VACUUM that can run in parallel with other
transactions, VACUUM will also have to obey the lock order rule.
with many NULLs ( inserting of NULL into indexed field cause
ERROR: MemoryContextAlloc: invalid request size)
As a workaround 'vacuum analyze' could be used.
This patch resolves the problem, please upply to 7.1.1 sources and
current cvs tree.
Oleg Bartunov
trees (mostly my fault). Repair. Also fix long-standing bug in ExecReplace:
after recomputing a concurrently updated tuple, we must recheck constraints.
Make EvalPlanQual leak memory with somewhat less enthusiasm than before,
although plugging leaks fully will require more changes than I care to risk
in a dot-release.
when we need to move to a new page; as long as we can insert the new
tuple on the same page as before, we only need LockBuffer and not the
expensive stuff. Also, twiddle bufmgr interfaces to avoid redundant
lseeks in RelationGetBufferForTuple and BufferAlloc. Successive inserts
now require one lseek per page added, rather than one per tuple with
several additional ones at each page boundary as happened before.
Lock contention when multiple backends are inserting in same table
is also greatly reduced.
not being consulted anywhere, so remove it and remove the _mdnblocks()
calls that were used to set it. Change smgrextend interface to pass in
the target block number (ie, current file length) --- the caller always
knows this already, having already done smgrnblocks(), so it's silly to
do it over again inside mdextend. Net result: extension of a file now
takes one lseek(SEEK_END) and a write(), not three lseeks and a write.
constraint names.
> > A reasonable interpretation of DROP CONSTRAINT "foo" is to drop *all*
> > constraints named "foo" on the target table.
>
> Then it should probably be a good thing to avoid the automatic
> generation of
> duplicate names? I might take a look at that, actually...
>
Christopher Kings-Lynne
in referencing and referenced columns of an fk constraint
aren't comparable using '=' at constraint definition time
rather than insert/update time.
Stephan Szabo
collected by ANALYZE. Also, add some modest amount of intelligence to
guesses that are used for varlena columns in the absence of any ANALYZE
statistics. The 'width' reported by EXPLAIN is finally something less
than totally bogus for varlena columns ... and, in consequence, hashjoin
estimating should be a little better ...
to their children, leading to misbehavior if they had any children that paid
attention to chgParam (most plan node types don't). Append's bug has been
there a long time, but nobody had noticed because it used to be difficult
to create a query where an Append would be used below the top level of a
plan; so there were never any parameters getting passed down. SubqueryScan
is new in 7.1 ... and I'd modeled its behavior on Append :-(
> cronjob:
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: InvalidateSharedInvalid: cache state reset
> I don't understand what these mean. Should I be concerned about them
> and what do they signify?
No real need to worry. Those should've been downgraded to DEBUG-level
messages a release or two back, but nobody bothered...
Tom Lane
a separate statement (though it can still be invoked as part of VACUUM, too).
pg_statistic redesigned to be more flexible about what statistics are
stored. ANALYZE now collects a list of several of the most common values,
not just one, plus a histogram (not just the min and max values). Random
sampling is used to make the process reasonably fast even on very large
tables. The number of values and histogram bins collected is now
user-settable via an ALTER TABLE command.
There is more still to do; the new stats are not being used everywhere
they could be in the planner. But the remaining changes for this project
should be localized, and the behavior is already better than before.
A not-very-related change is that sorting now makes use of btree comparison
routines if it can find one, rather than invoking '<' twice.
routine DetermineLocalTimeZone(). In that routine, be more wary of
broken mktime() implementations than the original code was: don't allow
mktime to change the already-set y/m/d/h/m/s information, and don't
use tm_gmtoff if mktime failed. Possibly this will resolve some of
the complaints we've been hearing from users of Middle Eastern timezones
on RedHat.
give consistent results for all datatypes. Types float4, float8, and
numeric were broken for NaN values; abstime, timestamp, and interval
were broken for INVALID values; timetz was just plain broken (some
possible pairs of values were neither < nor = nor >). Also clean up
text, bpchar, varchar, and bit/varbit to eliminate duplicate code and
thereby reduce the probability of similar inconsistencies arising in
the future.
This is an extension to the SQL9x standard, but is consistant with usage
of the underlying date_part() function used to implement it.
Example: EXTRACT('YEAR',...)
No impact on regression tests.
join. This is needed to avoid improper evaluation of expressions that
should be nulled out, as in Victor Wagner's bug report of 4/27/01.
Pretty ugly solution, but no time to do anything better for 7.1.1.
function arguments in join queries: copy the tuples into
TransactionCommandContext so they don't get recycled too soon. This is
horrid, but not any worse than 7.0 or before, which also leaked such
tuples until end of query. A proper fix will require allowing tuple
datums to be physically stored inside larger tuple datums, which opens
up a bunch of issues that can't realistically be solved for 7.1.1.
functions of join or subselect aliases. It'd be awfully nice if this
code knew for sure whether it was dealing with 'x.f' or 'f(x)' syntax;
maybe we can fix that in a future cycle.
or view that's been dropped and then recreated with the same name (but,
perhaps, different columns). Eventually we'd like to support this but
for now all we can do is fail cleanly, rather than possibly coredumping
if we proceed using the obsolete rule.
to specific base or join RelOptInfo nodes during planning. This preserves
the more-intuitive behavior of 7.0.* --- if you write an expensive clause
(such as a sub-select) last, it should get evaluated last. Someday we
ought to try to have some intelligence about the order of evaluation of
WHERE clauses, but for now we should not override what the user wrote.
only possible failure is in pq_flush, which will log a (better!) report
anyway --- so pq_endmessage is just cluttering the log with a redundant
entry. This matters when a client crashes partway through a large query,
since we will emit many broken-pipe reports before finishing the query
and exiting.
lists should be reverse-compiled into targetlist index numbers, because
that's the only interpretation the parser allows for a constant in these
clauses. (Ergo, the only way they could have gotten into the list in
the first place is to have come from the targetlist; so this should always
work.) Per problem report from Peter E.
join clauses. The mergejoin executor wants all the join clauses to appear
as merge quals, not as extra joinquals, for these kinds of joins. But the
planner would consider plans in which partially-sorted input paths were
used, leading to only some of the join clauses becoming merge quals.
This is fine for inner/left joins, not fine for right/full joins.
Although it was now using the right equation, it was making bogus choices
of the precision to compute intermediate results to. I'm not sure this
is really right even yet, but it's better than before ...
VFD entries. On platforms where dereferencing a null pointer doesn't
lead to coredump, it's possible that this omission could have led to
unpleasant behavior like deleting the wrong file.
physical file has disappeared. There is no really good reason why
relcache should be opening the underlying file at all, AFAICS.
In any case we needn't raise a hard error here.
with different default values, unless the child table redeclares the
column with an explicit default. This was judged to be the approach
least likely to cause unpleasant surprises.
in CREATE TABLE, but give a warning notice. Clean up inconsistent
handling of defaults and NOT NULL flags from multiply-inherited columns.
Per pghackers discussion 28-Mar through 30-Mar.
inheritance query: make duplicate copies of subplans in adjust_inherited_attrs.
When we redesign querytrees we really gotta do something about this
issue of whether querytrees are read-only and can share substructure
or not.
more recent versions of the IBM C++ compiler (now called VisualAge C++).
The C++ part was previously broken (g++ and xlC), thus this is zero risk.
Only AIX specific parts are touched (1 Makefile.shlib line (link with $(COMPILER
) instead
of $(CC) and one shell script line (parameter -C to nm to not demangle C++ symbo
ls for
.exp file)).
I thus ask you to please apply this patch before release.
With or without this patch RC1 on AIX 4.3.2 RS6000 passes "gmake check" for both
the native
compiler vac.C 5.0.1 and gcc 2.95.2 :-)
Andreas
accepts nnnLL syntax for long long constants. If so, decorate the CRC64
constants with LL to avoid warnings and/or erroneous results from certain
non-standards-compliant compilers.
on Alpha (because parser mistakenly assumes that a nonoverflow result
from strtol means the value will fit into int4). A scan for other uses
of strtol and strtoul found a couple other places with the same mistake;
fix them too. The changes are all conditional on HAVE_LONG_INT_64 to
avoid complaints from compilers that think x != x is a silly test
(cf. pg_atoi).
*before* acquiring shlock on buffer context. This way we should be
protected against conflicts with FlushRelationBuffers.
(Seems we never do excl lock and then StartBufferIO for the same
buffer, so there should be no deadlock here, - but we'd better
check this very soon).
O_SYNC, or O_DSYNC (as available on a given platform). Add GUC parameter
to control sync method.
Also, add defense to XLogWrite to prevent it from going nuts if passed
a target write position that's past the end of the buffers so far filled
by XLogInsert.
I'm not sure that it's really necessary to save insert events when there
are only after update or delete triggers, but certainly it's wrong for
COPY to behave differently from an INSERT query.
detect case that next page in log came from an older run than the prior
page. This avoids the necessity to re-zero the log after recovery from
a crash, which is good because we need not risk destroying valuable log
information.
This forces another initdb since yesterday :-(. Need to get that log
reset utility done...
* Store two past checkpoint locations, not just one, in pg_control.
On startup, we fall back to the older checkpoint if the newer one
is unreadable. Also, a physical copy of the newest checkpoint record
is kept in pg_control for possible use in disaster recovery (ie,
complete loss of pg_xlog). Also add a version number for pg_control
itself. Remove archdir from pg_control; it ought to be a GUC
parameter, not a special case (not that it's implemented yet anyway).
* Suppress successive checkpoint records when nothing has been entered
in the WAL log since the last one. This is not so much to avoid I/O
as to make it actually useful to keep track of the last two
checkpoints. If the things are right next to each other then there's
not a lot of redundancy gained...
* Change CRC scheme to a true 64-bit CRC, not a pair of 32-bit CRCs
on alternate bytes. Polynomial borrowed from ECMA DLT1 standard.
* Fix XLOG record length handling so that it will work at BLCKSZ = 32k.
* Change XID allocation to work more like OID allocation. (This is of
dubious necessity, but I think it's a good idea anyway.)
* Fix a number of minor bugs, such as off-by-one logic for XLOG file
wraparound at the 4 gig mark.
* Add documentation and clean up some coding infelicities; move file
format declarations out to include files where planned contrib
utilities can get at them.
* Checkpoint will now occur every CHECKPOINT_SEGMENTS log segments or
every CHECKPOINT_TIMEOUT seconds, whichever comes first. It is also
possible to force a checkpoint by sending SIGUSR1 to the postmaster
(undocumented feature...)
* Defend against kill -9 postmaster by storing shmem block's key and ID
in postmaster.pid lockfile, and checking at startup to ensure that no
processes are still connected to old shmem block (if it still exists).
* Switch backends to accept SIGQUIT rather than SIGUSR1 for emergency
stop, for symmetry with postmaster and xlog utilities. Clean up signal
handling in bootstrap.c so that xlog utilities launched by postmaster
will react to signals better.
* Standalone bootstrap now grabs lockfile in target directory, as added
insurance against running it in parallel with live postmaster.
tuples inserted/deleted/updated in a single transaction. On my machine,
this reduced the time to delete 80000 tuples in a foreign-key-referencing
table from ~15min to ~8sec.
of a counted input string. Marinos Yannikos' recent crash report turns
out to be due to applying pg_ascii2wchar_with_len to a TEXT object that
is smack up against the end of memory. This is the second just-barely-
reproducible bug report I have seen that traces to some bit of code
fetching one more byte than it is allowed to. Let's be more careful
out there, boys and girls.
While at it, I changed the code to not risk a similar crash when there
is a truncated multibyte character at the end of an input string. The
output in this case might not be the most reasonable output possible;
if anyone wants to improve it further, step right up...
succeeds or not. Revise rtree page split algorithm to take care about
making a feasible split --- ie, will the incoming tuple actually fit?
Failure to make a feasible split, combined with failure to notice the
failure, account for Jim Stone's recent bug report. I suspect that
hash and gist indices may have the same type of bug, but at least now
we'll get error messages rather than silent failures if so. Also clean
up rtree code to use Datum rather than char* where appropriate.
when user does another FETCH after reaching end of data, or another
FETCH backwards after reaching start. This is needed because some plan
nodes are not very robust about being called again after they've already
returned NULL; for example, MergeJoin will crash in some states but not
others. While the ideal approach would be for them all to handle this
correctly, it seems foolish to assume that no such bugs would creep in
again once cleaned up. Therefore, the most robust answer is to prevent
the situation from arising at all.
vacuum analyze on pg_type fails if bogus entries remain in pg_operator.
Here is a sample script to reproduce the problem.
drop table t1;
create table t1(i int);
drop function foo(t1,t1);
create function foo(t1,t1) returns bool as 'select true' language 'sql';
create operator = (
leftarg = t1,
rightarg = t1,
commutator = =,
procedure = foo
);
drop table t1;
vacuum analyze;
only if at least N other backends currently have open transactions. This
is not a great deal of intelligence about whether a delay might be
profitable ... but it beats no intelligence at all. Note that the default
COMMIT_DELAY is still zero --- this new code does nothing unless that
setting is changed.
Also, mark ENABLEFSYNC as a system-wide setting. It's no longer safe to
allow that to be set per-backend, since we may be relying on some other
backend's fsync to have synced the WAL log.
does not lead to a one-second delay, but to an immediate EINVAL failure.
This causes CHECKPOINT to crash with s_lock_stuck much too quickly :-(.
Fix by breaking down the requested wait div/mod 1e6.
> Is there one LOCKMETHODCTL for every backend? I thought there was only
> one of them.
>>
>> You're right, that line is erroneous; it should read
>>
>> size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
>>
>> Not a significant error but it should be changed for clarity ...
in Turkish locale. Keywords are now checked under pure ASCII case-folding
rules ('A'-'Z'->'a'-'z' and nothing else). However, once a word is
determined not to be a keyword, it will be case-folded under the current
locale, same as before. See pghackers discussion 20-Feb-01.
waste of cycles on single-CPU machines, and of dubious utility on multi-CPU
machines too.
Tweak s_lock_stuck so that caller can specify timeout interval, and
increase interval before declaring stuck spinlock for buffer locks and XLOG
locks.
On systems that have fdatasync(), use that rather than fsync() to sync WAL
log writes. Ensure that WAL file is entirely allocated during XLogFileInit.
either wrong or unnecessary in most cases, and on systems where setting
status takes a kernel call, the overhead of setting status three times
per command rather than two is annoying.
1. If there is exactly one pg_operator entry of the right name and oprkind,
oper() and related routines would return that entry whether its input type
had anything to do with the request or not. This is just premature
optimization: we shouldn't return the single candidate until after we verify
that it really is a valid candidate, ie, is at least coercion-compatible
with the given types.
2. oper() and related routines only promise a coercion-compatible result.
Unfortunately, there were quite a few callers that assumed the returned
operator is binary-compatible with the given datatype; they would proceed
to call it without making any datatype coercions. These callers include
sorting, grouping, aggregation, and VACUUM ANALYZE. In general I think
it is appropriate for these callers to require an exact or binary-compatible
match, so I've added a new routine compatible_oper() that only succeeds if
it can find an operator that doesn't require any run-time conversions.
Callers now call oper() or compatible_oper() depending on whether they are
prepared to deal with type conversion or not.
The upshot of these bugs is revealed by the following silliness in PL/Tcl's
selftest: it creates an operator @< on int4, and then tries to use it to
sort a char(N) column. The system would let it do that :-( (and evidently
has done so since 6.3 :-( :-(). The result in this case was just a silly
sort order, but the reverse combination would've provoked coredump from
trying to dereference integers. With this fix you get more reasonable
behavior:
pltcl_test=# select * from T_pkey1 order by key1, key2 using @<;
ERROR: Unable to identify an operator '@<' for types 'bpchar' and 'bpchar'
You will have to retype this query using an explicit cast
compressed storage works perfectly well. Might as well have a coherent
strategy for applying it, rather than the haphazard store-what-you-get
approach that was in the code before. The strategy I've set up here is
to attempt compression of any compressible index value exceeding
BLCKSZ/16, or about 500 bytes by default.
the old ones were not small enough to ensure r-tree and gist indexes would
get picked when available. These numbers are totally bogus anyway, but
in the absence of any real estimation technique, we'd like to select
indexes when available ...
such as
SELECT f1 FROM foo UNION SELECT ... ORDER BY upper(f1)
to draw
'ORDER BY on a UNION/INTERSECT/EXCEPT result must be on one of the result columns'
rather than the uninformative 'f1 not found' we were producing before.
Eventually this should actually work, but that looks much too hard to try
to implement in late beta...
clause with an alias is a <subquery> and therefore hides table references
appearing within it, according to the spec. This is the same as the
preliminary patch I posted to pgsql-patches yesterday, plus some really
grotty code in ruleutils.c to reverse-list a query tree with the correct
alias name depending on context. I'd rather not have done that, but unless
we want to force another initdb for 7.1, there's no other way for now.
as previously discussed.
It makes AIX and IRIX not use DST for dates before 1970.
The following expected files need to be removed from the regression tests,
they contain wrong results and are not needed any more.
src/test/regress/expected/horology-1947-PDT.out
src/test/regress/expected/tinterval-1947-PDT.out
src/test/regress/expected/abstime-1947-PDT.out
Zeugswetter Andreas
definitions from K&R to ANSI C style, and fix broken assumption that
int and long are the same datatype. This repairs problems observed
on Alpha with regexps having between 32 and 63 states.
two transactions create the same table name concurrently, the one that
fails will complain about unique index pg_class_relname_index, rather than
about pg_type_typname_index which'll confuse most people. Free side
benefit: pg_class.reltype is correctly linked to the pg_type entry now.
It's been zero in all but the preloaded pg_class entries since who knows
when.
are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
any other client connections that may exist (which would only happen if
another client is currently in the authentication cycle). This avoids
wastage of open descriptors in a child. It might also explain peculiar
behaviors like not closing connections when expected, since the kernel
will probably not signal EOF as long as some other backend is randomly
holding open a reference to the connection, even if the client went away
long since ...
elog(ERROR) not an Assert trap, since we've downgraded out-of-memory to
elog(ERROR) not a fatal error. Also, change the hard boundary from 256Mb
to 1Gb, just so that anyone who's actually got that much memory to spare
can play with TOAST objects approaching a gigabyte.
allocated by plan nodes are not leaked at end of query. This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions. Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.
original table ('OLD' table) in its join tree if OLD is referenced by
either the rule action, the rule qual, or the original query qual that
will be added to the rule action. However, we only want one instance
of the original table to be included; so beware of the possibility that
the rule action already has a jointree entry for OLD.
rather than coredumping (as prior 7.1 code did) or silently dropping the
condition (as 7.0 did). This is annoying but there doesn't seem to be
any good way to fix it, short of a major querytree restructuring.
actually) to ensure that its file access time doesn't get old enough to
tempt a /tmp directory cleaner to remove it. Still another reason we
should never have put the sockets in /tmp in the first place ...
truncating to integer. Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.
and new root page if old root one was splitted but new root page
wasn't created.
New code is protected by FixBTree bool flag setted to FALSE, so
nothing should be affected by this untested approach.