Teodor Sigaev [Fri, 17 Oct 2008 17:32:59 +0000 (17:32 +0000)]
Fix small bug in headline generation.
Patch from Sushant Sinha <sushant354@gmail.com>
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php
Teodor Sigaev [Fri, 17 Oct 2008 17:02:42 +0000 (17:02 +0000)]
During repeated rescan of GiST index it's possible that scan key
is NULL but SK_SEARCHNULL is not set. Add checking IS NULL of keys
to set during key initialization. If key is NULL and SK_SEARCHNULL is not
set then nothnig can be satisfied.
With assert-enabled compilation that causes coredump.
Bug was introduced in 8.3 by support of IS NULL index scan.
Neil Conway [Thu, 16 Oct 2008 19:25:58 +0000 (19:25 +0000)]
Fix a small memory leak in ExecReScanAgg() in the hashed aggregation case.
In the previous coding, the list of columns that needed to be hashed on
was allocated in the per-query context, but we reallocated every time
the Agg node was rescanned. Since this information doesn't change over
a rescan, just construct the list of columns once during ExecInitAgg().
Tom Lane [Thu, 16 Oct 2008 13:23:28 +0000 (13:23 +0000)]
Fix SPI_getvalue and SPI_getbinval to range-check the given attribute number
according to the TupleDesc's natts, not the number of physical columns in the
tuple. The previous coding would do the wrong thing in cases where natts is
different from the tuple's column count: either incorrectly report error when
it should just treat the column as null, or actually crash due to indexing off
the end of the TupleDesc's attribute array. (The second case is probably not
possible in modern PG versions, due to more careful handling of inheritance
cases than we once had. But it's still a clear lack of robustness here.)
The incorrect error indication is ignored by all callers within the core PG
distribution, so this bug has no symptoms visible within the core code, but
it might well be an issue for add-on packages. So patch all the way back.
Tom Lane [Fri, 10 Oct 2008 13:48:12 +0000 (13:48 +0000)]
Fix omission of DiscardStmt in GetCommandLogLevel, per report from Hubert
Depesz Lubaczewski. In HEAD, also move a couple of other cases to make the
code ordering match up with ProcessUtility.
Tom Lane [Thu, 9 Oct 2008 16:35:13 +0000 (16:35 +0000)]
Fix overly tense optimization of PLpgSQL_func_hashkey: we must represent
the isTrigger state explicitly, not rely on nonzero-ness of trigrelOid
to indicate trigger-hood, because trigrelOid will be left zero when compiling
for validation. The (useless) function hash entry built by the validator
was able to match an ordinary non-trigger call later in the same session,
thereby bypassing the check that is supposed to prevent such a call.
Per report from Alvaro.
It might be worth suppressing the useless hash entry altogether, but
that's a bigger change than I want to consider back-patching.
Back-patch to 8.0. 7.4 doesn't have the problem because it doesn't
have validation mode.
Tom Lane [Thu, 9 Oct 2008 15:49:10 +0000 (15:49 +0000)]
Fix crash in bytea-to-XML mapping when the source value is toasted.
Report and fix by Michael McMaster. Some minor code beautification by me,
also avoid memory leaks in the special-case paths.
Force a checkpoint in CREATE DATABASE before starting to copy the files,
to process any pending unlinks for the source database.
Before, if you dropped a relation in the template database just before
CREATE DATABASE, and a checkpoint happened during copydir(), the checkpoint
might delete a file that we're just about to copy, causing lstat() in
copydir() to fail with ENOENT.
Backpatch to 8.3, where the pending unlinks were introduced.
Per report by Matthew Wakeling and analysis by Tom Lane.
When a relation is moved to another tablespace, we can't assume that we can
use the old relfilenode in the new tablespace. There might be another relation
in the new tablespace with the same relfilenode, so we must generate a fresh
relfilenode in the new tablespace.
The 8.3 patch to let deleted relation files linger as zero-length files until
the next checkpoint made this more obvious: moving a relation from one table
space another, and then back again, caused a collision with the lingering
file.
Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem
worth fixing there, because we didn't have protection from OID collisions
after OID wraparound before 8.1.
Tom Lane [Tue, 30 Sep 2008 13:14:07 +0000 (13:14 +0000)]
Recent patches to pg_ctl broke "pg_ctl restart" for the case where no
command-line options had been given to the postmaster; and just plain
broke it altogether in 8.1 and 8.0. Per report from KaiGai Kohei.
Tom Lane [Wed, 24 Sep 2008 16:52:53 +0000 (16:52 +0000)]
Fix more problems with rewriter failing to set Query.hasSubLinks when inserting
a SubLink expression into a rule query. We missed cases where the original
query contained a sub-SELECT in a function in FROM, a multi-row VALUES list,
or a RETURNING list. Per bug #4434 from Dean Rasheed and subsequent
investigation.
Back-patch to 8.1; older releases don't have the issue because they didn't
try to be smart about setting hasSubLinks only when needed.
Tom Lane [Wed, 17 Sep 2008 14:18:46 +0000 (14:18 +0000)]
Update time zone data files to tzdata release 2008f (DST law changes in
Argentina, Bahamas, Brazil, Mauritius, Morocco, Pakistan, Palestine, Paraguay).
Tom Lane [Tue, 16 Sep 2008 01:56:35 +0000 (01:56 +0000)]
Widen the nLocks counts in local lock tables from int to int64. This
forestalls potential overflow when the same table (or other object, but
usually tables) is accessed by very many successive queries within a single
transaction. Per report from Michael Milligan.
Back-patch to 8.0, which is as far back as the patch conveniently applies.
There have been no reports of overflow in pre-8.3 releases, but clearly the
risk existed all along. (Michael's report suggests that 8.3 may consume lock
counts faster than prior releases, but with no test case to look at it's hard
to be sure about that. Widening the counts seems a good future-proofing
measure in any event.)
Tom Lane [Mon, 15 Sep 2008 23:37:49 +0000 (23:37 +0000)]
Fix caching of foreign-key-checking queries so that when a replan is needed,
we regenerate the SQL query text not merely the plan derived from it. This
is needed to handle contingencies such as renaming of a table or column
used in an FK. Pre-8.3, such cases worked despite the lack of replanning
(because the cached plan needn't actually change), so this is a regression.
Per bug #4417 from Benjamin Bihler.
Tom Lane [Fri, 12 Sep 2008 14:56:19 +0000 (14:56 +0000)]
Skip opfamily check in eclass_matches_any_index() when the index isn't a
btree. We can't easily tell whether clauses generated from the equivalence
class could be used with such an index, so just assume that they might be.
This bit of over-optimization prevented use of non-btree indexes for nestloop
inner indexscans, in any case where the join uses an equality operator that
is also a btree operator --- which in particular is typically true for hash
indexes. Noted while trying to test the current hash index patch.
Initialize the minimum frozen Xid in vac_update_datfrozenxid using
GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not
depend on the latter being correctly set elsewhere, and while it is more
expensive, this code path is not performance-critical. This is a real
risk for autovacuum, because it can execute whole cycles without doing
a single vacuum, which would mean that RecentGlobalXmin would stay at its
initialization value, FirstNormalTransactionId, causing a bogus value to be
inserted in pg_database. This bug could explain some recent reports of
failure to truncate pg_clog.
At the same time, change the initialization of RecentGlobalXmin to
InvalidTransactionId, and ensure that it's set to something else whenever
it's going to be used. Using it as FirstNormalTransactionId in HOT page
pruning could incur in data loss. InitPostgres takes care of setting it
to a valid value, but the extra checks are there to prevent "special"
backends from behaving in unusual ways.
Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us
Tom Lane [Wed, 10 Sep 2008 17:01:17 +0000 (17:01 +0000)]
Avoid using sprintf() for a simple octal conversion in PQescapeByteaInternal.
Improves performance, per suggestion from Rudolf Leitgeb (bug #4414).
The backend did this right already, but not libpq.
Tom Lane [Mon, 1 Sep 2008 22:30:40 +0000 (22:30 +0000)]
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value()
whenever possible, as per bug report from Oleg Serov. While at it, reorder
the operations in the RECORD case to avoid possible palloc failure while the
variable update is only partly complete.
Back-patch as far as 8.1. Although the code of the particular function is
similar in 8.0, 8.0's support for composite fields in rows is sufficiently
broken elsewhere that it doesn't seem worth fixing this.
HeapTupleHeaderAdjustCmax made the incorrect assumption that the raw
command id is the cmin, when it can in fact be a combo cid. That made rows
incorrectly invisible to a transaction where a tuple was deleted by multiple
aborted subtransactions.
Report and patch Karl Schnaitter. Back-patch to 8.3, where combo cids was
introduced.
Tom Lane [Fri, 29 Aug 2008 17:27:50 +0000 (17:27 +0000)]
Fix bug in original implementation of xmlserialize(): if user specifies
a target type that isn't acceptable, the code failed to raise the proper
error. The result instead was to return a NULL expression tree, which
in a quick test led to a 'cache lookup failed for type 0' error later.
Patch 8.3 only --- I fixed this in HEAD as part of recent locations patch.
Tom Lane [Tue, 26 Aug 2008 02:16:39 +0000 (02:16 +0000)]
Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant
when its input is constant and the element coercion function is immutable
(or nonexistent, ie, binary-coercible case). This is an oversight in the
8.3 implementation of ArrayCoerceExpr, and its result is that certain cases
involving IN or NOT IN with constants don't get optimized as they should be.
Per experimentation with an example from Ow Mun Heng.
Magnus Hagander [Wed, 20 Aug 2008 11:53:51 +0000 (11:53 +0000)]
Make libpq on windows not try to send chunks larger than 64Kb.
Per Microsoft knowledge base article Q201213, early versions of
Windows fail when we do this. Later versions of Windows appear
to have a higher limit than 64Kb, but do still fail on large
sends, so we unconditionally limit it for all versions.
Tom Lane [Sat, 16 Aug 2008 02:25:11 +0000 (02:25 +0000)]
Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexec
returns NULL instead of a PGresult. The former coding would fail, which
is OK, but it neglected to give you the PQerrorMessage that might tell
you why. In the oldest branches, there was another problem: it'd sometimes
report PQerrorMessage from the wrong connection.
Fix pull_up_simple_union_all to copy all rtable entries from child subquery to
parent, not only those with RangeTblRefs. We need them in ExecCheckRTPerms.
Report by Brendan O'Shea. Back-patch to 8.2, where pull_up_simple_union_all
was introduced.
Tom Lane [Sun, 10 Aug 2008 19:02:46 +0000 (19:02 +0000)]
Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class (or a
REINDEX DATABASE including same) is done before a session has done any other
update on pg_class, the pg_class relcache entry was left with an incorrect
setting of rd_indexattr, because the indexed-attributes set would be first
demanded at a time when we'd forced a partial list of indexes into the
pg_class entry, and it would remain cached after that. This could result
in incorrect decisions about HOT-update safety later in the same session.
In practice, since only pg_class_relname_nsp_index would be missed out,
only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a problem.
Per report and test case from Ondrej Jirman.
Tom Lane [Fri, 8 Aug 2008 17:01:18 +0000 (17:01 +0000)]
Install checks in executor startup to ensure that the tuples produced by an
INSERT or UPDATE will match the target table's current rowtype. In pre-8.3
releases inconsistency can arise with stale cached plans, as reported by
Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb
2007; I'm not sure why we thought there was no risk on the insertion side.)
In 8.3 and HEAD this problem should be impossible due to plan cache
invalidation management, but it seems prudent to make the check anyway.
Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there
seems no way to abuse a stale plan comparably.
Tom Lane [Tue, 5 Aug 2008 21:28:36 +0000 (21:28 +0000)]
Do not allow Unique nodes to be scanned backwards. The code claimed that it
would work, but in fact it didn't return the same rows when moving backwards
as when moving forwards. This would have no visible effect in a DISTINCT
query (at least assuming the column datatypes use a strong definition of
equality), but it gave entirely wrong answers for DISTINCT ON queries.
Tom Lane [Sun, 3 Aug 2008 05:12:45 +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 ...
Magnus Hagander [Tue, 29 Jul 2008 15:17:29 +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 [Fri, 11 Jul 2008 16:08:50 +0000 (16:08 +0000)]
Fix an oversight in the original implementation of performMultipleDeletions():
the alreadyDeleted list has to be passed down through
deleteDependentObjects(), else objects that are deleted via auto/internal
dependencies don't get reported back up to performMultipleDeletions().
Depending on the visitation order, this could cause the code to try to delete
an already-deleted object, leading to strange errors in DROP OWNED (typically
"cache lookup failed for relation NNNNN" or similar). Per bug #4289.
Patch for back branches only. This code has recently been rewritten in HEAD,
and doesn't have this particular bug anymore.
Tom Lane [Thu, 10 Jul 2008 01:17:36 +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 [Tue, 8 Jul 2008 22:17:47 +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:25:06 +0000 (20:25 +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:53 +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:53 +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:20 +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.
Tom Lane [Tue, 1 Jul 2008 03:41:01 +0000 (03:41 +0000)]
Fix identify_system_timezone() so that it tests the behavior of the system
timezone setting in the current year and for 100 years back, rather than
always examining years 1904-2004. The original coding would have problems
distinguishing zones whose behavior diverged only after 2004; which is a
situation we will surely face sometime, if it's not out there already.
In passing, also prevent selection of the dummy "Factory" timezone, even
if that's exactly what the system is using. Reporting time as GMT seems
better than that.
Tom Lane [Fri, 27 Jun 2008 20:54:45 +0000 (20:54 +0000)]
Consider a clause to be outerjoin_delayed if it references the nullable side
of any lower outer join, even if it also references the non-nullable side and
so could not get pushed below the outer join anyway. We need this in case
the clause is an OR clause: if it doesn't get marked outerjoin_delayed,
create_or_index_quals() could pull an indexable restriction for the nullable
side out of it, leading to wrong results as demonstrated by today's bug
report from toruvinn. (See added regression test case for an example.)
In principle this has been wrong for quite a while. In practice I don't
think any branch before 8.3 can really show the failure, because
create_or_index_quals() will only pull out indexable conditions, and before
8.3 those were always strict. So though we might have improperly generated
null-extended rows in the outer join, they'd get discarded from the result
anyway. The gating factor that makes the failure visible is that 8.3
considers "col IS NULL" to be indexable. Hence I'm not going to risk
back-patching further than 8.3.
Tom Lane [Wed, 18 Jun 2008 20:55:49 +0000 (20:55 +0000)]
Improve error reporting for problems in text search configuration files
by installing an error context subroutine that will provide the file name
and line number for all errors detected while reading a config file.
Some of the reader routines were already doing that in an ad-hoc way for
errors detected directly in the reader, but it didn't help for problems
detected in subroutines, such as encoding violations.
Back-patch to 8.3 because 8.3 is where people will be trying to debug
configuration files.
Tom Lane [Tue, 17 Jun 2008 14:51:38 +0000 (14:51 +0000)]
Fix the code that adds regclass constants to a plan's list of relation OIDs
that it depends on for replan-forcing purposes. We need to consider plain OID
constants too, because eval_const_expressions folds a RelabelType atop a Const
to just a Const. This change could result in OID values that aren't really
for tables getting added to the dependency list, but the worst-case
consequence would be occasional useless replans. Per report from Gabriele
Messineo.
Tom Lane [Tue, 17 Jun 2008 00:52:49 +0000 (00:52 +0000)]
Clean up a number of bogosities around pltcl's handling of the Tcl "result":
1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult. This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result. (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)
2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.
3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings. This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.
#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(
Tom Lane [Fri, 13 Jun 2008 02:59:52 +0000 (02:59 +0000)]
Improve the various elog messages in tuptoaster.c to report which TOAST table
the problem happened in. These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.
Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back. Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.
Fix bug in the WAL recovery code to finish an incomplete split.
CacheInvalidateRelcache() crashes if called in WAL recovery, because the
invalidation infrastructure hasn't been initialized yet.
Tom Lane [Mon, 9 Jun 2008 19:34:09 +0000 (19:34 +0000)]
Fix datetime input functions to correctly detect integer overflow when
running on a 64-bit platform ... strtol() will happily return 64-bit
output in that case. Per bug #4231 from Geoff Tolley.
Tom Lane [Sun, 8 Jun 2008 21:09:52 +0000 (21:09 +0000)]
ALTER AGGREGATE OWNER seems to have been missed by the last couple of
patches that dealt with object ownership. It wasn't updating pg_shdepend
nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently
by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't
factored that way, so just copy and paste.
Tom Lane [Fri, 6 Jun 2008 17:59:37 +0000 (17:59 +0000)]
Fix pg_get_ruledef() so that negative numeric constants are parenthesized.
This is needed because :: casting binds more tightly than minus, so for
example -1::integer is not the same as (-1)::integer, and there are cases
where the difference is important. In particular this caused a failure
in SELECT DISTINCT ... ORDER BY ... where expressions that should have
matched were seen as different by the parser; but I suspect that there
could be other cases where failure to parenthesize leads to subtler
semantic differences in reloaded rules. Per report from Alexandr Popov.
Tom Lane [Mon, 2 Jun 2008 03:48:07 +0000 (03:48 +0000)]
Fix initdb to reject a relative path for -X (--xlogdir) argument. This
doesn't work, and the real reason why not is it's unclear where the path
is relative to (initdb's CWD, or the data directory?). We could make an
arbitrary decision, but it seems best to make the user be unambiguous.
Per gripe from Devrim.
Tom Lane [Thu, 29 May 2008 19:34:44 +0000 (19:34 +0000)]
Make 8.3.x psql print tab characters as an appropriate number of spaces,
rather than "\x09". Before 8.3 we just printed tabs as-is, leading to poor
formatting of subsequent columns, but consensus is that "\x09" is not an
improvement over that. Back-patch of fix that's already in HEAD.
Tom Lane [Thu, 29 May 2008 18:46:46 +0000 (18:46 +0000)]
Fix some bugs introduced by the 8.2-era conversion of cube functions to V1
calling convention. cube_inter and cube_distance could attempt to pfree
their input arguments, and cube_dim returned a value from a struct it
might have just pfree'd (which would only really cause a problem in a
debug build, but it's still wrong). Per bug #4208 and additional code
reading.
In HEAD and 8.3, I also made a batch of cosmetic changes to bring these
functions into line with the preferred coding style for V1 functions,
ie declare and fetch all the arguments at the top so readers can easily
see what they are.
Tom Lane [Wed, 28 May 2008 21:58:03 +0000 (21:58 +0000)]
Backpatch Zdenek Kotala's fix to prevent pglz_decompress from stomping on
memory if the compressed data is corrupt.
Backpatch as far as 8.2. The issue exists in older branches too, but given
the lack of field reports, it's not clear it's worth any additional effort
to adapt the patch to the slightly different code in older branches.
Tom Lane [Wed, 28 May 2008 00:45:47 +0000 (00:45 +0000)]
Improve GRANT documentation to point out that UPDATE and DELETE typically
require SELECT privilege as well, since you normally need to read existing
column values within such commands. This behavior is according to spec,
but we'd never documented it before. Per gripe from Volkan Yazici.
Tom Lane [Tue, 27 May 2008 22:18:11 +0000 (22:18 +0000)]
Require bind_textdomain_codeset() not just gettext() to enable NLS support.
GNU gettext before 0.10.36 does not have that function, and is generally too
incomplete to be usable.
Magnus Hagander [Tue, 27 May 2008 12:24:46 +0000 (12:24 +0000)]
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Fixes crash with translated error messages per bugs 4180
and 4196.
Tom Lane [Mon, 26 May 2008 18:54:36 +0000 (18:54 +0000)]
Fix an old corner-case bug in set_config_option: push_old_value has to be
called before, not after, calling the assign_hook if any. This is because
push_old_value might fail (due to palloc out-of-memory), and in that case
there would be no stack entry to tell transaction abort to undo the GUC
assignment. Of course the actual assignment to the GUC variable hasn't
happened yet --- but the assign_hook might have altered subsidiary state.
Without a stack entry we won't call it again to make it undo such actions.
So this is necessary to make the world safe for assign_hooks with side
effects. Per a discussion a couple weeks ago with Magnus.
Back-patch to 8.0. 7.x did not have the problem because it did not have
allocatable stacks of GUC values.
Tom Lane [Sun, 25 May 2008 21:51:11 +0000 (21:51 +0000)]
Adjust timestamp regression tests to prevent two low-probability failure
cases. Recent buildfarm experience shows that it is sometimes possible
to execute several SQL commands in less time than the granularity of
Windows' not-very-high-resolution gettimeofday(), leading to a failure
because the tests expect the value of now() to change and it doesn't.
Also, it was recognized some time ago that the same area of the tests
could fail if local midnight passes between the insertion and the checking
of the values for 'yesterday', 'tomorrow', etc. Clean all this up per
ideas from myself and Greg Stark.
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.