Before removing backup_label and irrevocably changing pg_control file, check
that WAL file containing the checkpoint redo-location can be found. This
avoids making the cluster irrecoverable if the redo location is in an earlie
WAL file than the checkpoint record.
Report, analysis and patch by Jeff Davis, with small changes by me.
Tom Lane [Mon, 25 Oct 2010 17:04:42 +0000 (13:04 -0400)]
Fix inline_set_returning_function() to preserve the invalItems list properly.
This avoids a possible crash when inlining a SRF whose argument list
contains a reference to an inline-able user function. The crash is quite
reproducible with CLOBBER_FREED_MEMORY enabled, but would be less certain
in a production build. Problem introduced in 9.0 by the named-arguments
patch, which requires invoking eval_const_expressions() before we can try
to inline a SRF. Per report from Brendan Jurd.
Make OFF keyword unreserved. It's not hard to imagine wanting to use 'off'
as a variable or column name, and it's not reserved in recent versions of
the SQL spec either. This became particularly annoying in 9.0, before that
PL/pgSQL replaced variable names in queries with parameter markers, so
it was possible to use OFF and many other backend parser keywords as
variable names. Because of that, backpatch to 9.0.
Tom Lane [Wed, 20 Oct 2010 16:48:57 +0000 (12:48 -0400)]
Don't try to fetch database name when SetTransactionIdLimit() is executed
outside a transaction.
This repairs brain fade in my patch of 2009-08-30: the reason we had been
storing oldest-database name, not OID, in ShmemVariableCache was of course
to avoid having to do a catalog lookup at times when it might be unsafe.
This error explains why Aleksandr Dushein is having trouble getting out of
an XID wraparound state in bug #5718, though not how he got into that state
in the first place. I suspect pg_upgrade is at fault there.
Tom Lane [Wed, 20 Oct 2010 04:55:03 +0000 (00:55 -0400)]
Fix ecpg test building process to not generate *.dSYM junk on Macs.
The trick is to not try to build executables directly from .c files,
but to always build the intermediate .o files. For obscure reasons,
Darwin's version of gcc will leave debug cruft behind in the first
case but not the second. Per complaint from Robert Haas.
Tom Lane [Tue, 19 Oct 2010 19:08:47 +0000 (15:08 -0400)]
Fix incorrect generation of whole-row variables in planner.
A couple of places in the planner need to generate whole-row Vars, and were
cutting corners by setting vartype = RECORDOID in the Vars, even in cases
where there's an identifiable named composite type for the RTE being
referenced. While we mostly got away with this, it failed when there was
also a parser-generated whole-row reference to the same RTE, because the
two Vars weren't equal() due to the difference in vartype. Fix by
providing a subroutine the planner can call to generate whole-row Vars
the same way the parser does.
Per bug #5716 from Andrew Tipton. Back-patch to 9.0 where one of the bogus
calls was introduced (the other one is new in HEAD).
Magnus Hagander [Sun, 17 Oct 2010 14:36:54 +0000 (16:36 +0200)]
Fix msvc build for localized versions of Visual C++
Look only at the non-localized part of the output from "vcbuild /?",
which is used to determine the version of Visual Studio in use. Different
languages seem to localize different amounts of the string, but we assume
the part "Microsoft Visual C++" won't be modified.
Magnus Hagander [Fri, 15 Oct 2010 14:59:12 +0000 (16:59 +0200)]
Fix low-risk potential denial of service against RADIUS login.
Corrupt RADIUS responses were treated as errors and not ignored
(which the RFC2865 states they should be). This meant that a
user with unfiltered access to the network of the PostgreSQL
or RADIUS server could send a spoofed RADIUS response
to the PostgreSQL server causing it to reject a valid login,
provided the attacker could also guess (or brute-force) the
correct port number.
Fix is to simply retry the receive in a loop until the timeout
has expired or a valid (signed by the correct RADIUS server)
packet arrives.
Peter Eisentraut [Thu, 14 Oct 2010 17:36:42 +0000 (20:36 +0300)]
Complete the documentation of the USAGE privilege for foreign servers
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.
Tom Lane [Mon, 11 Oct 2010 23:04:44 +0000 (19:04 -0400)]
Fix assorted bugs in GIN's WAL replay logic.
The original coding was quite sloppy about handling the case where
XLogReadBuffer fails (because the page has since been deleted). This
would result in either "bad buffer id: 0" or an Assert failure during
replay, if indeed the page were no longer there. In a couple of places
it also neglected to check whether the change had already been applied,
which would probably result in corrupted index contents. I believe that
bug #5703 is an instance of the first problem. These issues could show up
without replication, but only if you were unfortunate enough to crash
between modification of a GIN index and the next checkpoint.
Back-patch to 8.2, which is as far back as GIN has WAL support.
Robert Haas [Thu, 7 Oct 2010 16:19:03 +0000 (12:19 -0400)]
Improve WAL reliability documentation, and add more cross-references to it.
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.
Simon Riggs [Tue, 5 Oct 2010 23:20:54 +0000 (00:20 +0100)]
Correct docs for behaviour of ALTER DATABASE .. RENAME during Hot Standby.
Actual behaviour did not match documented behaviour and we have agreed
that it should be the docs that change.
Tom Lane [Sun, 3 Oct 2010 00:02:33 +0000 (20:02 -0400)]
Behave correctly if INSERT ... VALUES is decorated with additional clauses.
In versions 8.2 and up, the grammar allows attaching ORDER BY, LIMIT,
FOR UPDATE, or WITH to VALUES, and hence to INSERT ... VALUES. But the
special-case code for VALUES in transformInsertStmt() wasn't expecting any
of those, and just ignored them, leading to unexpected results. Rather
than complicate the special-case path, just ensure that the presence of any
of those clauses makes us treat the query as if it had a general SELECT.
Per report from Hitoshi Harada.
Tom Lane [Sat, 2 Oct 2010 22:21:41 +0000 (18:21 -0400)]
Throw an appropriate error if ALTER COLUMN TYPE finds a dependent trigger.
Actually making this case work, if the column is used in the trigger's
WHEN condition, will take some new code that probably isn't appropriate
to back-patch. For now, just throw a FEATURE_NOT_SUPPORTED error rather
than allowing control to reach the "unexpected object" case. Per bug #5688
from Daniel Grace. Back-patch to 9.0 where the possibility of such a
dependency was introduced.
Tom Lane [Thu, 30 Sep 2010 21:19:44 +0000 (17:19 -0400)]
Use a separate interpreter for each calling SQL userid in plperl and pltcl.
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.
Bruce Momjian [Tue, 28 Sep 2010 19:25:13 +0000 (19:25 +0000)]
Properly close files after read file failure to prevent potential
resource leak. Of course, any such failure aborts pg_upgrade, but might
as well be clean about it.
Tom Lane [Tue, 28 Sep 2010 16:08:56 +0000 (12:08 -0400)]
Fix PlaceHolderVar mechanism's interaction with outer joins.
The point of a PlaceHolderVar is to allow a non-strict expression to be
evaluated below an outer join, after which its value bubbles up like a Var
and can be forced to NULL when the outer join's semantics require that.
However, there was a serious design oversight in that, namely that we
didn't ensure that there was actually a correct place in the plan tree
to evaluate the placeholder :-(. It may be necessary to delay evaluation
of an outer join to ensure that a placeholder that should be evaluated
below the join can be evaluated there. Per recent bug report from Kirill
Simonov.
Back-patch to 8.4 where the PlaceHolderVar mechanism was introduced.
Tom Lane [Sat, 25 Sep 2010 23:04:02 +0000 (19:04 -0400)]
Fix another join removal bug: the check on PlaceHolderVars was wrong.
The previous coding would decide that join removal was unsafe upon finding
a PlaceHolderVar that needed to be evaluated at the inner rel and then used
above the join. However, this fails to cover the case of PlaceHolderVars
that refer to both the inner rel and some other rels. Per bug report from
Andrus.
Tom Lane [Sat, 25 Sep 2010 19:57:05 +0000 (15:57 -0400)]
Further fixes to the pg_get_expr() security fix in back branches.
It now emerges that the JDBC driver expects to be able to use pg_get_expr()
on an output of a sub-SELECT. So extend the check logic to be able to recurse
into a sub-SELECT to see if the argument is ultimately coming from an
appropriate column. Per report from Thomas Kellerer.
Peter Eisentraut [Sat, 25 Sep 2010 06:57:09 +0000 (09:57 +0300)]
Fix man page markup for <cmdsynopsis> with multiple variants
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>.
Tom Lane [Thu, 23 Sep 2010 20:53:22 +0000 (16:53 -0400)]
Prevent show_session_authorization from crashing when session_authorization
hasn't been set.
The only known case where this can happen is when show_session_authorization
is invoked in an autovacuum process, which is possible if an index function
calls it, as for example in bug #5669 from Andrew Geery. We could perhaps
try to return a sensible value, such as the name of the cluster-owning
superuser; but that seems like much more trouble than the case is worth,
and in any case it could create new possible failure modes. Simply
returning an empty string seems like the most appropriate fix.
Back-patch to all supported versions, even those before autovacuum, just
in case there's another way to provoke this crash.
Tom Lane [Thu, 23 Sep 2010 23:34:56 +0000 (19:34 -0400)]
Avoid sharing subpath list structure when flattening nested AppendRels.
In some situations the original coding led to corrupting the child AppendRel's
subpaths list, effectively adding other members of the parent's list to it.
This was usually masked because we never made any further use of the child's
list, but given the right combination of circumstances, we could do so. The
visible symptom would be a relation getting scanned twice, as in bug #5673
from David Schmitt.
Backpatch to 8.2, which is as far back as the risky coding appears. The
example submitted by David only fails in 8.4 and later, but I'm not convinced
that there aren't any even-more-obscure cases where 8.2 and 8.3 would fail.
Initialize tableoid field correctly when dumping foreign data wrappers and
servers. AFAICT it's harmless at the moment because nothing can depend on
either, but as soon as we introduce an object type with such dependencies,
tableoid needs to be set or pg_dump will fail to interpret the dependencies
correctly. In theory, I guess the uninitialized garbage in tableoid could
cause the object to be mistaken for some other object with same OID as well.
Tom Lane [Thu, 23 Sep 2010 03:48:14 +0000 (23:48 -0400)]
Re-allow input of Julian dates prior to 0001-01-01 AD.
This was unintentionally broken in 8.4 while tightening up checking of
ordinary non-Julian date inputs to forbid references to "year zero".
Per bug #5672 from Benjamin Gigot.
Tom Lane [Thu, 23 Sep 2010 02:32:19 +0000 (22:32 -0400)]
More fixes for libpq's .gitignore file.
The previous patches failed to cover a lot of symlinks that are only
added in platform-specific cases. Make the lists match what's in the
Makefile for each branch.
Magnus Hagander [Thu, 16 Sep 2010 20:37:18 +0000 (20:37 +0000)]
Treat exit code 128 (ERROR_WAIT_NO_CHILDREN) as non-fatal on Win32,
since it can happen when a process fails to start when the system
is under high load.
Per several bug reports and many peoples investigation.
Back-patch to 8.4, which is as far back as the "deadman-switch"
for shared memory access exists.
Tom Lane [Thu, 16 Sep 2010 02:54:07 +0000 (02:54 +0000)]
Fix two new-in-9.0 bugs in hstore.
There was an incorrect Assert in hstoreValidOldFormat(), which would cause
immediate core dumps when attempting to work with pre-9.0 hstore data,
but of course only in an assert-enabled build.
Also, ghstore_decompress() incorrectly applied DatumGetHStoreP() to a datum
that wasn't actually an hstore, but rather a ghstore (ie, a gist signature
bitstring). That used to be harmless, but could now result in misbehavior
if the hstore format conversion code happened to trigger. In reality,
since ghstore is not marked toastable (and doesn't need to be), this
function is useless anyway; we can lobotomize it down to returning the
passed-in pointer.
Both bugs found by Andrew Gierth, though this isn't exactly his proposed
patch.
Tom Lane [Wed, 15 Sep 2010 17:46:02 +0000 (17:46 +0000)]
Add a compatibility note about plpgsql's treatment of SELECT INTO rec.fld
when fld is of composite type. Per discussion of bug #5644 from Valentine
Gogichashvili.
Tom Lane [Tue, 14 Sep 2010 23:15:37 +0000 (23:15 +0000)]
Fix join-removal logic for pseudoconstant and outerjoin-delayed quals.
In these cases a qual can get marked with the removable rel in its
required_relids, but this is just to schedule its evaluation correctly, not
because it really depends on the rel. We were assuming that, in effect,
we could throw away *all* quals so marked, which is nonsense. Tighten up
the logic to be a little more paranoid about which quals belong to the
outer join being considered for removal, and arrange for all quals that
don't belong to be updated so they will still get evaluated correctly.
Also fix another problem that happened to be exposed by this test case,
which was that make_join_rel() was failing to notice some cases where
a constant-false qual could be used to prove a join relation empty. If it's
a pushed-down constant false, then the relation is empty even if it's an
outer join, because the qual applies after the outer join expansion.
Per report from Nathan Grange. Back-patch into 9.0.
Don't warn about an in-progress online backup, when we're recovering from
an online backup instead of performing one. pg_ctl can detect that by
checking if recovery.conf exists.
Backup label file is renamed away early in recovery, so the window where
backup label exists during recovery is normally very small, but you can run
into it e.g if restore_command is set incorrectly and the startup process
never finds even the first WAL segment containing the checkpoint record to
start recovery from.
Remove prototype for non-existent function from walreceiver.h. Tidy up by
separating prototypes for functions in walreceiver.c and walreceiverfuncs.c
with comments.
Process options from the startup packed in walsender. Only few options
make sense for walsender, but for example application_name and client_encoding
do. We still don't apply per-role settings from pg_db_role_setting, because
that would require connecting to a database to read the table.
Tom Lane [Thu, 9 Sep 2010 17:19:46 +0000 (17:19 +0000)]
Remove obsolete claim that gzip is needed while installing PG's documentation.
It isn't, now that we ship the docs as loose files rather than a sub-tarball.
Also adjust the wording in a couple of places to make the lists of required
software read more consistently.
Bruce Momjian [Thu, 9 Sep 2010 00:48:29 +0000 (00:48 +0000)]
Doc fixes:
- remove excessive table cells
- moving function parameters into function tags rather than having
them being considered separate
- add return type column on XML2 contrib module functions list and
removing return types from function
- add table header to XML2 contrib parameter table
Bruce Momjian [Tue, 7 Sep 2010 14:10:39 +0000 (14:10 +0000)]
Modify pg_upgrade to set/restore all environment variables related to
collation/encoding to match English when reading controldata. This now
matches the English variable setting used by pg_regress.c.
Tom Lane [Sat, 4 Sep 2010 17:46:03 +0000 (17:46 +0000)]
Pad the ps_status display with nulls, not blanks, on Darwin.
A long time ago, this didn't work nicely, but it seems to work on all recent
versions of OS X. The blank-pad method is less desirable since it results
in lots of extra space in ps' output. Per Alexey Klyukin.
Tom Lane [Thu, 2 Sep 2010 03:16:52 +0000 (03:16 +0000)]
Fix up flushing of composite-type typcache entries to be driven directly by
SI invalidation events, rather than indirectly through the relcache.
In the previous coding, we had to flush a composite-type typcache entry
whenever we discarded the corresponding relcache entry. This caused problems
at least when testing with RELCACHE_FORCE_RELEASE, as shown in recent report
from Jeff Davis, and might result in real-world problems given the kind of
unexpected relcache flush that that test mechanism is intended to model.
The new coding decouples relcache and typcache management, which is a good
thing anyway from a structural perspective. The cost is that we have to
search the typcache linearly to find entries that need to be flushed. There
are a couple of ways we could avoid that, but at the moment it's not clear
it's worth any extra trouble, because the typcache contains very few entries
in typical operation.
Back-patch to 8.2, the same as some other recent fixes in this general area.
The patch could be carried back to 8.0 with some additional work, but given
that it's only hypothetical whether we're fixing any problem observable in
the field, it doesn't seem worth the work now.