Stamp 9.1.11.
commit : c53cbb39f880959d7ca04f43943e787ec5cad830
author : Tom Lane <[email protected]>
date : Mon, 2 Dec 2013 16:02:21 -0500
committer: Tom Lane <[email protected]>
date : Mon, 2 Dec 2013 16:02:21 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Update release notes for 9.3.2, 9.2.6, 9.1.11, 9.0.15, 8.4.19.
commit : 45f0620fc7ef1e331d77cf93cd72464ecaa4a523
author : Tom Lane <[email protected]>
date : Mon, 2 Dec 2013 15:54:05 -0500
committer: Tom Lane <[email protected]>
date : Mon, 2 Dec 2013 15:54:05 -0500
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
Fix incomplete backpatch of pg_multixact truncation changes to <= 9.2
commit : 0176f8bea436e166654fb3e5d2d8a1ff42552f7a
author : Alvaro Herrera <[email protected]>
date : Mon, 2 Dec 2013 13:28:18 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 2 Dec 2013 13:28:18 -0300
The backpatch of a95335b544d9c8377e9dc7a399d8e9a155895f82 to 9.2, 9.1
and 9.0 was incomplete, missing changes to xlog.c, primarily the call
to TrimMultiXact(). Testing presumably didn't show a problem without
these changes because TrimMultiXact() performs defense-in-depth work,
which is not strictly necessary.
It also missed moving StartupMultiXact() which would have been
problematic if a restartpoing happened in exactly the wrong moment,
causing a transient error.
Andres Freund
M src/backend/access/transam/xlog.c
M src/include/access/multixact.h
Translation updates
commit : 559eb85bff80f32a224975e0cad2f2f38e7c3435
author : Peter Eisentraut <[email protected]>
date : Mon, 2 Dec 2013 00:06:28 -0500
committer: Peter Eisentraut <[email protected]>
date : Mon, 2 Dec 2013 00:06:28 -0500
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/bin/initdb/po/cs.po
M src/bin/pg_basebackup/po/cs.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_dump/po/cs.po
M src/bin/pg_resetxlog/po/cs.po
M src/bin/psql/po/cs.po
M src/bin/scripts/po/cs.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/libpq/po/cs.po
M src/pl/plperl/po/cs.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpython/po/cs.po
M src/pl/tcl/po/cs.po
Update time zone data files to tzdata release 2013h.
commit : 99e7d2ad1f130bb8761bd584ab22d93a362f7a01
author : Tom Lane <[email protected]>
date : Sun, 1 Dec 2013 14:11:44 -0500
committer: Tom Lane <[email protected]>
date : Sun, 1 Dec 2013 14:11:44 -0500
DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein,
Morocco, Palestine. New timezone abbreviations WIB, WIT, WITA for
Indonesia.
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
M src/timezone/data/etcetera
M src/timezone/data/europe
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
Back-patch src/timezone/known_abbrevs.txt into all active branches.
commit : 06c04275e5512fc1aa1f6128b5e4455ad5c94637
author : Tom Lane <[email protected]>
date : Sun, 1 Dec 2013 14:09:31 -0500
committer: Tom Lane <[email protected]>
date : Sun, 1 Dec 2013 14:09:31 -0500
Needed so that timezone data update patches can be cherry-picked
into older branches conveniently.
A src/timezone/known_abbrevs.txt
Fix pg_dumpall to work for databases flagged as read-only.
commit : 4bdccd8427718f9c468e5e03286252f37ea771b5
author : Kevin Grittner <[email protected]>
date : Sat, 30 Nov 2013 12:06:48 -0600
committer: Kevin Grittner <[email protected]>
date : Sat, 30 Nov 2013 12:06:48 -0600
pg_dumpall's charter is to be able to recreate a database cluster's
contents in a virgin installation, but it was failing to honor that
contract if the cluster had any ALTER DATABASE SET
default_transaction_read_only settings. By including a SET command
for the connection for each connection opened by pg_dumpall output,
errors are avoided and the source cluster is successfully
recreated.
There was discussion of whether to also set this for the connection
applying pg_dump output, but it was felt that it was both less
appropriate in that context, and far easier to work around.
Backpatch to all supported branches.
M src/bin/pg_dump/pg_dumpall.c
Truncate pg_multixact/'s contents during crash recovery
commit : 9f1e051adefb2f29e757cf426b03db20d3f8a26d
author : Alvaro Herrera <[email protected]>
date : Fri, 29 Nov 2013 11:26:41 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 29 Nov 2013 11:26:41 -0300
Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash
recovery, because there was no guarantee that enough state had been
setup, and because it wasn't deemed to be a good idea to remove data
during crash recovery anyway. Since then, due to Hot-Standby, streaming
replication and PITR, the amount of time a cluster can spend doing crash
recovery has increased significantly, to the point that a cluster may
even never come out of it. This has made not truncating the content of
pg_multixact/ not defensible anymore.
To fix, take care to setup enough state for multixact truncation before
crash recovery starts (easy since checkpoints contain the required
information), and move the current end-of-recovery actions to a new
TrimMultiXact() function, analogous to TrimCLOG().
At some later point, this should probably done similarly to the way
clog.c is doing it, which is to just WAL log truncations, but we can't
do that for the back branches.
Back-patch to 9.0. 8.4 also has the problem, but since there's no hot
standby there, it's much less pressing. In 9.2 and earlier, this patch
is simpler than in newer branches, because multixact access during
recovery isn't required. Add appropriate checks to make sure that's not
happening.
Andres Freund
M src/backend/access/transam/multixact.c
Fix assorted issues in pg_ctl's pgwin32_CommandLine().
commit : 8c72b20e39a2f6e788020f9c6750e2c0a9bbb235
author : Tom Lane <[email protected]>
date : Fri, 29 Nov 2013 18:34:18 -0500
committer: Tom Lane <[email protected]>
date : Fri, 29 Nov 2013 18:34:18 -0500
Ensure that the invocation command for postgres or pg_ctl runservice
double-quotes the executable's pathname; failure to do this leads to
trouble when the path contains spaces.
Also, ensure that the path ends in ".exe" in both cases and uses
backslashes rather than slashes as directory separators. The latter issue
is reported to confuse some third-party tools such as Symantec Backup Exec.
Also, rewrite the function to avoid buffer overrun issues by using a
PQExpBuffer instead of a fixed-size static buffer. Combinations of
very long executable pathnames and very long data directory pathnames
could have caused trouble before, for example.
Back-patch to all active branches, since this code has been like this
for a long while.
Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi
M src/bin/pg_ctl/pg_ctl.c
Don't update relfrozenxid if any pages were skipped.
commit : bf0d21e6172ba049a51016215e31b5d198ca9abf
author : Heikki Linnakangas <[email protected]>
date : Wed, 27 Nov 2013 13:10:16 +0200
committer: Heikki Linnakangas <[email protected]>
date : Wed, 27 Nov 2013 13:10:16 +0200
Vacuum recognizes that it can update relfrozenxid by checking whether it has
processed all pages of a relation. Unfortunately it performed that check
after truncating the dead pages at the end of the relation, and used the new
number of pages to decide whether all pages have been scanned. If the new
number of pages happened to be smaller or equal to the number of pages
scanned, it incorrectly decided that all pages were scanned.
This can lead to relfrozenxid being updated, even though some pages were
skipped that still contain old XIDs. That can lead to data loss due to xid
wraparounds with some rows suddenly missing. This likely has escaped notice
so far because it takes a large number (~2^31) of xids being used to see the
effect, while a full-table vacuum before that would fix the issue.
The incorrect logic was introduced by commit
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4,
like that commit.
Andres Freund, with some modifications by me.
M src/backend/commands/vacuumlazy.c
ECPG: Fix searching for quoted cursor names case-sensitively.
commit : 9a1c6dd43a119b11a1a5114a99deec9d93fd21b7
author : Michael Meskes <[email protected]>
date : Wed, 27 Nov 2013 11:02:13 +0100
committer: Michael Meskes <[email protected]>
date : Wed, 27 Nov 2013 11:02:13 +0100
Patch by Böszörményi Zoltán <[email protected]>
M src/interfaces/ecpg/preproc/ecpg.addons
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/ecpg.trailer
Documentation fix for ecpg.
commit : a1726994bfd72cedc2808191139dea0d7f77f9f8
author : Michael Meskes <[email protected]>
date : Wed, 27 Nov 2013 11:03:59 +0100
committer: Michael Meskes <[email protected]>
date : Wed, 27 Nov 2013 11:03:59 +0100
The latest fixes removed a limitation that was still in the docs, so Zoltan updated the docs, too.
M doc/src/sgml/ecpg.sgml
Fix typo in release note.
commit : 375ed999efef0c551615b0a23763932714e74bf6
author : Fujii Masao <[email protected]>
date : Wed, 27 Nov 2013 13:45:41 +0900
committer: Fujii Masao <[email protected]>
date : Wed, 27 Nov 2013 13:45:41 +0900
Backpatch to 9.1.
Josh Kupershmidt
M doc/src/sgml/release-9.1.sgml
ECPG: Make the preprocessor emit ';' if the variable type for a list of variables is varchar. This fixes this test case:
commit : 5bffd42a3b0b049ea0e44a69c99ce3c3c5418af0
author : Michael Meskes <[email protected]>
date : Tue, 26 Nov 2013 17:12:39 +0100
committer: Michael Meskes <[email protected]>
date : Tue, 26 Nov 2013 17:12:39 +0100
int main(void)
{
exec sql begin declare section;
varchar a[50], b[50];
exec sql end declare section;
return 0;
}
Since varchars are internally turned into custom structs and
the type name is emitted for these variable declarations,
the preprocessed code previously had:
struct varchar_1 { ... } a _,_ struct varchar_2 { ... } b ;
The comma in the generated C file was a syntax error.
There are no regression test changes since it's not exercised.
Patch by Boszormenyi Zoltan <[email protected]>
M src/interfaces/ecpg/preproc/ecpg.trailer
ECPG: Fix offset to NULL/size indicator array.
commit : 20ada26ea210f04a6cd97cef34a4101757eef583
author : Michael Meskes <[email protected]>
date : Tue, 26 Nov 2013 17:16:39 +0100
committer: Michael Meskes <[email protected]>
date : Tue, 26 Nov 2013 17:16:39 +0100
Patch by Boszormenyi Zoltan <[email protected]>
M src/interfaces/ecpg/ecpglib/data.c
Defend against bad trigger definitions in contrib/lo's lo_manage() trigger.
commit : 8bf45ea8ba1d04e3df20a288e58c5f45fc54d1e6
author : Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 22:45:46 -0500
committer: Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 22:45:46 -0500
This function formerly crashed if called as a statement-level trigger,
or if a column-name argument wasn't given.
In passing, add the trigger name to all error messages from the function.
(None of them are expected cases, so this shouldn't pose any compatibility
risk.)
Marc Cousin, reviewed by Sawada Masahiko
M contrib/lo/lo.c
Fix array slicing of int2vector and oidvector values.
commit : 7b63528750a4a69875b75552f136947fa05aa1c9
author : Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 20:04:06 -0500
committer: Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 20:04:06 -0500
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
M src/backend/parser/parse_node.c
M src/backend/parser/parse_target.c
M src/include/catalog/pg_type.h
Ensure _dosmaperr() actually sets errno correctly.
commit : b2502ecef92c598f6d71d80b8a5745d252cfdde5
author : Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 18:24:26 -0500
committer: Tom Lane <[email protected]>
date : Sat, 23 Nov 2013 18:24:26 -0500
If logging is enabled, either ereport() or fprintf() might stomp on errno
internally, causing this function to return the wrong result. That might
only end in a misleading error report, but in any code that's examining
errno to decide what to do next, the consequences could be far graver.
This has been broken since the very first version of this file in 2006
... it's a bit astonishing that we didn't identify this long ago.
Reported by Amit Kapila, though this isn't his proposed fix.
M src/port/win32error.c
Avoid potential buffer overflow crash
commit : e1f7173ea19ad8977311dc72fe50492fae5c078d
author : Peter Eisentraut <[email protected]>
date : Sat, 23 Nov 2013 07:25:37 -0500
committer: Peter Eisentraut <[email protected]>
date : Sat, 23 Nov 2013 07:25:37 -0500
A pointer to a C string was treated as a pointer to a "name" datum and
passed to SPI_execute_plan(). This pointer would then end up being
passed through datumCopy(), which would try to copy the entire 64 bytes
of name data, thus running past the end of the C string. Fix by
converting the string to a proper name structure.
Found by LLVM AddressSanitizer.
M src/backend/utils/adt/ruleutils.c
Flatten join alias Vars before pulling up targetlist items from a subquery.
commit : 92a752151fa9c279595ab6f896534e49a5625920
author : Tom Lane <[email protected]>
date : Fri, 22 Nov 2013 14:37:31 -0500
committer: Tom Lane <[email protected]>
date : Fri, 22 Nov 2013 14:37:31 -0500
pullup_replace_vars()'s decisions about whether a pulled-up replacement
expression needs to be wrapped in a PlaceHolderVar depend on the assumption
that what looks like a Var behaves like a Var. However, if the Var is a
join alias reference, later flattening of join aliases might replace the
Var with something that's not a Var at all, and should have been wrapped.
To fix, do a forcible pass of flatten_join_alias_vars() on the subquery
targetlist before we start to copy items out of it. We'll re-run that
processing on the pulled-up expressions later, but that's harmless.
Per report from Ken Tanzer; the added regression test case is based on his
example. This bug has been there since the PlaceHolderVar mechanism was
invented, but has escaped detection because the circumstances that trigger
it are fairly narrow. You need a flattenable query underneath an outer
join, which contains another flattenable query inside a join of its own,
with a dangerous expression (a constant or something else non-strict)
in that one's targetlist.
Having seen this, I'm wondering if it wouldn't be prudent to do all
alias-variable flattening earlier, perhaps even in the rewriter.
But that would probably not be a back-patchable change.
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/util/var.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix quoting in help messages in uuid-ossp extension scripts.
commit : 673019936866652bfb8ac399fac6bc21fa6810fe
author : Tom Lane <[email protected]>
date : Fri, 22 Nov 2013 12:07:53 -0500
committer: Tom Lane <[email protected]>
date : Fri, 22 Nov 2013 12:07:53 -0500
The command we're telling people to type needs to include double-quoting
around the unfortunately-chosen extension name. Twiddle the textual
quoting so that it looks somewhat sane. Per gripe from roadrunner6.
M contrib/uuid-ossp/uuid-ossp–1.0.sql
M contrib/uuid-ossp/uuid-ossp–unpackaged–1.0.sql
Fix Hot-Standby initialization of clog and subtrans.
commit : fc8e54f399feac91aa6dd489b51d53921d21617b
author : Heikki Linnakangas <[email protected]>
date : Fri, 22 Nov 2013 14:38:59 +0200
committer: Heikki Linnakangas <[email protected]>
date : Fri, 22 Nov 2013 14:38:59 +0200
These bugs can cause data loss on standbys started with hot_standby=on at
the moment they start to accept read only queries, by marking committed
transactions as uncommited. The likelihood of such corruptions is small
unless the primary has a high transaction rate.
5a031a5556ff83b8a9646892715d7fef415b83c3 fixed bugs in HS's startup logic
by maintaining less state until at least STANDBY_SNAPSHOT_PENDING state
was reached, missing the fact that both clog and subtrans are written to
before that. This only failed to fail in common cases because the usage
of ExtendCLOG in procarray.c was superflous since clog extensions are
actually WAL logged.
f44eedc3f0f347a856eea8590730769125964597/I then tried to fix the missing
extensions of pg_subtrans due to the former commit's changes - which are
not WAL logged - by performing the extensions when switching to a state
> STANDBY_INITIALIZED and not performing xid assignments before that -
again missing the fact that ExtendCLOG is unneccessary - but screwed up
twice: Once because latestObservedXid wasn't updated anymore in that
state due to the earlier commit and once by having an off-by-one error in
the loop performing extensions. This means that whenever a
CLOG_XACTS_PER_PAGE (32768 with default settings) boundary was crossed
between the start of the checkpoint recovery started from and the first
xl_running_xact record old transactions commit bits in pg_clog could be
overwritten if they started and committed in that window.
Fix this mess by not performing ExtendCLOG() in HS at all anymore since
it's unneeded and evidently dangerous and by performing subtrans
extensions even before reaching STANDBY_SNAPSHOT_PENDING.
Analysis and patch by Andres Freund. Reported by Christophe Pettus.
Backpatch down to 9.0, like the previous commit that caused this.
M src/backend/access/transam/clog.c
M src/backend/storage/ipc/procarray.c
Fix incorrect loop counts in tidbitmap.c.
commit : e3a02a39268ff14a8f5f15f1bd9fb59869f26436
author : Tom Lane <[email protected]>
date : Fri, 15 Nov 2013 18:34:14 -0500
committer: Tom Lane <[email protected]>
date : Fri, 15 Nov 2013 18:34:14 -0500
A couple of places that should have been iterating over WORDS_PER_CHUNK
words were iterating over WORDS_PER_PAGE words instead. This thinko
accidentally failed to fail, because (at least on common architectures
with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE,
and the extra words being looked at were always zero so nothing happened.
Still, it's a bug waiting to happen if anybody ever fools with the
parameters affecting TIDBitmap sizes, and it's a small waste of cycles
too. So back-patch to all active branches.
Etsuro Fujita
M src/backend/nodes/tidbitmap.c
Clarify CREATE FUNCTION documentation about handling of typmods.
commit : 71ff6c1ebec774790b4d249abc9aeac79ad0becf
author : Tom Lane <[email protected]>
date : Wed, 13 Nov 2013 13:26:33 -0500
committer: Tom Lane <[email protected]>
date : Wed, 13 Nov 2013 13:26:33 -0500
The previous text was a bit misleading, as well as unnecessarily vague
about what information would be discarded. Per gripe from Craig Skinner.
M doc/src/sgml/ref/create_function.sgml
Fix doc links in README file to work with new website layout
commit : 29bbca433e58199836a3c25c8bdfd1717bbad087
author : Magnus Hagander <[email protected]>
date : Tue, 12 Nov 2013 12:53:32 +0100
committer: Magnus Hagander <[email protected]>
date : Tue, 12 Nov 2013 12:53:32 +0100
Per report from Colin 't Hart
M README.git
Fix race condition in GIN posting tree page deletion.
commit : 3527a5f59fc3821ae985bfb625263a26b00d514c
author : Heikki Linnakangas <[email protected]>
date : Fri, 8 Nov 2013 22:21:42 +0200
committer: Heikki Linnakangas <[email protected]>
date : Fri, 8 Nov 2013 22:21:42 +0200
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results, or even something more curious if the page is
reused for a different kind of a page.
To fix, modify the search algorithm to lock the next page before releasing
the previous one, and refrain from deleting pages from the leftmost branch
of the tree.
Add a new Concurrency section to the README, explaining why this works.
There is a lot more one could say about concurrency in GIN, but that's for
another patch.
Backpatch to all supported versions.
M src/backend/access/gin/README
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/ginget.c
M src/backend/access/gin/ginvacuum.c
M src/include/access/gin_private.h
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
commit : af38d140c71c21eda422fedc838525525d155cac
author : Tom Lane <[email protected]>
date : Fri, 8 Nov 2013 11:37:08 -0500
committer: Tom Lane <[email protected]>
date : Fri, 8 Nov 2013 11:37:08 -0500
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due to multiple evaluations of a volatile function, as in a recent
complaint from Etienne Dube. It's been questionable from the very
beginning whether these functions should look into subqueries (as noted in
their comments), and this case seems to provide proof that they should.
Because the new code only descends into SubLinks, not SubPlans or
InitPlans, the change only affects the planner's behavior during
prepjointree processing and not later on --- for example, you can still get
it to use a volatile function in an indexqual if you wrap the function in
(SELECT ...). That's a historical behavior, for sure, but it's reasonable
given that the executor's evaluation rules for subplans don't depend on
whether there are volatile functions inside them. In any case, we need to
constrain the behavioral change as narrowly as we can to make this
reasonable to back-patch.
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Be more robust when strerror() doesn't give a useful result.
commit : 8cfd4c6a17472d74814eb8f8d8995f6b2fd02ef7
author : Tom Lane <[email protected]>
date : Thu, 7 Nov 2013 16:33:28 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Nov 2013 16:33:28 -0500
Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and
8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches.
Buildfarm testing revealed no great portability surprises, and it
seems useful to have this robustness improvement in all branches.
M src/backend/utils/error/elog.c
Fix generation of MergeAppend plans for optimized min/max on expressions.
commit : 6e2c7624806f6cbbbfcc6fa0de0f2c11da6c0e03
author : Tom Lane <[email protected]>
date : Thu, 7 Nov 2013 13:13:47 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Nov 2013 13:13:47 -0500
Before jamming a desired targetlist into a plan node, one really ought to
make sure the plan node can handle projections, and insert a buffering
Result plan node if not. planagg.c forgot to do this, which is a hangover
from the days when it only dealt with IndexScan plan types. MergeAppend
doesn't project though, not to mention that it gets unhappy if you remove
its possibly-resjunk sort columns. The code accidentally failed to fail
for cases in which the min/max argument was a simple Var, because the new
targetlist would be equivalent to the original "flat" tlist anyway.
For any more complex case, it's been broken since 9.1 where we introduced
the ability to optimize min/max using MergeAppend, as reported by Raphael
Bauduin. Fix by duplicating the logic from grouping_planner that decides
whether we need a Result node.
In 9.2 and 9.1, this requires back-porting the tlist_same_exprs() function
introduced in commit 4387cf956b9eb13aad569634e0c4df081d76e2e3, else we'd
uselessly add a Result node in cases that worked before. It's rather
tempting to back-patch that whole commit so that we can avoid extra Result
nodes in mainline cases too; but I'll refrain, since that code hasn't
really seen all that much field testing yet.
M src/backend/optimizer/plan/planagg.c
M src/backend/optimizer/util/tlist.c
M src/include/optimizer/tlist.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Prevent creating window functions with default arguments.
commit : aad87e3f25ad751a3d021c139fd3adbbe1d19fce
author : Tom Lane <[email protected]>
date : Wed, 6 Nov 2013 13:32:26 -0500
committer: Tom Lane <[email protected]>
date : Wed, 6 Nov 2013 13:32:26 -0500
Insertion of default arguments doesn't work for window functions, which is
likely to cause a crash at runtime if the implementation code doesn't check
the number of actual arguments carefully. It doesn't seem worth working
harder than this for pre-9.2 branches.
M doc/src/sgml/syntax.sgml
M src/backend/catalog/pg_proc.c
Improve the error message given for modifying a window with frame clause.
commit : db157fb141df983f6d66209182ef4ac7997588d4
author : Tom Lane <[email protected]>
date : Tue, 5 Nov 2013 21:58:19 -0500
committer: Tom Lane <[email protected]>
date : Tue, 5 Nov 2013 21:58:19 -0500
For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a
window definition that has any explicit framing clause. The error message
we gave for this only made sense if the referencing window definition
itself contains an explicit framing clause, which it might well not.
Moreover, in the context of an OVER clause it's not exactly obvious that
"OVER (windowname)" implies copy-and-modify while "OVER windowname" does
not. This has led to multiple complaints, eg bug #5199 from Iliya
Krapchatov. Change to a hopefully more intelligible error message, and
in the case where we have just "OVER (windowname)", add a HINT suggesting
that omitting the parentheses will fix it. Also improve the related
documentation. Back-patch to all supported branches.
M doc/src/sgml/syntax.sgml
M src/backend/parser/parse_clause.c
Changed test case slightly so it doesn't have an unused typedef.
commit : 4c412ca2e510ecde00e36d226ff933acd6fb477a
author : Michael Meskes <[email protected]>
date : Sun, 3 Nov 2013 15:37:34 +0100
committer: Michael Meskes <[email protected]>
date : Sun, 3 Nov 2013 15:37:34 +0100
M src/interfaces/ecpg/test/expected/preproc-define.c
M src/interfaces/ecpg/test/expected/preproc-define.stderr
M src/interfaces/ecpg/test/preproc/define.pgc
Ensure all files created for a single BufFile have the same resource owner.
commit : 8c0116a4c990a2c29c33a0cfd62ebfe4de3620e6
author : Tom Lane <[email protected]>
date : Fri, 1 Nov 2013 16:10:00 -0400
committer: Tom Lane <[email protected]>
date : Fri, 1 Nov 2013 16:10:00 -0400
Callers expect that they only have to set the right resource owner when
creating a BufFile, not during subsequent operations on it. While we could
insist this be fixed at the caller level, it seems more sensible for the
BufFile to take care of it. Without this, some temp files belonging to
a BufFile can go away too soon, eg at the end of a subtransaction,
leading to errors or crashes.
Reported and fixed by Andres Freund. Back-patch to all active branches.
M src/backend/storage/file/buffile.c
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
commit : 172ba45780716349f9c76766bad751273c240a66
author : Tom Lane <[email protected]>
date : Fri, 1 Nov 2013 12:13:29 -0400
committer: Tom Lane <[email protected]>
date : Fri, 1 Nov 2013 12:13:29 -0400
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
M src/backend/commands/variable.c
M src/backend/utils/adt/datetime.c
M src/include/pgtime.h
M src/test/regress/expected/horology.out
M src/test/regress/sql/horology.sql
M src/timezone/pgtz.c
Prevent using strncpy with src == dest in TupleDescInitEntry.
commit : 4bf70c0394af8827dd0b22eca89be6e9bedb4d76
author : Tom Lane <[email protected]>
date : Mon, 28 Oct 2013 20:49:35 -0400
committer: Tom Lane <[email protected]>
date : Mon, 28 Oct 2013 20:49:35 -0400
The C and POSIX standards state that strncpy's behavior is undefined when
source and destination areas overlap. While it remains dubious whether any
implementations really misbehave when the pointers are exactly equal, some
platforms are now starting to force the issue by complaining when an
undefined call occurs. (In particular OS X 10.9 has been seen to dump core
here, though the exact set of circumstances needed to trigger that remain
elusive. Similar behavior can be expected to be optional on Linux and
other platforms in the near future.) So tweak the code to explicitly do
nothing when nothing need be done.
Back-patch to all active branches. In HEAD, this also lets us get rid of
an exception in valgrind.supp.
Per discussion of a report from Matthias Schmitt.
M src/backend/access/common/tupdesc.c
doc: Remove i18ngurus.com link
commit : e78ed0402b831947a8a1584892753c3892a8dae9
author : Peter Eisentraut <[email protected]>
date : Tue, 2 Jul 2013 20:32:09 -0400
committer: Peter Eisentraut <[email protected]>
date : Tue, 2 Jul 2013 20:32:09 -0400
The web site is dead, and the Wayback Machine shows that it didn't have
much useful content before.
M doc/src/sgml/charset.sgml
docs: correct 9.1 and 9.2 release note mention of timeline switch fix
commit : 38ee3c55a7403d3c33a28a61b63e94590515912b
author : Bruce Momjian <[email protected]>
date : Tue, 15 Oct 2013 10:34:04 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 15 Oct 2013 10:34:04 -0400
Backpatch through 9.1.
KONDO Mitsumasa
M doc/src/sgml/release-9.1.sgml
doc: fix typo in release notes
commit : 6defa661e0f69c0a3fa1526b3536fe3f63005bc4
author : Bruce Momjian <[email protected]>
date : Wed, 9 Oct 2013 08:44:52 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 9 Oct 2013 08:44:52 -0400
Backpatch through 8.4
Per suggestion by Amit Langote
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml