Tom Lane [Sun, 26 Apr 2009 15:31:50 +0000 (15:31 +0000)]
Remove Windows-specific definition of S_ISDIR(). This should not be here;
if there are any Windows configurations where port/win32.h fails to
provide the macro, it should be fixed in the latter file not here.
Tom Lane [Sun, 26 Apr 2009 02:47:05 +0000 (02:47 +0000)]
Update citext expected output to exactly match the real output, rather
than having some whitespace discrepancy. Although whitespace is supposed
to be ignored in our regression tests, for some reason buildfarm member
spoonbill doesn't like it.
Tom Lane [Sat, 25 Apr 2009 16:44:56 +0000 (16:44 +0000)]
Fix the handling of sub-SELECTs appearing in the arguments of an outer-level
aggregate function. By definition, such a sub-SELECT cannot reference any
variables of query levels between itself and the aggregate's semantic level
(else the aggregate would've been assigned to that lower level instead).
So the correct, most efficient implementation is to treat the sub-SELECT as
being a sub-select of that outer query level, not the level the aggregate
syntactically appears in. Not doing so also confuses the heck out of our
parameter-passing logic, as illustrated in bug report from Daniel Grace.
Fortunately, we were already copying the whole Aggref expression up to the
outer query level, so all that's needed is to delay SS_process_sublinks
processing of the sub-SELECT until control returns to the outer level.
This has been broken since we introduced spec-compliant treatment of
outer aggregates in 7.4; so patch all the way back.
Improve the documentation on 8.4 visibility map related VACUUM changes.
Explain how vacuum_freeze_table_age should be tuned, and how it relates
to the other settings. Mention that vacuum_freeze_table_age also affects
when autovacuum scans the whole table.
varstr_cmp and any comparison function that piggybacks on it can return
any negative or positive number, not just -1 or 1. Fix comment on
varstr_cmp and citext test case accordingly.
As pointed out by Zdenek Kotala, and buildfarm member gothic moth.
Tom Lane [Thu, 23 Apr 2009 00:23:46 +0000 (00:23 +0000)]
Change the default value of max_prepared_transactions to zero, and add
documentation warnings against setting it nonzero unless active use of
prepared transactions is intended and a suitable transaction manager has been
installed. This should help to prevent the type of scenario we've seen
several times now where a prepared transaction is forgotten and eventually
causes severe maintenance problems (or even anti-wraparound shutdown).
The only real reason we had the default be nonzero in the first place was to
support regression testing of the feature. To still be able to do that,
tweak pg_regress to force a nonzero value during "make check". Since we
cannot force a nonzero value in "make installcheck", add a variant regression
test "expected" file that shows the results that will be obtained when
max_prepared_transactions is zero.
Also, extend the HINT messages for transaction wraparound warnings to mention
the possibility that old prepared transactions are causing the problem.
After archive recovery, mark the last WAL segment from the parent timeline
ready for archival. It was marked at the next checkpoint anyway, but
waiting for the next checkpoint is an unnecessary delay.
Tom Lane [Tue, 21 Apr 2009 21:15:50 +0000 (21:15 +0000)]
Remove the long-obsolete homebrew dl*() functions for AIX, in favor of just
using the system functions all the time. (These files are now just copies
of the osf.* files.) The homebrew functions were not getting used anyway
on AIX versions that have dlopen(), that is 4.3 and up, so they are not
needed on any AIX that is even remotely supported by the vendor anymore.
We'd have probably left them here anyway, except some questions were
raised about the copyright.
Tom Lane [Sun, 19 Apr 2009 21:50:09 +0000 (21:50 +0000)]
Rethink the idea of having plpgsql depend on parser/gram.h. Aside from the
fact that this is breaking the MSVC build, it's probably not really a good
idea to expand the dependencies of gram.h any further than the core parser;
for instance the value of SCONST might depend on which bison version you'd
built with. Better to expose an additional call point in parser.c, so
move what I had put into pl_funcs.c into parser.c. Also PGDLLIMPORT'ify
the reference to standard_conforming_strings, per buildfarm results.
Tom Lane [Sun, 19 Apr 2009 19:46:33 +0000 (19:46 +0000)]
Fix estimate_num_groups() to not fail on PlaceHolderVars, per report from
Stefan Kaltenbrunner. The most reasonable behavior (at least for the near
term) seems to be to ignore the PlaceHolderVar and examine its argument
instead. In support of this, change the API of pull_var_clause() to allow
callers to request recursion into PlaceHolderVars. Currently
estimate_num_groups() is the only customer for that behavior, but where
there's one there may be others.
Tom Lane [Sun, 19 Apr 2009 18:52:58 +0000 (18:52 +0000)]
Revise plpgsql's scanner to process comments and string literals in a way
more nearly matching the core SQL scanner. The user-visible effects are:
* Block comments (slash-star comments) now nest, as per SQL spec.
* In standard_conforming_strings mode, backslash as the last character of a
non-E string literal is now correctly taken as an ordinary character;
formerly it was misinterpreted as escaping the ending quote. (Since the
string also had to pass through the core scanner, this invariably led
to syntax errors.)
* Formerly, backslashes in the format string of RAISE were always treated as
quoting the next character, regardless of mode. Now, they are ordinary
characters with standard_conforming_strings on, while with it off, they
introduce the same set of escapes as in the core SQL scanner. Also,
escape_string_warning is now effective for RAISE format strings. These
changes make RAISE format strings work just like any other string literal.
This is implemented by copying and pasting a lot of logic from the core
scanner. It would be a good idea to look into getting rid of plpgsql's
scanner entirely in favor of using the core scanner. However, that involves
more change than I can justify making during beta --- in particular, the core
scanner would have to become re-entrant.
In passing, remove the kluge that made the plpgsql scanner emit T_FUNCTION or
T_TRIGGER as a made-up first token. That presumably had some value once upon
a time, but now it's just useless complication for both the scanner and the
grammar.
Tom Lane [Sun, 19 Apr 2009 15:49:34 +0000 (15:49 +0000)]
Mention as a potential incompatibility the fact that SELECT DISTINCT, UNION,
etc are no longer guaranteed to produce sorted output; per gripe from Ian
Barwick. Also improve the release note entries about to_timestamp(), per
Brendan Jurd.
Tom Lane [Thu, 16 Apr 2009 20:42:16 +0000 (20:42 +0000)]
Fix planner to restore its previous level of intelligence about pushing
constants through full joins, as in
select * from tenk1 a full join tenk1 b using (unique1)
where unique1 = 42;
which should generate a fairly cheap plan where we apply the constraint
unique1 = 42 in each relation scan. This had been broken by my patch of
2008-06-27, which is now reverted in favor of a more invasive but hopefully
less incorrect approach. That patch was meant to prevent incorrect extraction
of OR'd indexclauses from OR conditions above an outer join. To do that
correctly we need more information than the outerjoin_delay flag can provide,
so add a nullable_relids field to RestrictInfo that records exactly which
relations are nulled by outer joins that are underneath a particular qual
clause. A side benefit is that we can make the test in create_or_index_quals
more specific: it is now smart enough to extract an OR'd indexclause into the
outer side of an outer join, even though it must not do so in the inner side.
The old coding couldn't distinguish these cases so it could not do either.
Tom Lane [Tue, 14 Apr 2009 22:18:47 +0000 (22:18 +0000)]
Fix broken {xufailed} production that made HEAD fail on
select u&42 from table-with-a-u-column;
Also fix missing SET_YYLLOC() in the {dolqfailed} production that I suppose
this was based on. The latter is a pre-existing bug, but the only effect
is to misplace the error cursor by one token, so probably not worth
backpatching.
Andrew Dunstan [Sun, 12 Apr 2009 21:02:44 +0000 (21:02 +0000)]
Fix logic to detect conflicts or blocks involving exclusive locks in parallel restore items.
If a currently running item needs an exclusive lock on any item that the candidate items needs
any sort of lock on, or vice versa, then the candidate item is not allowed to run now, and
must wait till later.
Tom Lane [Sat, 11 Apr 2009 20:23:05 +0000 (20:23 +0000)]
Fix pg_dumpall so that when --clean is specified, it drops roles and
tablespaces in an order that has some chance of working.
Per a complaint from Kevin Bailey.
This is a pre-existing bug, but given the lack of prior complaints I'm
not sure it's worth back-patching. In most cases failure of the DROP
commands wouldn't be that important anyway.
In passing, fix syntax errors in dumpCreateDB()'s queries for old servers;
these were apparently introduced in recent binary_upgrade patch.
Tom Lane [Thu, 9 Apr 2009 20:50:42 +0000 (20:50 +0000)]
Update time zone data files to tzdata release 2009e: DST law changes in
Argentina/San_Luis, Cuba, Jordan (historical correction only), Morocco,
Palestine, Syria, Tunisia.
Tom Lane [Thu, 9 Apr 2009 17:39:50 +0000 (17:39 +0000)]
Remove SQL-compatibility function cardinality(). It is not exactly clear
how this ought to behave for multi-dimensional arrays. Per discussion,
not having it at all seems better than having it with what might prove
to be the wrong behavior. We can always add it later when we have consensus
on the correct behavior.
Tom Lane [Thu, 9 Apr 2009 02:57:53 +0000 (02:57 +0000)]
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced
by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates:
since we re-prepared any expression tree when the current subtransaction ID
changed, we'd accumulate more and more leaked expression state trees in the
outermost subtransaction if the same function was executed at multiple levels
of subtransaction nesting. To fix, go back to the previous scheme where
there was only one EState per transaction for simple plpgsql expressions.
We really only need an ExprContext per subtransaction, not a whole EState,
so it's possible to keep prepared expression state trees in the one EState
throughout the transaction. This should be more efficient as well as not
leaking memory for cases involving lots of subtransactions.
The added regression test is the case that inspired the 2007-01-28 patch in
the first place, just to make sure we didn't go backwards. The current
memory leak complaint is unfortunately hard to test for in the regression
test framework, though manual testing shows it's fixed.
Although this is a pre-existing bug, I'm not back-patching because I'd like to
see this method get some field testing first. Consider back-patching if it
gets through 8.4beta unscathed.
Tom Lane [Wed, 8 Apr 2009 22:29:30 +0000 (22:29 +0000)]
Remove psql's ancient hack that suppressed functions taking or returning
cstring from the output of \df. Now that the default behavior is to
exclude all system functions, the de-cluttering rationale for this behavior
seems pretty weak; and it was always quite confusing/unhelpful if you were
actually looking for I/O functions. (Not to mention if you were looking
for encoding converters or other cases that might take or return cstring.)
XMLATTRIBUTES() should send the attribute values through
map_sql_value_to_xml_value() instead of directly through the data type output
function. This is per SQL standard, and consistent with XMLELEMENT().
Tell gettext which codeset to use by calling bind_textdomain_codeset(). We
already did that on Windows, but it's needed on other platforms too when
LC_CTYPE=C. With other locales, we enforce (or trust) that the codeset of
the locale matches the server encoding so we don't need to bind it
explicitly. It should do no harm in that case either, but I don't have
full faith in the PG encoding -> OS codeset mapping table yet. Per recent
discussion on pgsql-hackers.
Tom Lane [Tue, 7 Apr 2009 15:53:54 +0000 (15:53 +0000)]
Defend against non-ASCII letters in fuzzystrmatch code. The functions
still don't behave very sanely for multibyte encodings, but at least
they won't be indexing off the ends of static arrays.
Tom Lane [Tue, 7 Apr 2009 00:31:26 +0000 (00:31 +0000)]
Add an optional parameter to pg_start_backup() that specifies whether to do
the checkpoint in immediate or lazy mode. This is to address complaints
that pg_start_backup() takes a long time even when there's no need to minimize
its I/O consumption.