Stamp 9.0.9.
commit : 3b849dbf41357aa9cf209b194d6b7ac5c3c07113
author : Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:43:20 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:43:20 -0400
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.1.5, 9.0.9, 8.4.13, 8.3.20.
commit : 99f093b0f869930417756b0a35a06d20c7ffa91d
author : Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:24:19 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:24:19 -0400
M doc/src/sgml/release-8.3.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
Prevent access to external files/URLs via contrib/xml2's xslt_process().
commit : ac7e13d6fc6fa211f2e4582a959ead762d15c997
author : Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:28:48 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:28:48 -0400
libxslt offers the ability to read and write both files and URLs through
stylesheet commands, thus allowing unprivileged database users to both read
and write data with the privileges of the database server. Disable that
through proper use of libxslt's security options.
Also, remove xslt_process()'s ability to fetch documents and stylesheets
from external files/URLs. While this was a documented "feature", it was
long regarded as a terrible idea. The fix for CVE-2012-3489 broke that
capability, and rather than expend effort on trying to fix it, we're just
going to summarily remove it.
While the ability to write as well as read makes this security hole
considerably worse than CVE-2012-3489, the problem is mitigated by the fact
that xslt_process() is not available unless contrib/xml2 is installed,
and the longstanding warnings about security risks from that should have
discouraged prudent DBAs from installing it in security-exposed databases.
Reported and fixed by Peter Eisentraut.
Security: CVE-2012-3488
M contrib/xml2/expected/xml2.out
M contrib/xml2/expected/xml2_1.out
M contrib/xml2/sql/xml2.sql
M contrib/xml2/xslt_proc.c
M doc/src/sgml/xml2.sgml
Prevent access to external files/URLs via XML entity references.
commit : 24cc5f8745bb5c161d2b52969b9cb77a23124d1d
author : Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:25:50 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 18:25:50 -0400
xml_parse() would attempt to fetch external files or URLs as needed to
resolve DTD and entity references in an XML value, thus allowing
unprivileged database users to attempt to fetch data with the privileges
of the database server. While the external data wouldn't get returned
directly to the user, portions of it could be exposed in error messages
if the data didn't parse as valid XML; and in any case the mere ability
to check existence of a file might be useful to an attacker.
The ideal solution to this would still allow fetching of references that
are listed in the host system's XML catalogs, so that documents can be
validated according to installed DTDs. However, doing that with the
available libxml2 APIs appears complex and error-prone, so we're not going
to risk it in a security patch that necessarily hasn't gotten wide review.
So this patch merely shuts off all access, causing any external fetch to
silently expand to an empty string. A future patch may improve this.
In HEAD and 9.2, also suppress warnings about undefined entities, which
would otherwise occur as a result of not loading referenced DTDs. Previous
branches don't show such warnings anyway, due to different error handling
arrangements.
Credit to Noah Misch for first reporting the problem, and for much work
towards a solution, though this simplistic approach was not his preference.
Also thanks to Daniel Veillard for consultation.
Security: CVE-2012-3489
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/sql/xml.sql
Translation updates
commit : 1bfe3d602bfe28b8b4beae814104eaa0ec3063f8
author : Peter Eisentraut <[email protected]>
date : Tue, 14 Aug 2012 16:32:19 -0400
committer: Peter Eisentraut <[email protected]>
date : Tue, 14 Aug 2012 16:32:19 -0400
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/pt_BR.po
M src/backend/po/ru.po
M src/bin/initdb/po/ru.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/pt_BR.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/pt_BR.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po
Update time zone data files to tzdata release 2012e.
commit : 6d7ba7b6b5c9a131fd2d36ae421a12ba0c5e58b5
author : Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 10:54:43 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 Aug 2012 10:54:43 -0400
DST law changes in Morocco; Tokelau has relocated to the other side of
the International Date Line; and apparently Olson had Tokelau's GMT
offset wrong by an hour even before that.
There are also a large number of non-significant changes in this update.
Upstream took the opportunity to remove trailing whitespace, and the
SCCS-style version numbers on the individual files are gone too.
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/factory
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/pacificnew
M src/timezone/data/solar87
M src/timezone/data/solar88
M src/timezone/data/solar89
M src/timezone/data/southamerica
M src/timezone/data/systemv
M src/timezone/data/yearistype.sh
M src/timezone/data/zone.tab
Fix upper limit of superuser_reserved_connections, add limit for wal_senders
commit : 6f0c9bc4b95c295501caa5ca56158afef7f50f30
author : Magnus Hagander <[email protected]>
date : Fri, 10 Aug 2012 14:49:03 +0200
committer: Magnus Hagander <[email protected]>
date : Fri, 10 Aug 2012 14:49:03 +0200
Should be limited to the maximum number of connections excluding
autovacuum workers, not including.
Add similar check for max_wal_senders, which should never be higher than
max_connections.
M doc/src/sgml/config.sgml
M src/backend/postmaster/postmaster.c
fsync backup_label after pg_start_backup()
commit : c0751d323e96fcaaecba289b71970388972ee608
author : Simon Riggs <[email protected]>
date : Tue, 7 Aug 2012 16:22:58 +0100
committer: Simon Riggs <[email protected]>
date : Tue, 7 Aug 2012 16:22:58 +0100
Dave Kerr, backpatched by Simon Riggs
M src/backend/access/transam/xlog.c
Put back plpython_unicode_2.out for SQL_ASCII case.
commit : 8fb54e91b3b5ff2f73039cc1ba9b0c2d9022418e
author : Heikki Linnakangas <[email protected]>
date : Mon, 6 Aug 2012 16:04:18 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 6 Aug 2012 16:04:18 +0300
This alternative expected output file is required when using SQL_ASCII
as the client and server encoding. The python encoding conversion used to
throw an error on that, but it is now accepted and you get the UTF-8
representation of the string. I thought that case was already covered by
the other expected output files, but the buildfarm says otherwise.
This is only required on REL9_2_STABLE. In 9.1, we explicitly set
client_encoding to UTF-8 to avoid this.
A src/pl/plpython/expected/plpython_unicode_2.out
Perform conversion from Python unicode to string/bytes object via UTF-8.
commit : 7fbe5aaaa8bd50e75474f8f671e66ec1b24a42ab
author : Heikki Linnakangas <[email protected]>
date : Mon, 6 Aug 2012 13:02:15 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 6 Aug 2012 13:02:15 +0300
We used to convert the unicode object directly to a string in the server
encoding by calling Python's PyUnicode_AsEncodedString function. In other
words, we used Python's routines to do the encoding. However, that has a
few problems. First of all, it required keeping a mapping table of Python
encoding names and PostgreSQL encodings. But the real killer was that Python
doesn't support EUC_TW and MULE_INTERNAL encodings at all.
Instead, convert the Python unicode object to UTF-8, and use PostgreSQL's
encoding conversion functions to convert from UTF-8 to server encoding. We
were already doing the same in the other direction in PLyUnicode_FromString,
so this is more consistent, too.
Note: This makes SQL_ASCII to behave more leniently. We used to map
SQL_ASCII to Python's 'ascii', which on Python means strict 7-bit ASCII
only, so you got an error if the python string contained anything but pure
ASCII. You no longer get an error; you get the UTF-8 representation of the
string instead.
Backpatch to 9.0, where these conversions were introduced.
Jan Urbański
D src/pl/plpython/expected/plpython_unicode_2.out
D src/pl/plpython/expected/plpython_unicode_3.out
M src/pl/plpython/plpython.c
Fix bugs with parsing signed hh:mm and hh:mm:ss fields in interval input.
commit : bb49e3551b33a016f75095fe7388b25c332996c3
author : Tom Lane <[email protected]>
date : Fri, 3 Aug 2012 17:39:56 -0400
committer: Tom Lane <[email protected]>
date : Fri, 3 Aug 2012 17:39:56 -0400
DecodeInterval() failed to honor the "range" parameter (the special SQL
syntax for indicating which fields appear in the literal string) if the
time was signed. This seems inappropriate, so make it work like the
not-signed case. The inconsistency was introduced in my commit
f867339c0148381eb1d01f93ab5c79f9d10211de, which as noted in its log message
was only really focused on making SQL-compliant literals work per spec.
Including a sign here is not per spec, but if we're going to allow it
then it's reasonable to expect it to work like the not-signed case.
Also, remove bogus setting of tmask, which caused subsequent processing to
think that what had been given was a timezone and not an hh:mm(:ss) field,
thus confusing checks for redundant fields. This seems to be an aboriginal
mistake in Lockhart's commit 2cf1642461536d0d8f3a1cf124ead0eac04eb760.
Add regression test cases to illustrate the changed behaviors.
Back-patch as far as 8.4, where support for spec-compliant interval
literals was added.
Range problem reported and diagnosed by Amit Kapila, tmask problem by me.
M src/backend/utils/adt/datetime.c
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql
Fix WITH attached to a nested set operation (UNION/INTERSECT/EXCEPT).
commit : ae47eb112f2332a8acff0cb33025a471d8d01222
author : Tom Lane <[email protected]>
date : Tue, 31 Jul 2012 17:56:37 -0400
committer: Tom Lane <[email protected]>
date : Tue, 31 Jul 2012 17:56:37 -0400
Parse analysis neglected to cover the case of a WITH clause attached to an
intermediate-level set operation; it only handled WITH at the top level
or WITH attached to a leaf-level SELECT. Per report from Adam Mackler.
In HEAD, I rearranged the order of SelectStmt's fields to put withClause
with the other fields that can appear on non-leaf SelectStmts. In back
branches, leave it alone to avoid a possible ABI break for third-party
code.
Back-patch to 8.4 where WITH support was added.
M src/backend/parser/analyze.c
M src/backend/parser/parse_cte.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Fix syslogger so that log_truncate_on_rotation works in the first rotation.
commit : 706f792fc525258803fc6444af05ce264b26acc8
author : Tom Lane <[email protected]>
date : Tue, 31 Jul 2012 14:37:08 -0400
committer: Tom Lane <[email protected]>
date : Tue, 31 Jul 2012 14:37:08 -0400
In the original coding of the log rotation stuff, we did not bother to make
the truncation logic work for the very first rotation after postmaster
start (or after a syslogger crash and restart). It just always appended
in that case. It did not seem terribly important at the time, but we've
recently had two separate complaints from people who expected it to work
unsurprisingly. (Both users tend to restart the postmaster about as often
as a log rotation is configured to happen, which is maybe not typical use,
but still...) Since the initial log file is opened in the postmaster,
fixing this requires passing down some more state to the syslogger child
process.
It's always been like this, so back-patch to all supported branches.
M src/backend/postmaster/postmaster.c
M src/backend/postmaster/syslogger.c
Now that the diskchecker.pl author has updated the download link on his website, revert the separate link to the download git repository.
commit : 85509b9c646e2598b3d664b4d7afc16ea41ea708
author : Bruce Momjian <[email protected]>
date : Mon, 30 Jul 2012 10:15:55 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 30 Jul 2012 10:15:55 -0400
Backpatch from 9.0 to current.
M doc/src/sgml/wal.sgml
Improve reporting of error situations in find_other_exec().
commit : 73162ee6bedbd49c9c93a9f0f54258fed2356e4f
author : Tom Lane <[email protected]>
date : Fri, 27 Jul 2012 19:31:28 -0400
committer: Tom Lane <[email protected]>
date : Fri, 27 Jul 2012 19:31:28 -0400
This function suppressed any stderr output from the called program, which
is unnecessary in the normal case and unhelpful in error cases. It also
gave a rather opaque message along the lines of "fgets failure: Success"
in case the called program failed to return anything on stdout. Since
we've seen multiple reports of people not understanding what's wrong when
pg_ctl reports this, improve the message.
Back-patch to all active branches.
M src/port/exec.c
Update doc mention of diskchecker.pl to add URL for script; retain URL for description.
commit : 3262b196aa7d878993108aa6bbbfc8636784bb7e
author : Bruce Momjian <[email protected]>
date : Thu, 26 Jul 2012 21:25:25 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 26 Jul 2012 21:25:25 -0400
Patch to 9.0 and later, where script is mentioned.
M doc/src/sgml/wal.sgml
Only allow autovacuum to be auto-canceled by a directly blocked process.
commit : faa2cbe7d11f3246269c86425826d335c2549eaf
author : Tom Lane <[email protected]>
date : Thu, 26 Jul 2012 14:29:42 -0400
committer: Tom Lane <[email protected]>
date : Thu, 26 Jul 2012 14:29:42 -0400
In the original coding of the autovacuum cancel feature, commit
acac68b2bcae818bc8803b8cb8cbb17eee8d5e2b, an autovacuum process was
considered a target for cancellation if it was found to hard-block any
process examined in the deadlock search. This patch tightens the test so
that the autovacuum must directly hard-block the current process. This
should make the behavior more predictable in general, and in particular
it ensures that an autovacuum will not be canceled with less than
deadlock_timeout grace period. In the old coding, it was possible for an
autovacuum to be canceled almost instantly, given unfortunate timing of two
or more other processes' lock attempts.
This also justifies the logging methodology in the recent commit
d7318d43d891bd63e82dcfc27948113ed7b1db80; without this restriction, that
patch isn't providing enough information to see the connection of the
canceling process to the autovacuum. Like that one, patch all the way
back.
M src/backend/storage/lmgr/deadlock.c
Log a better message when canceling autovacuum.
commit : 63791569d8d7c01257e8f85fdbb918d144e54cc6
author : Robert Haas <[email protected]>
date : Thu, 26 Jul 2012 09:16:44 -0400
committer: Robert Haas <[email protected]>
date : Thu, 26 Jul 2012 09:16:44 -0400
The old message was at DEBUG2, so typically it didn't show up in the
log at all. As a result, in most cases where autovacuum was canceled,
the only information that was logged was the table being vacuumed,
with no indication as to what problem caused the cancel. Crank up
the level to LOG and add some more details to assist with debugging.
Back-patch all the way, per discussion on pgsql-hackers.
M src/backend/storage/lmgr/proc.c
Fix longstanding crash-safety bug with newly-created-or-reset sequences.
commit : 2d7045db0fed2be986e2fc3bc0bb0c3f44badd96
author : Tom Lane <[email protected]>
date : Wed, 25 Jul 2012 17:40:53 -0400
committer: Tom Lane <[email protected]>
date : Wed, 25 Jul 2012 17:40:53 -0400
If a crash occurred immediately after the first nextval() call for a serial
column, WAL replay would restore the sequence to a state in which it
appeared that no nextval() had been done, thus allowing the first sequence
value to be returned again by the next nextval() call; as reported in
bug #6748 from Xiangming Mei.
More generally, the problem would occur if an ALTER SEQUENCE was executed
on a freshly created or reset sequence. (The manifestation with serial
columns was introduced in 8.2 when we added an ALTER SEQUENCE OWNED BY step
to serial column creation.) The cause is that sequence creation attempted
to save one WAL entry by writing out a WAL record that made it appear that
the first nextval() had already happened (viz, with is_called = true),
while marking the sequence's in-database state with log_cnt = 1 to show
that the first nextval() need not emit a WAL record. However, ALTER
SEQUENCE would emit a new WAL entry reflecting the actual in-database state
(with is_called = false). Then, nextval would allocate the first sequence
value and set is_called = true, but it would trust the log_cnt value and
not emit any WAL record. A crash at this point would thus restore the
sequence to its post-ALTER state, causing the next nextval() call to return
the first sequence value again.
To fix, get rid of the idea of logging an is_called status different from
reality. This means that the first nextval-driven WAL record will happen
at the first nextval call not the second, but the marginal cost of that is
pretty negligible. In addition, make sure that ALTER SEQUENCE resets
log_cnt to zero in any case where it touches sequence parameters that
affect future nextval results. This will result in some user-visible
changes in the contents of a sequence's log_cnt column, as reflected in the
patch's regression test changes; but no application should be depending on
that anyway, since it was already true that log_cnt changes rather
unpredictably depending on checkpoint timing.
In addition, make some basically-cosmetic improvements to get rid of
sequence.c's undesirable intimacy with page layout details. It was always
really trying to WAL-log the contents of the sequence tuple, so we should
have it do that directly using a HeapTuple's t_data and t_len, rather than
backing into it with some magic assumptions about where the tuple would be
on the sequence's page.
Back-patch to all supported branches.
M src/backend/commands/sequence.c
M src/test/regress/expected/sequence.out
M src/test/regress/expected/sequence_1.out
Fix whole-row Var evaluation to cope with resjunk columns (again).
commit : 0b71d8e855764894c38b30b17810c45368af6ab1
author : Tom Lane <[email protected]>
date : Fri, 20 Jul 2012 13:09:21 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 Jul 2012 13:09:21 -0400
When a whole-row Var is reading the result of a subquery, we need it to
ignore any "resjunk" columns that the subquery might have evaluated for
GROUP BY or ORDER BY purposes. We've hacked this area before, in commit
68e40998d058c1f6662800a648ff1e1ce5d99cba, but that fix only covered
whole-row Vars of named composite types, not those of RECORD type; and it
was mighty klugy anyway, since it just assumed without checking that any
extra columns in the result must be resjunk. A proper fix requires getting
hold of the subquery's targetlist so we can actually see which columns are
resjunk (whereupon we can use a JunkFilter to get rid of them). So bite
the bullet and add some infrastructure to make that possible.
Per report from Andrew Dunstan and additional testing by Merlin Moncure.
Back-patch to all supported branches. In 8.3, also back-patch commit
292176a118da6979e5d368a4baf27f26896c99a5, which for some reason I had
not done at the time, but it's a prerequisite for this change.
M src/backend/executor/execQual.c
M src/backend/executor/execUtils.c
M src/include/nodes/execnodes.h
M src/include/nodes/nodes.h
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Improve coding around the fsync request queue.
commit : 7587286f667079245cd9692a927f74245b662709
author : Tom Lane <[email protected]>
date : Tue, 17 Jul 2012 16:55:56 -0400
committer: Tom Lane <[email protected]>
date : Tue, 17 Jul 2012 16:55:56 -0400
In all branches back to 8.3, this patch fixes a questionable assumption in
CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are
no uninitialized pad bytes in the request queue structs. This would only
cause trouble if (a) there were such pad bytes, which could happen in 8.4
and up if the compiler makes enum ForkNumber narrower than 32 bits, but
otherwise would require not-currently-planned changes in the widths of
other typedefs; and (b) the kernel has not uniformly initialized the
contents of shared memory to zeroes. Still, it seems a tad risky, and we
can easily remove any risk by pre-zeroing the request array for ourselves.
In addition to that, we need to establish a coding rule that struct
RelFileNode can't contain any padding bytes, since such structs are copied
into the request array verbatim. (There are other places that are assuming
this anyway, it turns out.)
In 9.1 and up, the risk was a bit larger because we were also effectively
assuming that struct RelFileNodeBackend contained no pad bytes, and with
fields of different types in there, that would be much easier to break.
However, there is no good reason to ever transmit fsync or delete requests
for temp files to the bgwriter/checkpointer, so we can revert the request
structs to plain RelFileNode, getting rid of the padding risk and saving
some marginal number of bytes and cycles in fsync queue manipulation while
we are at it. The savings might be more than marginal during deletion of
a temp relation, because the old code transmitted an entirely useless but
nonetheless expensive-to-process ForgetRelationFsync request to the
background process, and also had the background process perform the file
deletion even though that can safely be done immediately.
In addition, make some cleanup of nearby comments and small improvements to
the code in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue.
M src/backend/postmaster/bgwriter.c
M src/backend/storage/smgr/md.c
M src/include/storage/relfilenode.h
Prevent corner-case core dump in rfree().
commit : f81d50dc87ae73f2817c67b205fdcf8d266ca3fb
author : Tom Lane <[email protected]>
date : Sun, 15 Jul 2012 13:28:20 -0400
committer: Tom Lane <[email protected]>
date : Sun, 15 Jul 2012 13:28:20 -0400
rfree() failed to cope with the case that pg_regcomp() had initialized the
regex_t struct but then failed to allocate any memory for re->re_guts (ie,
the first malloc call in pg_regcomp() failed). It would try to touch the
guts struct anyway, and thus dump core. This is a sufficiently narrow
corner case that it's not surprising it's never been seen in the field;
but still a bug is a bug, so patch all active branches.
Noted while investigating whether we need to call pg_regfree after a
failure return from pg_regcomp. Other than this bug, it turns out we
don't, so adjust comments appropriately.
M src/backend/regex/regcomp.c
M src/backend/utils/adt/regexp.c
Fix walsender processes to establish a SIGALRM handler.
commit : 2f9907cb83a12ac432fb81c87cfa735e1229a5bb
author : Tom Lane <[email protected]>
date : Thu, 12 Jul 2012 14:30:10 -0400
committer: Tom Lane <[email protected]>
date : Thu, 12 Jul 2012 14:30:10 -0400
Walsenders must have working SIGALRM handling during InitPostgres,
but they set the handler to SIG_IGN so that nothing would happen
if a timeout was reached. This could result in two failure modes:
* If a walsender participated in a deadlock during its authentication
transaction, and was the last to wait in the deadly embrace, the deadlock
would not get cleared automatically. This would require somebody to be
trying to take out AccessExclusiveLock on multiple system catalogs, so
it's not very probable.
* If a client failed to respond to a walsender's authentication challenge,
the intended disconnect after AuthenticationTimeout wouldn't happen, and
the walsender would wait indefinitely for the client.
For the moment, fix in back branches only, since this is fixed in a
different way in the timeout-infrastructure patch that's awaiting
application to HEAD. If we choose not to apply that, then we'll need
to do this in HEAD as well.
M src/backend/replication/walsender.c
Back-patch fix for extraction of fixed prefixes from regular expressions.
commit : dffc6c8a85e934a3633e0ba4c336830c2833e126
author : Tom Lane <[email protected]>
date : Tue, 10 Jul 2012 18:00:47 -0400
committer: Tom Lane <[email protected]>
date : Tue, 10 Jul 2012 18:00:47 -0400
Back-patch of commits 628cbb50ba80c83917b07a7609ddec12cda172d0 and
c6aae3042be5249e672b731ebeb21875b5343010. This has been broken since
7.3, so back-patch to all supported branches.
M src/backend/regex/Makefile
M src/backend/regex/regc_color.c
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/backend/regex/rege_dfa.c
A src/backend/regex/regprefix.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/selfuncs.c
M src/include/regex/regex.h
M src/include/regex/regguts.h
M src/include/utils/builtins.h
Back-patch addition of pg_wchar-to-multibyte conversion functionality.
commit : 647ae3cfe399e723dabea8fb73ab963c133babc8
author : Tom Lane <[email protected]>
date : Tue, 10 Jul 2012 16:52:47 -0400
committer: Tom Lane <[email protected]>
date : Tue, 10 Jul 2012 16:52:47 -0400
Back-patch of commits 72dd6291f216440f6bb61a8733729a37c7e3b2d2,
f6a05fd973a102f7e66c491d3f854864b8d24844, and
60e9c224a197aa37abb1aa3aefa3aad42da61f7f.
This is needed to support fixing the regex prefix extraction bug in
back branches.
M src/backend/utils/mb/mbutils.c
M src/backend/utils/mb/wchar.c
M src/include/mb/pg_wchar.h
Refactor pattern_fixed_prefix() to avoid dealing in incomplete patterns.
commit : 5edd21de419dc3cc6cfbc1a36079443e516c000f
author : Tom Lane <[email protected]>
date : Mon, 9 Jul 2012 23:23:16 -0400
committer: Tom Lane <[email protected]>
date : Mon, 9 Jul 2012 23:23:16 -0400
Previously, pattern_fixed_prefix() was defined to return whatever fixed
prefix it could extract from the pattern, plus the "rest" of the pattern.
That definition was sensible for LIKE patterns, but not so much for
regexes, where reconstituting a valid pattern minus the prefix could be
quite tricky (certainly the existing code wasn't doing that correctly).
Since the only thing that callers ever did with the "rest" of the pattern
was to pass it to like_selectivity() or regex_selectivity(), let's cut out
the middle-man and just have pattern_fixed_prefix's subroutines do this
directly. Then pattern_fixed_prefix can return a simple selectivity
number, and the question of how to cope with partial patterns is removed
from its API specification.
While at it, adjust the API spec so that callers who don't actually care
about the pattern's selectivity (which is a lot of them) can pass NULL for
the selectivity pointer to skip doing the work of computing a selectivity
estimate.
This patch is only an API refactoring that doesn't actually change any
processing, other than allowing a little bit of useless work to be skipped.
However, it's necessary infrastructure for my upcoming fix to regex prefix
extraction, because after that change there won't be any simple way to
identify the "rest" of the regex, not even to the low level of fidelity
needed by regex_selectivity. We can cope with that if regex_fixed_prefix
and regex_selectivity communicate directly, but not if we have to work
within the old API. Hence, back-patch to all active branches.
M src/backend/optimizer/path/indxpath.c
M src/backend/utils/adt/selfuncs.c
M src/include/utils/selfuncs.h
Don't try to trim "../" in join_path_components().
commit : 490cb052491a0c1bb691a5ba84e959128171fe0d
author : Tom Lane <[email protected]>
date : Thu, 5 Jul 2012 17:15:21 -0400
committer: Tom Lane <[email protected]>
date : Thu, 5 Jul 2012 17:15:21 -0400
join_path_components() tried to remove leading ".." components from its
tail argument, but it was not nearly bright enough to do so correctly
unless the head argument was (a) absolute and (b) canonicalized.
Rather than try to fix that logic, let's just get rid of it: there is no
correctness reason to remove "..", and cosmetic concerns can be taken
care of by a subsequent canonicalize_path() call. Per bug #6715 from
Greg Davidson.
Back-patch to all supported branches. It appears that pre-9.2, this
function is only used with absolute paths as head arguments, which is why
we'd not noticed the breakage before. However, third-party code might be
expecting this function to work in more general cases, so it seems wise
to back-patch.
In HEAD and 9.2, also make some minor cosmetic improvements to callers.
M src/port/path.c
Revert part of the previous patch that avoided using PLy_elog().
commit : 13797cb46072403fd1696a1f4eb3a9d7634797a1
author : Heikki Linnakangas <[email protected]>
date : Thu, 5 Jul 2012 23:40:25 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 5 Jul 2012 23:40:25 +0300
That caused the plpython_unicode regression test to fail on SQL_ASCII
encoding, as evidenced by the buildfarm. The reason is that with the patch,
you don't get the detail in the error message that you got before. That
detail is actually very informative, so rather than just adjust the expected
output, let's revert that part of the patch for now to make the buildfarm
green again, and figure out some other way to avoid the recursion of
PLy_elog() that doesn't lose the detail.
M src/pl/plpython/plpython.c
Fix mapping of PostgreSQL encodings to Python encodings.
commit : 2956745fa7488ec810b5752dadca5511011ed0b6
author : Heikki Linnakangas <[email protected]>
date : Thu, 5 Jul 2012 22:16:29 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 5 Jul 2012 22:16:29 +0300
Windows encodings, "win1252" and so forth, are named differently in Python,
like "cp1252". Also, if the PyUnicode_AsEncodedString() function call fails
for some reason, use a plain ereport(), not a PLy_elog(), to report that
error. That avoids recursion and crash, if PLy_elog() tries to call
PLyUnicode_Bytes() again.
This fixes bug reported by Asif Naeem. Backpatch down to 9.0, before that
plpython didn't even try these conversions.
Jan Urbański, with minor comment improvements by me.
M src/pl/plpython/plpython.c
Fix typo
commit : 5b214b4d90608425cc9e6ed870583b3c61c0a39e
author : Magnus Hagander <[email protected]>
date : Wed, 4 Jul 2012 09:06:02 +0200
committer: Magnus Hagander <[email protected]>
date : Wed, 4 Jul 2012 09:06:02 +0200
gabrielle
M doc/src/sgml/wal.sgml
Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars.
commit : afc73284575d102048d850eb0b5fd66e036d3b54
author : Tom Lane <[email protected]>
date : Sat, 30 Jun 2012 16:44:09 -0400
committer: Tom Lane <[email protected]>
date : Sat, 30 Jun 2012 16:44:09 -0400
If a CHECK constraint or index definition contained a whole-row Var (that
is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or
table inheritance produced incorrect results: the copied Var still claimed
to have the rowtype of the source table, rather than the created table.
For the LIKE case, it seems reasonable to just throw error for this
situation, since the point of LIKE is that the new table is not permanently
coupled to the old, so there's no reason to assume its rowtype will stay
compatible. In the inheritance case, we should ideally allow such
constraints, but doing so will require nontrivial refactoring of CREATE
TABLE processing (because we'd need to know the OID of the new table's
rowtype before we adjust inherited CHECK constraints). In view of the lack
of previous complaints, that doesn't seem worth the risk in a back-patched
bug fix, so just make it throw error for the inheritance case as well.
Along the way, replace change_varattnos_of_a_node() with a more robust
function map_variable_attnos(), which is capable of being extended to
handle insertion of ConvertRowtypeExpr whenever we get around to fixing
the inheritance case nicely, and in the meantime it returns a failure
indication to the caller so that a helpful message with some context can be
thrown. Also, this code will do the right thing with subselects (if we
ever allow them in CHECK or indexes), and it range-checks varattnos before
using them to index into the map array.
Per report from Sergey Konoplev. Back-patch to all supported branches.
M src/backend/commands/tablecmds.c
M src/backend/parser/parse_utilcmd.c
M src/backend/rewrite/rewriteManip.c
M src/include/commands/tablecmds.h
M src/include/rewrite/rewriteManip.h
Initialize shared memory copy of ckptXidEpoch correctly when not in recovery.
commit : 580bde7a1022aa93abbfb4db67a754a1da86b49c
author : Heikki Linnakangas <[email protected]>
date : Fri, 29 Jun 2012 19:19:29 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 29 Jun 2012 19:19:29 +0300
This bug was introduced by commit 20d98ab6e4110087d1816cd105a40fcc8ce0a307,
so backpatch this to 9.0-9.2 like that one.
This fixes bug #6710, reported by Tarvi Pillessaar
M src/backend/access/transam/xlog.c
Fix NOTIFY to cope with I/O problems, such as out-of-disk-space.
commit : 38a90526a13670e56f22fba818362255ddaf52c2
author : Tom Lane <[email protected]>
date : Fri, 29 Jun 2012 00:51:49 -0400
committer: Tom Lane <[email protected]>
date : Fri, 29 Jun 2012 00:51:49 -0400
The LISTEN/NOTIFY subsystem got confused if SimpleLruZeroPage failed,
which would typically happen as a result of a write() failure while
attempting to dump a dirty pg_notify page out of memory. Subsequently,
all attempts to send more NOTIFY messages would fail with messages like
"Could not read from file "pg_notify/nnnn" at offset nnnnn: Success".
Only restarting the server would clear this condition. Per reports from
Kevin Grittner and Christoph Berg.
Back-patch to 9.0, where the problem was introduced during the
LISTEN/NOTIFY rewrite.
M src/backend/commands/async.c
Backport fsync queue compaction logic to all supported branches.
commit : 73a3b1d4589eaf3dc7f0a573727a2a6ac5279e6a
author : Robert Haas <[email protected]>
date : Tue, 26 Jun 2012 06:40:58 -0400
committer: Robert Haas <[email protected]>
date : Tue, 26 Jun 2012 06:40:58 -0400
This backports commit 7f242d880b5b5d9642675517466d31373961cf98,
except for the counter in pg_stat_bgwriter. The underlying problem
(namely, that a full fsync request queue causes terrible checkpoint
behavior) continues to be reported in the wild, and this code seems
to be safe and robust enough to risk back-porting the fix.
M src/backend/postmaster/bgwriter.c
M src/backend/storage/smgr/md.c
Fix memory leak in ARRAY(SELECT ...) subqueries.
commit : d8bd584bf4cc6c74178a73ae8924b86ab2bebb44
author : Tom Lane <[email protected]>
date : Thu, 21 Jun 2012 17:26:24 -0400
committer: Tom Lane <[email protected]>
date : Thu, 21 Jun 2012 17:26:24 -0400
Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which
I think can only happen if the sub-select is embedded in a larger,
correlated subquery) would leak memory for the duration of the query,
due to not reclaiming the array generated in the previous execution.
Per bug #6698 from Armando Miraglia. Diagnosis and fix idea by Heikki,
patch itself by me.
This has been like this all along, so back-patch to all supported versions.
M src/backend/executor/nodeSubplan.c
M src/include/nodes/execnodes.h
pg_dump: Fix verbosity level in LO progress messages
commit : 9166ae25bc9067cbf6b439f4a66277578230fd21
author : Alvaro Herrera <[email protected]>
date : Mon, 18 Jun 2012 16:37:49 -0400
committer: Alvaro Herrera <[email protected]>
date : Mon, 18 Jun 2012 16:37:49 -0400
In passing, reword another instance of the same message that was
gratuitously different.
Author: Josh Kupershmidt
after a bug report by Bosco Rama
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_tar.c
Update copyright year in forgotten places
commit : 10a376c7728cca9a2a2785dedaa17377e9d173bb
author : Peter Eisentraut <[email protected]>
date : Tue, 19 Jun 2012 21:35:35 +0300
committer: Peter Eisentraut <[email protected]>
date : Tue, 19 Jun 2012 21:35:35 +0300
found by Stefan Kaltenbrunner
M doc/src/sgml/legal.sgml
M src/interfaces/libpq/libpq.rc.in
Add missing subtitle for compressed archive logs
commit : a0bab308809cf212ebadfaab56c37943f22afed4
author : Magnus Hagander <[email protected]>
date : Sun, 17 Jun 2012 21:20:32 +0800
committer: Magnus Hagander <[email protected]>
date : Sun, 17 Jun 2012 21:20:32 +0800
M doc/src/sgml/backup.sgml
Fix bug in early startup of Hot Standby with subtransactions. When HS startup is deferred because of overflowed subtransactions, ensure that we re-initialize KnownAssignedXids for when both existing and incoming snapshots have non-zero qualifying xids.
commit : 9d091e05464d075a7dc4943ee51ae7e4b1ebf13c
author : Simon Riggs <[email protected]>
date : Fri, 8 Jun 2012 17:36:10 +0100
committer: Simon Riggs <[email protected]>
date : Fri, 8 Jun 2012 17:36:10 +0100
Fixes bug #6661 reported by Valentine Gogichashvili.
Analysis and fix by Andres Freund
M src/backend/storage/ipc/procarray.c
Revert "Wake WALSender to reduce data loss at failover for async commit."
commit : da6bb58ed9da5ba95b7668e7f4b4c9e2d318a62a
author : Tom Lane <[email protected]>
date : Thu, 7 Jun 2012 23:07:03 -0400
committer: Tom Lane <[email protected]>
date : Thu, 7 Jun 2012 23:07:03 -0400
This reverts commit 090e8a984cf1a8a3ef7f6db6dc919f843902d80c.
Since WalSndWakeup does not exist in 9.0, it's clear that this patch
wasn't even compiled in this branch. Perhaps some variant of it is
appropriate in 9.0, but for the moment I'm just going to un-break
the buildfarm.
M src/backend/access/transam/xlog.c
Wake WALSender to reduce data loss at failover for async commit. WALSender now woken up after each background flush by WALwriter, avoiding multi-second replication delay for an all-async commit workload. Replication delay reduced from 7s with default settings to 200ms, allowing significantly reduced data loss at failover.
commit : 090e8a984cf1a8a3ef7f6db6dc919f843902d80c
author : Simon Riggs <[email protected]>
date : Thu, 7 Jun 2012 19:26:03 +0100
committer: Simon Riggs <[email protected]>
date : Thu, 7 Jun 2012 19:26:03 +0100
Andres Freund and Simon Riggs
M src/backend/access/transam/xlog.c
Fix some more bugs in contrib/xml2's xslt_process().
commit : 110ebff20972101236b27c876c14e6df2833b571
author : Tom Lane <[email protected]>
date : Mon, 4 Jun 2012 20:12:59 -0400
committer: Tom Lane <[email protected]>
date : Mon, 4 Jun 2012 20:12:59 -0400
It failed to check for error return from xsltApplyStylesheet(), as reported
by Peter Gagarinov. (So far as I can tell, libxslt provides no convenient
way to get a useful error message in failure cases. There might be some
inconvenient way, but considering that this code is deprecated it's hard to
get enthusiastic about putting lots of work into it. So I just made it say
"failed to apply stylesheet", in line with the existing error checks.)
While looking at the code I also noticed that the string returned by
xsltSaveResultToString was never freed, resulting in a session-lifespan
memory leak.
Back-patch to all supported versions.
M contrib/xml2/xslt_proc.c
Avoid early reuse of btree pages, causing incorrect query results. When we allowed read-only transactions to skip assigning XIDs we introduced the possibility that a fully deleted btree page could be reused. This broke the index link sequence which could then lead to indexscans silently returning fewer rows than would have been correct. The actual incidence of silent errors from this is thought to be very low because of the exact workload required and locking pre-conditions. Fix is to remove pages only if index page opaque->btpo.xact precedes RecentGlobalXmin.
commit : 3406861436e575d21cee07a56058934747bd46af
author : Simon Riggs <[email protected]>
date : Fri, 1 Jun 2012 12:39:54 +0100
committer: Simon Riggs <[email protected]>
date : Fri, 1 Jun 2012 12:39:54 +0100
Noah Misch, reviewed by Simon Riggs
M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtxlog.c