Bruce Momjian [Sat, 7 May 2005 15:45:23 +0000 (15:45 +0000)]
Add description:
< Currently locale can only be set during initdb.
> Currently locale can only be set during initdb. No global tables have
> locale-aware columns. However, the database template used during
> database creation might have locale-aware indexes. The indexes would
> need to be reindexed to match the new locale.
Neil Conway [Sat, 7 May 2005 05:48:50 +0000 (05:48 +0000)]
Revert the ld --as-needed patch. This breaks Fedora Core 3, due to a strange
interaction between ld, readline, termcap, and psql. The symptom is psql
failing with this error on startup:
symbol lookup error: /usr/lib64/libreadline.so.4: undefined symbol: BC
I'm still trying to find the best way to solve this, but in the mean time
I'm reverting the patch in order to unbreak FC3.
Bruce Momjian [Sat, 7 May 2005 04:24:34 +0000 (04:24 +0000)]
Add items:
> * Prevent to_char() on interval from returning meaningless values
>
> For example, to_char('1 month', 'mon') is meaningless. Basically,
> most date-related parameters to to_char() are meaningless for
> intervals because interval is not anchored to a date.
>
> * Allow to_char() on interval values to accumulate the highest unit
> requested
>
> o to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
> o to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
> o to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
> o to_char(INTERVAL '3 years 5 months','MM') => 41
>
> Some special format flag would be required to request such
> accumulation. Such functionality could also be added to EXTRACT.
> Prevent accumulation that crosses the month/day boundary because of
> the uneven number of days in a month.
>
Tom Lane [Fri, 6 May 2005 17:24:55 +0000 (17:24 +0000)]
For some reason access/tupmacs.h has been #including utils/memutils.h,
which is neither needed by nor related to that header. Remove the bogus
inclusion and instead include the header in those C files that actually
need it. Also fix unnecessary inclusions and bad inclusion order in
tsearch2 files.
Tom Lane [Fri, 6 May 2005 00:19:14 +0000 (00:19 +0000)]
Marginal performance improvements in dynahash: make sure that everything
associated with a hashtable is allocated in that hashtable's private
context, so that hash_destroy only has to destroy the context and not
do any retail pfree's; and tighten the inner loop of hash_seq_search.
Bruce Momjian [Thu, 5 May 2005 19:15:54 +0000 (19:15 +0000)]
On Win32, libintl replaces snprintf() with its own version that
understands arg control, so we don't need our own. In fact, it
also uses macros that conflict with ours, so we _can't_ use
our own.
Neil Conway [Thu, 5 May 2005 11:50:18 +0000 (11:50 +0000)]
The issue has been raised in the past that our build system links each
executable against the maximal set of libraries it might need. So for
example, if one executable requires `libreadline', all executables are
linked against it.
The easiest fix is to make use of GNU ld's --as-needed flag, which
ignores linker arguments that are not actually needed by the specified
object files. The attached patch modifies configure to check for this
flag (when using GNU ld), and if ld supports it, adds the flag to
LDFLAGS (we need to do the check since only relatively recent versions
of GNU ld support this capability). Currently only GNU ld is supported;
I'm not aware of any other linkers that support this functionality.
Tom Lane [Thu, 5 May 2005 03:37:23 +0000 (03:37 +0000)]
Adjust nodeBitmapIndexscan to keep the target index opened from plan
startup to end, rather than re-opening it in each MultiExecBitmapIndexScan
call. I had foolishly thought that opening/closing wouldn't be much
more expensive than a rescan call, but that was sheer brain fade.
This seems to fix about half of the performance lossage reported by
Sergey Koposov. I'm still not sure where the other half went.
Tom Lane [Thu, 5 May 2005 00:19:47 +0000 (00:19 +0000)]
Allow implicit cast from any named composite type to RECORD. At the
moment this has no particular use except to allow table rows to be
passed to record_out(), but that case seems to be useful in itself
per recent example from Elein. Further down the road we could look
at letting PL functions be declared to accept RECORD parameters.
Tom Lane [Tue, 3 May 2005 19:42:41 +0000 (19:42 +0000)]
Clean up MultiXactIdExpand's API by separating out the case where we
are creating a new MultiXactId from two regular XIDs. The original
coding was unnecessarily complicated and didn't save any code anyway.
Tom Lane [Tue, 3 May 2005 19:17:59 +0000 (19:17 +0000)]
Alter the signature for encoding conversion functions to declare the
output area as INTERNAL not CSTRING. This is to prevent people from
calling the functions by hand. This is a permanent solution for the
back branches but I hope it is just a stopgap for HEAD.
Tom Lane [Tue, 3 May 2005 16:51:00 +0000 (16:51 +0000)]
Change tsearch2 to not use the unsafe practice of creating functions
that return INTERNAL without also having INTERNAL arguments. Since the
functions in question aren't meant to be called by hand anyway, I just
redeclared them to take 'internal' instead of 'text'. Also add code
to ProcedureCreate() to enforce the restriction, as I should have done
to start with :-(
Neil Conway [Mon, 2 May 2005 00:37:07 +0000 (00:37 +0000)]
Change SPI functions to use a `long' when specifying the number of tuples
to produce when running the executor. This is consistent with the internal
executor APIs (such as ExecutorRun), which also use a long for this purpose.
It also allows FETCH_ALL to be passed -- since FETCH_ALL is defined as
LONG_MAX, this wouldn't have worked on platforms where int and long are of
different sizes. Per report from Tzahi Fadida.
Tom Lane [Sun, 1 May 2005 18:56:19 +0000 (18:56 +0000)]
Change CREATE TYPE to require datatype output and send functions to have
only one argument. (Per recent discussion, the option to accept multiple
arguments is pretty useless for user-defined types, and would be a likely
source of security holes if it was used.) Simplify call sites of
output/send functions to not bother passing more than one argument.
Tom Lane [Sat, 30 Apr 2005 20:31:39 +0000 (20:31 +0000)]
Change catalog entries for record_out and record_send to show only one
argument, since that's all they are using now. Adjust type_sanity
regression test so that it will complain if anyone tries to define
multiple-argument output functions in future.
Tom Lane [Sat, 30 Apr 2005 20:04:33 +0000 (20:04 +0000)]
Make record_out and record_send extract type information from the passed
record object itself, rather than relying on a second OID argument to be
correct. This patch just changes the function behavior and not the
catalogs, so it's OK to back-patch to 8.0. Will remove the now-redundant
second argument in pg_proc in a separate patch in HEAD only.
Tom Lane [Sat, 30 Apr 2005 19:03:33 +0000 (19:03 +0000)]
Use the standard lock manager to establish priority order when there
is contention for a tuple-level lock. This solves the problem of a
would-be exclusive locker being starved out by an indefinite succession
of share-lockers. Per recent discussion with Alvaro.
Neil Conway [Sat, 30 Apr 2005 08:08:51 +0000 (08:08 +0000)]
GCC 4.0 includes a new warning option, -Wformat-literal, that emits
a warning when a variable is used as a format string for printf()
and similar functions (if the variable is derived from untrusted
data, it could include unexpected formatting sequences). This
emits too many warnings to be enabled by default, but it does
flag a few dubious constructs in the Postgres tree. This patch
fixes up the obvious variants: functions that are passed a variable
format string but no additional arguments.
Most of these are harmless (e.g. the ruleutils stuff), but there
is at least one actual bug here: if you create a trigger named
"%sfoo", pg_dump will read uninitialized memory and fail to dump
the trigger correctly.
Tom Lane [Fri, 29 Apr 2005 22:28:24 +0000 (22:28 +0000)]
Restructure LOCKTAG as per discussions of a couple months ago.
Essentially, we shoehorn in a lockable-object-type field by taking
a byte away from the lockmethodid, which can surely fit in one byte
instead of two. This allows less artificial definitions of all the
other fields of LOCKTAG; we can get rid of the special pg_xactlock
pseudo-relation, and also support locks on individual tuples and
general database objects (including shared objects). None of those
possibilities are actually exploited just yet, however.
I removed pg_xactlock from pg_class, but did not force initdb for
that change. At this point, relkind 's' (SPECIAL) is unused and
could be removed entirely.
Neil Conway [Fri, 29 Apr 2005 07:08:06 +0000 (07:08 +0000)]
This patch fixes a bug in the error message emitted by pg_restore on an
incorrect -F argument: write_msg() expects its first parameter to be a
"module name", not the format string.
Tom Lane [Thu, 28 Apr 2005 21:47:18 +0000 (21:47 +0000)]
Implement sharable row-level locks, and use them for foreign key references
to eliminate unnecessary deadlocks. This commit adds SELECT ... FOR SHARE
paralleling SELECT ... FOR UPDATE. The implementation uses a new SLRU
data structure (managed much like pg_subtrans) to represent multiple-
transaction-ID sets. When more than one transaction is holding a shared
lock on a particular row, we create a MultiXactId representing that set
of transactions and store its ID in the row's XMAX. This scheme allows
an effectively unlimited number of row locks, just as we did before,
while not costing any extra overhead except when a shared lock actually
has to be shared. Still TODO: use the regular lock manager to control
the grant order when multiple backends are waiting for a row lock.
Bruce Momjian [Thu, 28 Apr 2005 13:09:59 +0000 (13:09 +0000)]
Add psql \set ON_ERROR_ROLLBACK to allow statements in a transaction to
error without affecting the entire transaction. Valid values are
"on|interactive|off".
Tom Lane [Mon, 25 Apr 2005 21:03:25 +0000 (21:03 +0000)]
Fix ExpandIndirectionStar to handle cases where the expression to be
expanded is of RECORD type, eg
'select (foo).* from (select foo(f1) from t1) ss'
where foo() is a function declared with multiple OUT parameters.
Tom Lane [Mon, 25 Apr 2005 20:59:44 +0000 (20:59 +0000)]
get_expr_result_type probably needs to be able to handle OpExpr as well
as FuncExpr, to cover cases where a function returning tuple is invoked
via an operator.
Bruce Momjian [Mon, 25 Apr 2005 15:35:32 +0000 (15:35 +0000)]
Update description:
< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
> * Allow ORDER BY ... LIMIT # to select high/low value without sort or 868c868
< Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
> Right now, if no index exists, ORDER BY ... LIMIT # requires we sort 870a871
> MIN/MAX already does this, but not for LIMIT > 1.
Bruce Momjian [Mon, 25 Apr 2005 13:03:37 +0000 (13:03 +0000)]
Re-add item with better description:
> * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
> index using a sequential scan for highest/lowest values
>
> Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
> all values to return the high/low value. Instead The idea is to do a
> sequential scan to find the high/low value, thus avoiding the sort.
>
Tom Lane [Mon, 25 Apr 2005 03:58:30 +0000 (03:58 +0000)]
While determining the filter clauses for an index scan (either plain
or bitmap), use pred_test to be a little smarter about cases where a
filter clause is logically unnecessary. This may be overkill for the
plain indexscan case, but it's definitely useful for OR'd bitmap scans.
Tom Lane [Mon, 25 Apr 2005 02:14:48 +0000 (02:14 +0000)]
Replace slightly klugy create_bitmap_restriction() function with a
more efficient routine in restrictinfo.c (which can make use of
make_restrictinfo_internal).
Bruce Momjian [Mon, 25 Apr 2005 01:42:41 +0000 (01:42 +0000)]
Add description for concurrent sequential scans:
> One possible implementation is to start sequential scans from the lowest
> numbered buffer in the shared cache, and when reaching the end wrap
> around to the beginning, rather than always starting sequential scans
> at the start of the table.
Tom Lane [Mon, 25 Apr 2005 01:30:14 +0000 (01:30 +0000)]
Remove support for OR'd indexscans internal to a single IndexScan plan
node, as this behavior is now better done as a bitmap OR indexscan.
This allows considerable simplification in nodeIndexscan.c itself as
well as several planner modules concerned with indexscan plan generation.
Also we can improve the sharing of code between regular and bitmap
indexscans, since they are now working with nigh-identical Plan nodes.
Tom Lane [Sun, 24 Apr 2005 18:16:38 +0000 (18:16 +0000)]
Adjust nodeBitmapIndexscan.c to not keep the index open across calls,
but just to open and close it during MultiExecBitmapIndexScan. This
avoids acquiring duplicate resources (eg, multiple locks on the same
relation) in a tree with many bitmap scans. Also, don't bother to
lock the parent heap at all here, since we must be underneath a
BitmapHeapScan node that will be holding a suitable lock.
Bruce Momjian [Sun, 24 Apr 2005 12:39:07 +0000 (12:39 +0000)]
Update wording:
< This allows vacuum to reclaim free space without requiring
< a sequential scan
> This allows vacuum to target specific pages for possible free space
> without requiring a sequential scan.
Tom Lane [Sat, 23 Apr 2005 22:53:05 +0000 (22:53 +0000)]
Repair two TIME WITH TIME ZONE bugs found by Dennis Vshivkov. Comparison
of timetz values misbehaved in --enable-integer-datetime cases, and
EXTRACT(EPOCH) subtracted the zone instead of adding it in all cases.
Backpatch to all supported releases (except --enable-integer-datetime code
does not exist in 7.2).
Tom Lane [Sat, 23 Apr 2005 22:09:58 +0000 (22:09 +0000)]
Remove useless argtype_inherit() code, and make consequent simplifications.
As I pointed out a few days ago, this code has failed to do anything useful
for some time ... and if we did want to revive the capability to select
functions by nearness of inheritance ancestry, this is the wrong place
and way to do it anyway. The knowledge would need to go into
func_select_candidate() instead. Perhaps someday someone will be motivated
to do that, but I am not today.
Bruce Momjian [Sat, 23 Apr 2005 21:44:52 +0000 (21:44 +0000)]
Item already added to existing 'thread' item:
< * Consider parallel processing a single query
<
< This would involve using multiple threads or processes to do optimization,
< sorting, or execution of single query. The major advantage of such a
< feature would be to allow multiple CPUs to work together to process a
< single query.
<
Bruce Momjian [Sat, 23 Apr 2005 21:43:24 +0000 (21:43 +0000)]
Remove item, not sure what it refers to:
< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
< index using a sequential scan for highest/lowest values
<
< If only one value is needed, there is no need to sort the entire
< table. Instead a sequential scan could get the matching value.
<
Bruce Momjian [Sat, 23 Apr 2005 21:39:27 +0000 (21:39 +0000)]
Update threading item:
< Solaris) might benefit from threading.
> Solaris) might benefit from threading. Also explore the idea of
> a single session using multiple threads to execute a query faster.
Tom Lane [Sat, 23 Apr 2005 21:32:34 +0000 (21:32 +0000)]
Remove explicit FreeExprContext calls during plan node shutdown. The
ExprContexts will be freed anyway when FreeExecutorState() is reached,
and letting that routine do the work is more efficient because it will
automatically free the ExprContexts in reverse creation order. The
existing coding was effectively freeing them in exactly the worst
possible order, resulting in O(N^2) behavior inside list_delete_ptr,
which becomes highly visible in cases with a few thousand plan nodes.
ExecFreeExprContext is now effectively a no-op and could be removed,
but I left it in place in case we ever want to put it back to use.