| Age | Commit message (Collapse) | Author |
|---|
|
The description of the initcond value for the built-in avg(float8)
aggregate has been wrong since it was written. Noted by Disc Magnet.
|
|
Time spent executing AFTER triggers is not included in the runtime of the
associated ModifyTable node; in my patch of yesterday I confused queuing of
these triggers with their actual execution. Spotted by Marko Tiikkaja.
|
|
Back-patch to 9.0, since this was changed then.
|
|
format.
Modify PQescapeStringConn() docs to be consisent with other escaping
functions.
Add mention problems with pre-9.0 versions of libpq using not understanding
bytea hex format to the 9.0 release notes.
Backpatch to 9.0 docs.
|
|
Thom Brown
|
|
Previously reported as ERRCODE_ADMIN_SHUTDOWN, this case is now
reported as ERRCODE_DATABASE_DROPPED. No message text change.
Unlikely to happen on most servers, so low impact change to allow
session poolers to correctly handle this situation.
Tatsuo Ishii and Simon Riggs
|
|
Security: CVE-2010-4015
|
|
|
|
The latter is the correct name of the operation to change the data type
of a column.
Noah Misch
|
|
Peter Geoghegan, reviewed by Stephen Frost
|
|
Josh Kupershmidt
|
|
Josh Kupershmidt
|
|
lo_insert.
|
|
|
|
|
|
writes.
|
|
Add a note to user-facing parameters that can be removed completely
(and not just empty) by #ifdef's depending on build configuration.
|
|
|
|
Recent versions of the Linux system header files cause xlogdefs.h to
believe that open_datasync should be the default sync method, whereas
formerly fdatasync was the default on Linux. open_datasync is a bad
choice, first because it doesn't actually outperform fdatasync (in fact
the reverse), and second because we try to use O_DIRECT with it, causing
failures on certain filesystems (e.g., ext4 with data=journal option).
This part of the patch is largely per a proposal from Marti Raudsepp.
More extensive changes are likely to follow in HEAD, but this is as much
change as we want to back-patch.
Also clean up confusing code and incorrect documentation surrounding the
fsync_writethrough option. Those changes shouldn't result in any actual
behavioral change, but I chose to back-patch them anyway to keep the
branches looking similar in this area.
In 9.0 and HEAD, also do some copy-editing on the WAL Reliability
documentation section.
Back-patch to all supported branches, since any of them might get used
on modern Linux versions.
|
|
|
|
|
|
Author: Marti Raudsepp <marti@juffo.org>
|
|
WAL-logged. Make the notice about the lack of WAL-logging more visible by
making it a <caution>. Also remove the false statement from hot standby
caveats section that hash indexes are not used during hot standby.
|
|
the docs to reflect that OFF is now unreserved. Spotted by Tom Lane.
|
|
|
|
recent wal_sync_method doc paragraph to be clearer.
|
|
|
|
be empty. Because of binary migration usage, it might not be empty.
|
|
Error pointed out by Fujii Masao, though not his patch.
|
|
|
|
Brendan Jurd
|
|
The GRANT reference page failed to mention that the USAGE privilege
allows modifying associated user mappings, although this was already
documented on the CREATE/ALTER/DROP USER MAPPING pages.
|
|
|
|
The new formatting matches what we do for COPY.
Per a complaint from Bruce Momjian.
|
|
|
|
In particular, we are now more explicit about the fact that you may need
wal_sync_method=fsync_writethrough for crash-safety on some platforms,
including MaxOS X. There's also now an explicit caution against assuming
that the default setting of wal_sync_method is either crash-safe or best
for performance.
|
|
Actual behaviour did not match documented behaviour and we have agreed
that it should be the docs that change.
Spotted by Bernd Helmle
|
|
Per Tatsuhito Kasahara.
|
|
|
|
There are numerous methods by which a Perl or Tcl function can subvert
the behavior of another such function executed later; for example, by
redefining standard functions or operators called by the target function.
If the target function is SECURITY DEFINER, or is called by such a
function, this means that any ordinary SQL user with Perl or Tcl language
usage rights can do essentially anything with the privileges of the target
function's owner.
To close this security hole, create a separate Perl or Tcl interpreter for
each SQL userid under which plperl or pltcl functions are executed within
a session. However, all plperlu or pltclu functions run within a session
still share a single interpreter, since they all execute at the trust
level of a database superuser anyway.
Note: this change results in a functionality loss when libperl has been
built without the "multiplicity" option: it's no longer possible to call
plperl functions under different userids in one session, since such a
libperl can't support multiple interpreters in one process. However, such
a libperl already failed to support concurrent use of plperl and plperlu,
so it's likely that few people use such versions with Postgres.
Security: CVE-2010-3433
|
|
Erik Rijkers
|
|
8.0.26, and 7.4.30.
|
|
directory.
Per report from Harald Armin Massa.
|
|
Per report from Harald Armin Massa
|
|
title, per suggestion from Ian Barwick.
|
|
Command synopses using <cmdsynopsis> with multiple variants previously used
<sbr> to break lines between variants. The new man page toolchain introduced
in 9.0 makes a mess out of that, and that markup was probably wrong all along,
because <sbr> is supposed to break lines within a synopsis, not between them.
So fix that by using multiple <cmdsynopsis> elements inside <refsynopsisdiv>.
backpatched to 9.0
|
|
|
|
These are just cosmetic and don't seem worth back-patching far.
I put them into 9.0 just because it was trivial to do so.
|
|
|
|
for git. Change other references from cvs to git as well.
|
