Tom Lane [Sun, 3 Aug 2008 19:10:52 +0000 (19:10 +0000)]
Make GROUP BY work properly for datatypes that only support hashing and not
sorting. The infrastructure for this was all in place already; it's only
necessary to fix the planner to not assume that sorting is always an available
option.
Tom Lane [Sun, 3 Aug 2008 15:23:58 +0000 (15:23 +0000)]
Tighten up the sanity checks in TypeCreate(): pass-by-value types must have
a size that is one of the supported values, not just anything <= sizeof(Datum).
Cross-check the alignment specification against size as well.
Tom Lane [Sun, 3 Aug 2008 05:12:38 +0000 (05:12 +0000)]
Fix copy-and-pasteo that's causing pg_regress to lie about which file it can't
read when the --temp-config argument is bad. Noted while wondering why
buildfarm member dungbeetle is failing ... this isn't why, but it is why
the error report isn't very helpful ...
Tom Lane [Sat, 2 Aug 2008 21:32:01 +0000 (21:32 +0000)]
Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT items
as per my recent proposal:
1. Fold SortClause and GroupClause into a single node type SortGroupClause.
We were already relying on them to be struct-equivalent, so using two node
tags wasn't accomplishing much except to get in the way of comparing items
with equal().
2. Add an "eqop" field to SortGroupClause to carry the associated equality
operator. This is cheap for the parser to get at the same time it's looking
up the sort operator, and storing it eliminates the need for repeated
not-so-cheap lookups during planning. In future this will also let us
represent GROUP/DISTINCT operations on datatypes that have hash opclasses
but no btree opclasses (ie, they have equality but no natural sort order).
The previous representation simply didn't work for that, since its only
indicator of comparison semantics was a sort operator.
3. Add a hasDistinctOn boolean to struct Query to explicitly record whether
the distinctClause came from DISTINCT or DISTINCT ON. This allows removing
some complicated and not 100% bulletproof code that attempted to figure
that out from the distinctClause alone.
This patch doesn't in itself create any new capability, but it's necessary
infrastructure for future attempts to use hash-based grouping for DISTINCT
and UNION/INTERSECT/EXCEPT.
Magnus Hagander [Fri, 1 Aug 2008 11:41:12 +0000 (11:41 +0000)]
Rearrange the code in auth.c so that all functions for a single authentication
method is grouped together in a reasonably similar way, keeping the "global
shared functions" together in their own section as well. Makes it a lot easier
to find your way around the code.
Magnus Hagander [Fri, 1 Aug 2008 09:09:49 +0000 (09:09 +0000)]
Move ident authentication code into auth.c along with the other authenciation
routines, leaving hba.c to deal only with processing the HBA specific files.
Tom Lane [Thu, 31 Jul 2008 22:47:56 +0000 (22:47 +0000)]
Fix parser so that we don't modify the user-written ORDER BY list in order
to represent DISTINCT or DISTINCT ON. This gets rid of a longstanding
annoyance that a view or rule using SELECT DISTINCT will be dumped out
with an overspecified ORDER BY list, and is one small step along the way
to decoupling DISTINCT and ORDER BY enough so that hash-based implementation
of DISTINCT will be possible. In passing, improve transformDistinctClause
so that it doesn't reject duplicate DISTINCT ON items, as was reported by
Steve Midgley a couple weeks ago.
Tom Lane [Thu, 31 Jul 2008 16:27:16 +0000 (16:27 +0000)]
Require superuser privilege to create base types (but not composites, enums,
or domains). This was already effectively required because you had to own
the I/O functions, and the I/O functions pretty much have to be written in
C since we don't let PL functions take or return cstring. But given the
possible security consequences of a malicious type definition, it seems
prudent to enforce superuser requirement directly. Per recent discussion.
Tom Lane [Wed, 30 Jul 2008 21:23:17 +0000 (21:23 +0000)]
Allow I/O conversion casts to be applied to or from any type that is a member
of the STRING type category, thereby opening up the mechanism for user-defined
types. This is mainly for the benefit of citext, though; there aren't likely
to be a lot of types that are all general-purpose character strings.
Per discussion with David Wheeler.
Tom Lane [Wed, 30 Jul 2008 19:35:13 +0000 (19:35 +0000)]
Flip the default typispreferred setting from true to false. This affects
only type categories in which the previous coding made *every* type
preferred; so there is no change in effective behavior, because the function
resolution rules only do something different when faced with a choice
between preferred and non-preferred types in the same category. It just
seems safer and less surprising to have CREATE TYPE default to non-preferred
status ...
Tom Lane [Wed, 30 Jul 2008 17:08:52 +0000 (17:08 +0000)]
Adjust citext to make use of the new ability to declare its type category:
by putting it into the standard string category, we cause casts from citext
to text to be recognized as "preferred" casts. This eliminates the need
for creation of alias functions and operators that only serve to prevent
ambiguous-function errors; get rid of the ones that were in the original
commit.
Tom Lane [Wed, 30 Jul 2008 17:05:05 +0000 (17:05 +0000)]
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
Magnus Hagander [Tue, 29 Jul 2008 15:17:27 +0000 (15:17 +0000)]
Document which versions of ActivePerl and ActiveTcl are required
for building on MSVC, and that the free distribution is enough
(no need for the enterprise version).
Tom Lane [Sat, 26 Jul 2008 19:15:35 +0000 (19:15 +0000)]
As noted by Andrew Gierth, there's really no need any more to force a junk
filter to be used when INSERT or SELECT INTO has a plan that returns raw
disk tuples. The virtual-tuple-slot optimizations that were put in place
awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
already copies the tuple if it's raw (and does so more efficiently than
a junk filter, too). So get rid of that logic. This in turn means that
we can throw away ExecMayReturnRawTuples, which wasn't used for any other
purpose, and was always a kluge anyway.
In passing, move a couple of SELECT-INTO-specific fields out of EState
and into the private state of the SELECT INTO DestReceiver, as was foreseen
in an old comment there. Also make intorel_receive use ExecMaterializeSlot
not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
a tuple copy step in some cases.
Tom Lane [Wed, 23 Jul 2008 17:29:53 +0000 (17:29 +0000)]
Use guc.c's parse_int() instead of pg_atoi() to parse fillfactor in
default_reloptions(). The previous coding was really a bug because pg_atoi()
will always throw elog on bad input data, whereas default_reloptions is not
supposed to complain about bad input unless its validate parameter is true.
Right now you could only expose the problem by hand-modifying
pg_class.reloptions into an invalid state, so it doesn't seem worth
back-patching; but we should get it right in HEAD because there might be other
situations in future. Noted while studying GIN fast-update patch.
Tom Lane [Mon, 21 Jul 2008 04:47:00 +0000 (04:47 +0000)]
Code review for array_fill patch: fix inadequate check for array size overflow
and bogus documentation (dimension arrays are int[] not anyarray). Also the
errhint() messages seem to be really errdetail(), since there is nothing
heuristic about them. Some other trivial cosmetic improvements.
Tom Lane [Sat, 19 Jul 2008 04:01:29 +0000 (04:01 +0000)]
Avoid substituting NAMEDATALEN, FLOAT4PASSBYVAL, and FLOAT8PASSBYVAL into
the postgres.bki file during build, because we want that file to be entirely
platform- and configuration-independent; else it can't safely be put into
/usr/share on multiarch machines. We can do the substitution during initdb,
instead. FLOAT4PASSBYVAL and FLOAT8PASSBYVAL are new breakage as of 8.4,
while the NAMEDATALEN hazard has been there all along but I guess no one
tripped over it. Noticed while trying to build "universal" OS X binaries.
Tom Lane [Fri, 18 Jul 2008 20:26:06 +0000 (20:26 +0000)]
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement. That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text. Fix it to copy the source text over
from the cached plan. Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.
There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
ProcessUtility((Node *) atstmt,
"(generated ALTER TABLE ADD FOREIGN KEY command)",
NULL, false, None_Receiver, NULL);
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
Tom Lane [Fri, 18 Jul 2008 14:45:48 +0000 (14:45 +0000)]
Fix a race condition that I introduced into sinvaladt.c during the recent
rewrite. When called from SIInsertDataEntries, SICleanupQueue releases
the write lock if it has to issue a kill() to signal some laggard backend.
That still seems like a good idea --- but it's possible that by the time
we get the lock back, there are no longer enough free message slots to
satisfy SIInsertDataEntries' requirement. Must recheck, and repeat the
whole SICleanupQueue process if not. Noted while reading code.
Tom Lane [Fri, 18 Jul 2008 04:20:24 +0000 (04:20 +0000)]
Suppress compiler warning, and not incidentally make the code more
robust. The previous coding was quite risky because it was testing
conditions different from 'is the array really allocated?'.
Tom Lane [Wed, 16 Jul 2008 16:55:24 +0000 (16:55 +0000)]
Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates(). Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.
In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.
Tom Lane [Wed, 16 Jul 2008 01:30:23 +0000 (01:30 +0000)]
Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).
It might be useful to extend this facility to aggregates, but this patch
doesn't do that.
This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.
Tom Lane [Mon, 14 Jul 2008 03:22:32 +0000 (03:22 +0000)]
Clean up buildfarm failures arising from the seemingly straightforward page
macros patch :-(. Results from both baiji and mastodon imply that MSVC
fails to perceive offsetof(PageHeaderData, pd_linp[0]) as a constant
expression in some contexts where offsetof(PageHeaderData, pd_linp) works
fine. Sloth, thy name is Micro.
Tom Lane [Mon, 14 Jul 2008 00:51:46 +0000 (00:51 +0000)]
Create a type-specific typanalyze routine for tsvector, which collects stats
on the most common individual lexemes in place of the mostly-useless default
behavior of counting duplicate tsvectors. Future work: create selectivity
estimation functions that actually do something with these stats.
(Some other things we ought to look at doing: using the Lossy Counting
algorithm in compute_minimal_stats, and using the element-counting idea for
stats on regular arrays.)
Tom Lane [Sun, 13 Jul 2008 21:50:04 +0000 (21:50 +0000)]
Change the PageGetContents() macro to guarantee its result is maxalign'd,
thereby forestalling any problems with alignment of the data structure placed
there. Since SizeOfPageHeaderData is maxalign'd anyway in 8.3 and HEAD, this
does not actually change anything right now, but it is foreseeable that the
header size will change again someday. I had to fix a couple of places that
were assuming that the content offset is just SizeOfPageHeaderData rather than
MAXALIGN(SizeOfPageHeaderData). Per discussion of Zdenek's page-macros patch.
Tom Lane [Sun, 13 Jul 2008 20:45:47 +0000 (20:45 +0000)]
Clean up the use of some page-header-access macros: principally, use
SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that
makes the code clearer, and avoid casting between Page and PageHeader where
possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas.
I did not apply the parts of the proposed patch that would have resulted in
slightly changing the on-disk format of hash indexes; it seems to me that's
not a win as long as there's any chance of having in-place upgrade for 8.4.
Tom Lane [Sat, 12 Jul 2008 02:28:43 +0000 (02:28 +0000)]
Don't make --enable-cassert turn on RANDOMIZE_ALLOCATED_MEMORY automatically;
it's just too dang expensive. Per recent discussion, but I just got my
nose rubbed in it again while doing some performance checking.
Tom Lane [Sat, 12 Jul 2008 00:44:38 +0000 (00:44 +0000)]
Const-ify the arguments of str_tolower() and friends to suppress compile
warnings. Clean up various unneeded cruft that was left behind after
creating those routines. Introduce some convenience functions str_tolower_z
etc to eliminate tedious and error-prone double arguments in formatting.c.
(Currently there seems no need to export the latter, but maybe reconsider
this later.)
Make sure we only try to free snapshots that have been passed through
CopySnapshot, per Neil Conway. Also add a comment about the assumption in
GetSnapshotData that the argument is statically allocated.
Also, fix some more typos in comments in snapmgr.c.
Tom Lane [Thu, 10 Jul 2008 22:08:17 +0000 (22:08 +0000)]
Add unchangeable GUC "variables" segment_size, wal_block_size, and
wal_segment_size to make those configuration parameters available to clients,
in the same way that block_size was previously exposed. Bernd Helmle, with
comments from Abhijit Menon-Sen and some further tweaking by me.
Tom Lane [Thu, 10 Jul 2008 02:14:03 +0000 (02:14 +0000)]
Tighten up SS_finalize_plan's computation of valid_params to exclude Params of
the current query level that aren't in fact output parameters of the current
initPlans. (This means, for example, output parameters of regular subplans.)
To make this work correctly for output parameters coming from sibling
initplans requires rejiggering the API of SS_finalize_plan just a bit:
we need the siblings to be visible to it, rather than hidden as
SS_make_initplan_from_plan had been doing. This is really part of my response
to bug #4290, but I concluded this part probably shouldn't be back-patched,
since all that it's doing is to make a debugging cross-check tighter.
Tom Lane [Thu, 10 Jul 2008 01:17:29 +0000 (01:17 +0000)]
Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290. The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan. On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely. The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.
I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.
Back-patch to 8.1. Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed. So I'll
refrain from changing them for now.
Tom Lane [Wed, 9 Jul 2008 15:56:49 +0000 (15:56 +0000)]
Increase PG_SYSLOG_LIMIT (the max line length sent to syslog()) from 128 to
1024 to improve performance when sending large elog messages. Also add a
comment about why we use that number.
Since this represents an externally visible behavior change, and might
possibly result in portability issues, it seems best not to back-patch it.
Tom Lane [Tue, 8 Jul 2008 22:17:41 +0000 (22:17 +0000)]
Fix performance bug in write_syslog(): the code to preferentially break the
log message at newlines cost O(N^2) for very long messages with few or no
newlines. For messages in the megabyte range this became the dominant cost.
Per gripe from Achilleas Mantzios.
Patch all the way back, since this is a safe change with no portability
risks. I am also thinking of increasing PG_SYSLOG_LIMIT, but that should
be done separately.
Tom Lane [Mon, 7 Jul 2008 20:24:55 +0000 (20:24 +0000)]
Fix estimate_num_groups() to assume that GROUP BY expressions yielding boolean
results always contribute two groups, regardless of the expression contents.
This is very substantially more accurate than the regular heuristic for
certain boolean tests like "col IS NULL". Per gripe from Sam Mason.
Back-patch to all supported releases, since the behavior of
estimate_num_groups() hasn't changed all that much since 7.4.
Tom Lane [Mon, 7 Jul 2008 18:09:46 +0000 (18:09 +0000)]
Fix AT TIME ZONE (in all three variants) so that we first try to interpret
the timezone argument as a timezone abbreviation, and only try it as a full
timezone name if that fails. The zic database has four zones (CET, EET, MET,
WET) that are full daylight-savings zones and yet have names that are the
same as their abbreviations for standard time, resulting in ambiguity.
In the timestamp input functions we resolve the ambiguity by preferring the
abbreviation, and AT TIME ZONE should work the same way. (No functionality
is lost because the zic database also has other names for these zones, eg
Europe/Zurich.) Per gripe from Jaromir Talir.
Backpatch to 8.1. Older releases did not have the issue because AT TIME ZONE
only accepted abbreviations not zone names. (Thus, this patch also arguably
fixes a compatibility botch introduced at 8.1: in ambiguous cases we now
behave the same as 8.0 did.)
Tom Lane [Sun, 6 Jul 2008 19:48:45 +0000 (19:48 +0000)]
Prevent integer overflows during units conversion when displaying a GUC
variable that has units. Per report from Stefan Kaltenbrunner.
Backport to 8.2. I also backported my patch of 2007-06-21 that prevented
comparable overflows on the input side, since that now seems to have enough
field track record to be back-patched safely. That patch included addition
of hints listing the available unit names, which I did not bother to strip
out of it --- this will make a little more work for the translators, but
they can copy the translation from 8.3, and anyway an untranslated hint
is better than no hint.
Magnus Hagander [Fri, 4 Jul 2008 10:50:18 +0000 (10:50 +0000)]
Fix a couple of bugs in win32 shmem name generation:
* Don't cut off the prefix. With this fix, it's again readable.
* Properly store it in the Global namespace as intended.
Joe Conway [Thu, 3 Jul 2008 03:56:57 +0000 (03:56 +0000)]
When an ERROR happens on a dblink remote connection, take
pains to pass the ERROR message components locally, including
using the passed SQLSTATE. Also wrap the passed info in an
appropriate CONTEXT message. Addresses complaint by Henry
Combrinck. Joe Conway, with much good advice from Tom Lane.