Tom Lane [Tue, 6 Feb 2007 22:49:24 +0000 (22:49 +0000)]
Fix an error in the original coding of holdable cursors: PersistHoldablePortal
thought that it didn't have to reposition the underlying tuplestore if the
portal is atEnd. But this is not so, because tuplestores have separate read
and write cursors ... and the read cursor hasn't moved from the start.
This mistake explains bug #2970 from William Zhang.
Note: the coding here is pretty inefficient, but given that no one has noticed
this bug until now, I'd say hardly anyone uses the case where the cursor has
been advanced before being persisted. So maybe it's not worth worrying about.
Bruce Momjian [Tue, 6 Feb 2007 18:31:26 +0000 (18:31 +0000)]
Update timezone FAQ item:
<P>USA saving time changes are included in PostgreSQL release 8.0.[4+],
and all later major releases, e.g. 8.1. Canada and Western Australia
changes are included in 8.0.[10+], 8.1.[6+], and all later major
releases. PostgreSQL releases prior to 8.0 use the operating system's
timezone database for daylight saving information.</P>
Tom Lane [Tue, 6 Feb 2007 17:35:20 +0000 (17:35 +0000)]
Remove typmod checking from the recent security-related patches. It turns
out that ExecEvalVar and friends don't necessarily have access to a tuple
descriptor with correct typmod: it definitely can contain -1, and possibly
might contain other values that are different from the Var's value.
Arguably this should be cleaned up someday, but it's not a simple change,
and in any case typmod discrepancies don't pose a security hazard.
Per reports from numerous people :-(
I'm not entirely sure whether the failure can occur in 8.0 --- the simple
test cases reported so far don't trigger it there. But back-patch the
change all the way anyway.
Move NAMEDATALEN definition from postgres_ext.h to pg_config_manual.h. It
used to be part of libpq's exported interface many releases ago, but now
it's no longer necessary to make it accessible to clients.
Tom Lane [Tue, 6 Feb 2007 06:50:26 +0000 (06:50 +0000)]
Fix a performance regression in 8.2: optimization of MIN/MAX into indexscans
had stopped working for tables buried inside views or sub-selects. This is
because I had gotten rid of the simplify_jointree() preprocessing step, and
optimize_minmax_aggregates() wasn't smart enough to deal with a non-canonical
FromExpr. Per gripe from Bill Howe.
Tom Lane [Tue, 6 Feb 2007 02:59:15 +0000 (02:59 +0000)]
Add support for cross-type hashing in hashed subplans (hashed IN/NOT IN cases
that aren't turned into true joins). Since this is the last missing bit of
infrastructure, go ahead and fill out the hash integer_ops and float_ops
opfamilies with cross-type operators. The operator family project is now
DONE ... er, except for documentation ...
Bruce Momjian [Mon, 5 Feb 2007 17:17:13 +0000 (17:17 +0000)]
Updated TODO item:
> o Add a \set variable to control whether \s displays line numbers
> Another option is to add \# which lists line numbers, and
> allows command execution.
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Tom Lane [Mon, 5 Feb 2007 04:22:18 +0000 (04:22 +0000)]
Rename MaxTupleSize to MaxHeapTupleSize to clarify that it's not meant to
describe the maximum size of index tuples (which is typically AM-dependent
anyway); and consequently remove the bogus deduction for "special space"
that was built into it.
Adjust TOAST_TUPLE_THRESHOLD and TOAST_MAX_CHUNK_SIZE to avoid wasting two
bytes per toast chunk, and to ensure that the calculation correctly tracks any
future changes in page header size. The computation had been inaccurate in a
way that didn't cause any harm except space wastage, but future changes could
have broken it more drastically.
Fix the calculation of BTMaxItemSize, which was formerly computed as 1 byte
more than it could safely be. This didn't cause any harm in practice because
it's only compared against maxalign'd lengths, but future changes in the size
of page headers or btree special space could have exposed the problem.
initdb forced because of change in TOAST_MAX_CHUNK_SIZE, which alters the
storage of toast tables.
Tom Lane [Sun, 4 Feb 2007 20:00:37 +0000 (20:00 +0000)]
Don't MAXALIGN in the checks to decide whether a tuple is over TOAST's
threshold for tuple length. On 4-byte-MAXALIGN machines, the toast code
creates tuples that have t_len exactly TOAST_TUPLE_THRESHOLD ... but this
number is not itself maxaligned, so if heap_insert maxaligns t_len before
comparing to TOAST_TUPLE_THRESHOLD, it'll uselessly recurse back to
tuptoaster.c, wasting cycles. (It turns out that this does not happen on
8-byte-MAXALIGN machines, because for them the outer MAXALIGN in the
TOAST_MAX_CHUNK_SIZE macro reduces TOAST_MAX_CHUNK_SIZE so that toast tuples
will be less than TOAST_TUPLE_THRESHOLD in size. That MAXALIGN is really
incorrect, but we can't remove it now, see below.) There isn't any particular
value in maxaligning before comparing to the thresholds, so just don't do
that, which saves a small number of cycles in itself.
These numbers should be rejiggered to minimize wasted space on toast-relation
pages, but we can't do that in the back branches because changing
TOAST_MAX_CHUNK_SIZE would force an initdb (by changing the contents of toast
tables). We can move the toast decision thresholds a bit, though, which is
what this patch effectively does.
Thanks to Pavan Deolasee for discovering the unintended recursion.
Back-patch into 8.2, but not further, pending more testing. (HEAD is about
to get a further patch modifying the thresholds, so it won't help much
for testing this form of the patch.)
Bruce Momjian [Sat, 3 Feb 2007 23:52:19 +0000 (23:52 +0000)]
Add URLs for:
* Allow sequential scans to take advantage of other concurrent
sequential scans, also called "Synchronised Scanning"
> http://archives.postgresql.org/pgsql-patches/2006-12/msg00076.php
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00408.php
Bruce Momjian [Sat, 3 Feb 2007 22:32:49 +0000 (22:32 +0000)]
Add:
> o Allow recovery.conf to allow the same syntax as
> postgresql.conf, including quoting
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php
Bruce Momjian [Fri, 2 Feb 2007 23:05:36 +0000 (23:05 +0000)]
Add URL for:
* Allow sequential scans to take advantage of other concurrent
sequential scans, also called "Synchronised Scanning"
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00784.php
Bruce Momjian [Fri, 2 Feb 2007 22:55:08 +0000 (22:55 +0000)]
Add:
> * Reduce checkpoint performance degredation by forcing data to disk
> more evenly
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00079.php
Neil Conway [Fri, 2 Feb 2007 16:25:34 +0000 (16:25 +0000)]
This patch changes the installscript for vcbuild to actually parse the
generated solution files for what to install, instead of blindly copying
everything as it previously did. With the previous quick-n-dirty
version, it would copy old DLLs if you reconfigured in a way that didn't
include subprojects like a PL for example.
Bruce Momjian [Fri, 2 Feb 2007 05:42:56 +0000 (05:42 +0000)]
Add:
> o Allow column display reordering by recording a display,
> storage, and permanent id for every column?
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
>
Tom Lane [Fri, 2 Feb 2007 00:07:03 +0000 (00:07 +0000)]
Repair failure to check that a table is still compatible with a previously
made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached
query plans: they could contain Vars that claim a column has a different
type than it now has. Fix this by checking during plan startup that Vars
at relation scan level match the current relation tuple descriptor. Since
at that point we already have at least AccessShareLock, we can be sure the
column type will not change underneath us later in the query. However,
since a backend's locks do not conflict against itself, there is still a
hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
while a query is in progress in the current backend. Seal that hole by
rejecting ALTER TABLE whenever the target relation is already open in
the current backend.
This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see. Our thanks to Jeff Trout for the initial report.
Tom Lane [Fri, 2 Feb 2007 00:02:55 +0000 (00:02 +0000)]
Repair insufficiently careful type checking for SQL-language functions:
we should check that the function code returns the claimed result datatype
every time we parse the function for execution. Formerly, for simple
scalar result types we assumed the creation-time check was sufficient, but
this fails if the function selects from a table that's been redefined since
then, and even more obviously fails if check_function_bodies had been OFF.
This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see. Our thanks to Jeff Trout for the initial report.
Neil Conway [Thu, 1 Feb 2007 20:11:18 +0000 (20:11 +0000)]
Update some of the "expected" regression test results for Bruce's
recent may/might cleanup, in the hopes that this will unbreak the
buildfarm. Per report from Stefan Kaltenbrunner.
Tom Lane [Thu, 1 Feb 2007 19:22:07 +0000 (19:22 +0000)]
Fix plpgsql so that when a local variable has no initial-value expression,
an error will be thrown correctly if the variable is of a NOT NULL domain.
Report and almost-correct fix from Sergiy Vyshnevetskiy (bug #2948).
Bruce Momjian [Thu, 1 Feb 2007 19:10:30 +0000 (19:10 +0000)]
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Neil Conway [Thu, 1 Feb 2007 04:39:33 +0000 (04:39 +0000)]
This patch adds documentation for the long-version parameters --username
and --password for pg_dump, pg_dumpall and pg_restore, per complaint by
Michael Schmidt. Patch from Magnus Hagander.
Bruce Momjian [Thu, 1 Feb 2007 04:35:52 +0000 (04:35 +0000)]
Add:
>
> * Fix problem when multiple subtransactions of the same outer transaction
> hold different types of locks, and one subtransaction aborts
>
> http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php
Bruce Momjian [Thu, 1 Feb 2007 00:34:03 +0000 (00:34 +0000)]
Update CREATE SEQUENCE documentation to show the same sequence being
created and increments. The old docs created the sequence, then showed
a nextval() of 114.
Bruce Momjian [Wed, 31 Jan 2007 23:26:05 +0000 (23:26 +0000)]
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Bruce Momjian [Wed, 31 Jan 2007 20:56:20 +0000 (20:56 +0000)]
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
Neil Conway [Wed, 31 Jan 2007 19:33:54 +0000 (19:33 +0000)]
Rewrite uuid input and output routines to avoid dependency on the
nonportable "hh" sprintf(3) length modifier. Instead, do the parsing
and output by hand. The code to do this isn't ideal, but this is
an interim measure anyway: the uuid type should probably use the
in-memory struct layout specified by RFC 4122. For now, this patch
should hopefully rectify the buildfarm failures for the uuid test.
Along the way, re-add pg_cast entries for uuid <-> varchar, which
I mistakenly removed earlier, and bump the catversion.
Tom Lane [Wed, 31 Jan 2007 18:52:49 +0000 (18:52 +0000)]
Fix initdb to not generate misleading error messages when postgres.bki
or other share-directory files are inaccessible for some reason other
than not existing. Inspired by trouble report from Simon Kinsella.
Teodor Sigaev [Wed, 31 Jan 2007 15:09:45 +0000 (15:09 +0000)]
Allow GIN's extractQuery method to signal that nothing can satisfy the query.
In this case extractQuery should returns -1 as nentries. This changes
prototype of extractQuery method to use int32* instead of uint32* for
nentries argument.
Based on that gincostestimate may see two corner cases: nothing will be found
or seqscan should be used.
Per proposal at http://archives.postgresql.org/pgsql-hackers/2007-01/msg01581.php
PS tsearch_core patch should be sightly modified to support changes, but I'm
waiting a verdict about reviewing of tsearch_core patch.
Bruce Momjian [Wed, 31 Jan 2007 03:17:49 +0000 (03:17 +0000)]
Add:
>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
> This is difficult because you must upgrade to an exclusive table lock
> to replace the existing index file. CREATE INDEX CONCURRENTLY does not
> have this complication. This would allow index compaction without
> downtime.
Bruce Momjian [Tue, 30 Jan 2007 22:29:23 +0000 (22:29 +0000)]
Update documentation for backslashes to mention escape string syntax
more, and standard_conforming_strings less, because in the future non-E
strings will not treat backslashes specially.
Also use E'' strings where backslashes are used in examples. (The
existing examples would have drawn warnings.)
Tom Lane [Tue, 30 Jan 2007 22:05:13 +0000 (22:05 +0000)]
Repair oversights in the mechanism used to store compiled plpgsql functions.
The original coding failed (tried to access deallocated memory) if there were
two active call sites (fn_extra pointers) for the same function and the
function definition was updated. Also, if an update of a recursive function
was detected upon nested entry to the function, the existing compiled version
was summarily deallocated, resulting in crash upon return to the outer
instance. Problem observed while studying a bug report from Sergiy
Vyshnevetskiy.
Bug does not exist before 8.1 since older versions just leaked the memory of
obsoleted compiled functions, rather than trying to reclaim it.
Tom Lane [Tue, 30 Jan 2007 18:02:22 +0000 (18:02 +0000)]
Add SPI_push/SPI_pop calls so that datatype input and output functions called
by plpgsql can themselves use SPI --- possibly indirectly, as in the case
of domain_in() invoking plpgsql functions in a domain check constraint.
Per bug #2945 from Sergiy Vyshnevetskiy.
Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given
the lack of prior complaints, it doesn't seem critical for 7.x.
Tom Lane [Tue, 30 Jan 2007 01:33:36 +0000 (01:33 +0000)]
Add support for cross-type hashing in hash index searches and hash joins.
Hashing for aggregation purposes still needs work, so it's not time to
mark any cross-type operators as hashable for general use, but these cases
work if the operators are so marked by hand in the system catalogs.
Tom Lane [Sun, 28 Jan 2007 23:21:26 +0000 (23:21 +0000)]
Improve hash join to discard input tuples immediately if they can't
match because they contain a null join key (and the join operator is
known strict). Improves performance significantly when the inner
relation contains a lot of nulls, as per bug #2930.