Tom Lane [Thu, 25 Feb 2010 20:59:53 +0000 (20:59 +0000)]
Allow predicate_refuted_by() to deduce that NOT A refutes A.
We had originally made the stronger assumption that NOT A refutes any B
if B implies A, but this fails in three-valued logic, because we need to
prove B is false not just that it's not true. However the logic does
go through if B is equal to A.
Recognizing this limited case is enough to handle examples that arise when
we have simplified "bool_var = true" or "bool_var = false" to just "bool_var"
or "NOT bool_var". If we had not done that simplification then the
btree-operator proof logic would have been able to prove that the expressions
were contradictory, but only for identical expressions being compared to the
constants; so handling identical A and B covers all the same cases.
The motivation for doing this is to avoid unexpected asymmetrical behavior
when a partitioned table uses a boolean partitioning column, as in today's
gripe from Dominik Sander.
Back-patch to 8.2, which is as far back as predicate_refuted_by attempts to
do anything at all with NOTs.
Magnus Hagander [Thu, 25 Feb 2010 13:26:16 +0000 (13:26 +0000)]
Add configuration parameter ssl_renegotiation_limit to control
how often we do SSL session key renegotiation. Can be set to
0 to disable renegotiation completely, which is required if
a broken SSL library is used (broken patches to CVE-2009-3555
a known cause) or when using a client library that can't do
renegotiation.
Tom Lane [Wed, 24 Feb 2010 18:02:24 +0000 (18:02 +0000)]
Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations.
The main motivation for changing this is bug #4921, in which it's pointed out
that it's no longer safe to apply ltree operations to the result of
ARRAY(SELECT ...) if the sub-select might return no rows. Before 8.3,
the ARRAY() construct would return NULL, which might or might not be helpful
but at least it wouldn't result in an error. Now it returns an empty array
which results in a failure for no good reason, since the ltree operations
are all perfectly capable of dealing with zero-element arrays.
As far as I can find, these ltree functions are the only places where zero
array dimensionality is rejected unnecessarily.
Back-patch to 8.3 to prevent behavioral regression of queries that worked
in older releases.
Tom Lane [Wed, 24 Feb 2010 02:42:55 +0000 (02:42 +0000)]
Fix patch for printing backend and pg_dump versions so that it works in
a desirable fashion in archive-dump cases, ie you should get the pg_dump
version not the pg_restore version.
Tom Lane [Wed, 24 Feb 2010 02:15:58 +0000 (02:15 +0000)]
Un-break pg_dump for the case of zero-column tables.
This was evidently broken by the CREATE TABLE OF TYPE patch. It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...
Tom Lane [Wed, 24 Feb 2010 01:57:16 +0000 (01:57 +0000)]
Use CREATE OR REPLACE LANGUAGE in pg_dump to avoid the need for a couple of
significantly uglier kluges that were working around the change in plpgsql's
preinstalled status.
Tom Lane [Wed, 24 Feb 2010 01:35:14 +0000 (01:35 +0000)]
Make pg_regress use CREATE OR REPLACE LANGUAGE, so that --load-language
will work whether or not the specified language is preinstalled. This
responds to some complaints about having to change test scripts because
plpgsql is preinstalled as of 9.0.
Tom Lane [Tue, 23 Feb 2010 22:51:43 +0000 (22:51 +0000)]
Add an OR REPLACE option to CREATE LANGUAGE.
This operates in the same way as other CREATE OR REPLACE commands, ie,
it replaces everything but the ownership and ACL lists of an existing
entry, and requires the caller to have owner privileges for that entry.
While modifying an existing language has some use in development scenarios,
in typical usage all the "replaced" values come from pg_pltemplate so there
will be no actual change in the language definition. The reason for adding
this is mainly to allow programs to ensure that a language exists without
triggering an error if it already does exist.
This commit just adds and documents the new option. A followon patch
will use it to clean up some unpleasant cases in pg_dump and pg_regress.
Tom Lane [Tue, 23 Feb 2010 18:35:07 +0000 (18:35 +0000)]
Fix configure's regexp for extracting the Perl version number from perl -v
output. Per bug #5339, Perl 5.11 has changed the format of that output
enough to break the previous coding.
Tom Lane [Tue, 23 Feb 2010 16:55:22 +0000 (16:55 +0000)]
Minor style policing for error messages in pg_dump tar code. Notably, change
"dumping data out of order is not supported" to "restoring data out of order
is not supported", because you get that error during pg_restore not pg_dump.
Also fix some comments that didn't look so good after being pgindented as
perhaps they did originally.
Tom Lane [Mon, 22 Feb 2010 15:29:46 +0000 (15:29 +0000)]
Let's try forcing errno to zero before issuing fsync. The current buildfarm
results claiming EBADF seem improbable enough that I'm not convinced fsync
is really returning that --- could it be failing to set errno at all?
Tom Lane [Mon, 22 Feb 2010 15:26:14 +0000 (15:26 +0000)]
Adjust pg_fsync_writethrough so that it will set errno when failing
on a platform that doesn't support this operation. The former coding
would allow an unrelated errno to be reported, which would be quite
misleading. Not sure if this has anything to do with the current
buildfarm failures, but it's certainly bogus as-is.
Move documentation of all recovery.conf option to a new chapter.
They used to be scattered between the "backup and restore" and "streaming
replication" chapters.
Tom Lane [Sat, 20 Feb 2010 21:24:02 +0000 (21:24 +0000)]
Clean up handling of XactReadOnly and RecoveryInProgress checks.
Add some checks that seem logically necessary, in particular let's make
real sure that HS slave sessions cannot create temp tables. (If they did
they would think that temp tables belonging to the master's session with
the same BackendId were theirs. We *must* not allow myTempNamespace to
become set in a slave session.)
Change setval() and nextval() so that they are only allowed on temp sequences
in a read-only transaction. This seems consistent with what we allow for
table modifications in read-only transactions. Since an HS slave can't have a
temp sequence, this also provides a nicer cure for the setval PANIC reported
by Erik Rijkers.
Make the error messages more uniform, and have them mention the specific
command being complained of. This seems worth the trifling amount of extra
code, since people are likely to see such messages a lot more than before.
Tom Lane [Fri, 19 Feb 2010 21:49:10 +0000 (21:49 +0000)]
Reduce the rescan cost estimate for Materialize nodes to cpu_operator_cost per
tuple, instead of the former cpu_tuple_cost. It is sane to charge less than
cpu_tuple_cost because Materialize never does any qual-checking or projection,
so it's got less overhead than most plan node types. In particular, we want
to have the same charge here as is charged for readout in cost_sort. That
avoids the problem recently exhibited by Teodor wherein the planner prefers
a useless sort over a materialize step in a context where a lot of rescanning
will happen. The rescan costs should be just about the same for both node
types, so make their estimates the same.
Not back-patching because all of the current logic for rescan cost estimates
is new in 9.0. The old handling of rescans is sufficiently not-sane that
changing this in that structure is a bit pointless, and might indeed cause
regressions.
Don't use O_DIRECT when writing WAL files if archiving or streaming is
enabled. Bypassing the kernel cache is counter-productive in that case,
because the archiver/walsender process will read from the WAL file
soon after it's written, and if it's not cached the read will cause
a physical read, eating I/O bandwidth available on the WAL drive.
Also, walreceiver process does unaligned writes, so disable O_DIRECT
in walreceiver process for that reason too.
Itagaki Takahiro [Fri, 19 Feb 2010 01:04:03 +0000 (01:04 +0000)]
Fix STOP WAL LOCATION in backup history files no to return the next
segment of XLOG_BACKUP_END record even if the the record is placed
at a segment boundary. Furthermore the previous implementation could
return nonexistent segment file name when the boundary is in segments
that has "FE" suffix; We never use segments with "FF" suffix.
Backpatch to 8.0, where hot backup was introduced.
Tom Lane [Thu, 18 Feb 2010 23:50:06 +0000 (23:50 +0000)]
Volatile-ize all five places where we expect a PG_TRY block to restore
old memory context in plpython. Before only one of them was marked
volatile, but per report from Zdenek Kotala, some compilers do the
wrong thing here.
Tom Lane [Thu, 18 Feb 2010 22:43:31 +0000 (22:43 +0000)]
Provide some rather hokey ways for EXPLAIN to print FieldStore and assignment
ArrayRef expressions that are not in the immediate context of an INSERT or
UPDATE targetlist. Such cases never arise in stored rules, so ruleutils.c
hadn't tried to handle them. However, they do occur in the targetlists of
plans derived from such statements, and now that EXPLAIN VERBOSE tries to
print targetlists, we need some way to deal with the case.
I chose to represent an assignment ArrayRef as "array[subscripts] := source",
which is fairly reasonable and doesn't omit any information. However,
FieldStore is problematic because the planner will fold multiple assignments
to fields of the same composite column into one FieldStore, resulting in a
structure that is hard to understand at all, let alone display comprehensibly.
So in that case I punted and just made it print the source expression(s).
Backpatch to 8.4 --- the lack of functionality exists in older releases,
but doesn't seem to be important for lack of anything that would call it.
Tom Lane [Thu, 18 Feb 2010 18:41:47 +0000 (18:41 +0000)]
Fix ExecEvalArrayRef to pass down the old value of the array element or slice
being assigned to, in case the expression to be assigned is a FieldStore that
would need to modify that value. The need for this was foreseen some time
ago, but not implemented then because we did not have arrays of composites.
Now we do, but the point evidently got overlooked in that patch. Net result
is that updating a field of an array element doesn't work right, as
illustrated if you try the new regression test on an unpatched backend.
Noted while experimenting with EXPLAIN VERBOSE, which has also got some issues
in this area.
Backpatch to 8.3, where arrays of composites were introduced.
Fix pq_getbyte_if_available() function. It was confused on what it
returns if no data is immediately available. Patch by me with numerous
fixes from Fujii Masao and Magnus Hagander.
Tom Lane [Thu, 18 Feb 2010 03:06:46 +0000 (03:06 +0000)]
Force READY portals into FAILED state when a transaction or subtransaction
is aborted, if they were created within the failed xact. This prevents
ExecutorEnd from being run on them, which is a good idea because they may
contain references to tables or other objects that no longer exist.
In particular this is hazardous when auto_explain is active, but it's
really rather surprising that nobody has seen an issue with this before.
I'm back-patching this to 8.4, since that's the first version that contains
auto_explain or an ExecutorEnd hook, but I wonder whether we shouldn't
back-patch further.
Tom Lane [Thu, 18 Feb 2010 01:29:10 +0000 (01:29 +0000)]
Fix up pg_dump's treatment of large object ownership and ACLs. We now emit
a separate archive entry for each BLOB, and use pg_dump's standard methods
for dealing with its ownership, ACL if any, and comment if any. This means
that switches like --no-owner and --no-privileges do what they're supposed
to. Preliminary testing says that performance is still reasonable even
with many blobs, though we'll have to see how that shakes out in the field.
Itagaki Takahiro [Wed, 17 Feb 2010 04:09:40 +0000 (04:09 +0000)]
Support new syntax and improve handling of parentheses in psql tab-completion.
Newly supported syntax are:
- ALTER {TABLE|INDEX|TABLESPACE} {SET|RESET} with options
- ALTER TABLE ALTER COLUMN {SET|RESET} with options
- ALTER TABLE ALTER COLUMN SET STORAGE
- CREATE INDEX CONCURRENTLY
- CREATE INDEX ON (without name)
- CREATE INDEX ... USING with pg_am.amname instead of hard-corded names
- CREATE TRIGGER with events
- DROP AGGREGATE function with arguments
Tom Lane [Wed, 17 Feb 2010 03:10:33 +0000 (03:10 +0000)]
When updating ShmemVariableCache from a checkpoint record, be sure to set
all the values derived from oldestXid, not just that field. Brain fade in
one of my patches associated with flat file removal, exposed by a report
from Fujii Masao.
With this change, xidVacLimit should always be valid, so remove a couple of
bits of complexity associated with the previous assumption that sometimes
it wouldn't get set right away.