Commit Graph

35623 Commits

Author SHA1 Message Date
Alvaro Herrera
673b527534 Fix some "translator:" comments mangled by pgindent 2013-08-27 13:33:37 -04:00
Robert Haas
8d00ab6306 doc: Explain that ereport doesn't return for ERROR or higher levels.
Christophe Pettus
2013-08-26 14:27:43 -04:00
Tom Lane
2aac3399ae Account better for planning cost when choosing whether to use custom plans.
The previous coding in plancache.c essentially used 10% of the estimated
runtime as its cost estimate for planning.  This can be pretty bogus,
especially when the estimated runtime is very small, such as in a simple
expression plan created by plpgsql, or a simple INSERT ... VALUES.

While we don't have a really good handle on how planning time compares
to runtime, it seems reasonable to use an estimate based on the number of
relations referenced in the query, with a rather large multiplier.  This
patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a
trivial query will be charged 1000 * cpu_operator_cost for planning.
This should address the problem reported by Marc Cousin and others that
9.2 and up prefer custom plans in cases where the planning time greatly
exceeds what can be saved.
2013-08-24 15:14:17 -04:00
Magnus Hagander
db4ef73760 Don't crash when pg_xlog is empty and pg_basebackup -x is used
The backup will not work (without a logarchive, and that's the whole
point of -x) in this case, this patch just changes it to throw an
error instead of crashing when this happens.

Noticed and diagnosed by TAKATSUKA Haruka
2013-08-24 17:13:49 +02:00
Tom Lane
fcf9ecad57 In locate_grouping_columns(), don't expect an exact match of Var typmods.
It's possible that inlining of SQL functions (or perhaps other changes?)
has exposed typmod information not known at parse time.  In such cases,
Vars generated by query_planner might have valid typmod values while the
original grouping columns only have typmod -1.  This isn't a semantic
problem since the behavior of grouping only depends on type not typmod,
but it breaks locate_grouping_columns' use of tlist_member to locate the
matching entry in query_planner's result tlist.

We can fix this without an excessive amount of new code or complexity by
relying on the fact that locate_grouping_columns only gets called when
make_subplanTargetList has set need_tlist_eval == false, and that can only
happen if all the grouping columns are simple Vars.  Therefore we only need
to search the sub_tlist for a matching Var, and we can reasonably define a
"match" as being a match of the Var identity fields
varno/varattno/varlevelsup.  The code still Asserts that vartype matches,
but ignores vartypmod.

Per bug #8393 from Evan Martin.  The added regression test case is
basically the same as his example.  This has been broken for a very long
time, so back-patch to all supported branches.
2013-08-23 17:30:53 -04:00
Tom Lane
3454876314 Fix hash table size estimation error in choose_hashed_distinct().
We should account for the per-group hashtable entry overhead when
considering whether to use a hash aggregate to implement DISTINCT.  The
comparable logic in choose_hashed_grouping() gets this right, but I think
I omitted it here in the mistaken belief that there would be no overhead
if there were no aggregate functions to be evaluated.  This can result in
more than 2X underestimate of the hash table size, if the tuples being
aggregated aren't very wide.  Per report from Tomas Vondra.

This bug is of long standing, but per discussion we'll only back-patch into
9.3.  Changing the estimation behavior in stable branches seems to carry too
much risk of destabilizing plan choices for already-tuned applications.
2013-08-21 13:38:34 -04:00
Bruce Momjian
5dcc48c2c7 docs: Remove second 'trim' index reference
Per suggestion from Vik Fearing
2013-08-21 07:32:48 -04:00
Andrew Dunstan
73838b5251 Unconditionally use the WSA equivalents of Socket error constants.
This change will only apply to mingw compilers, and has been found
necessary by late versions of the mingw-w64 compiler. It's the same as
what is done elsewhere for the Microsoft compilers.

If this doesn't upset older compilers in the buildfarm, it will be
backpatched to 9.1.

Problem reported by Michael Cronenworth, although not his patch.
2013-08-20 14:11:36 -04:00
Bruce Momjian
b3cc173e19 release notes: update link to 9.3 PL/pgSQL constraint error info
Backpatch to 9.3.

Pavel Stehule
2013-08-20 09:39:08 -04:00
Tom Lane
20fe870753 Be more wary of unwanted whitespace in pgstat_reset_remove_files().
sscanf isn't the easiest thing to use for exact pattern checks ...
also, don't use strncmp where strcmp will do.
2013-08-19 19:36:04 -04:00
Alvaro Herrera
f9b50b7c18 Fix removal of files in pgstats directories
Instead of deleting all files in stats_temp_directory and the permanent
directory on a crash, only remove those files that match the pattern of
files we actually write in them, to avoid possibly clobbering existing
unrelated contents of the temporary directory.  Per complaint from Jeff
Janes, and subsequent discussion, starting at message
CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com

Also, fix a bug in the same routine to avoid removing files from the
permanent directory twice (instead of once from that directory and then
from the temporary directory), also per report from Jeff Janes, in
message
CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 17:48:17 -04:00
Heikki Linnakangas
3619a20d33 Rename the "fast_promote" file to just "promote".
This keeps the usual trigger file name unchanged from 9.2, avoiding nasty
issues if you use a pre-9.3 pg_ctl binary with a 9.3 server or vice versa.
The fallback behavior of creating a full checkpoint before starting up is now
triggered by a file called "fallback_promote". That can be useful for
debugging purposes, but we don't expect any users to have to resort to that
and we might want to remove that in the future, which is why the fallback
mechanism is undocumented.
2013-08-19 20:59:51 +03:00
Tom Lane
c64de21e96 Fix qual-clause-misplacement issues with pulled-up LATERAL subqueries.
In an example such as
SELECT * FROM
  i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true;
it is safe to pull up the LATERAL subquery into its parent, but we must
then treat the "i.n = j.n" clause as a qual clause of the LEFT JOIN.  The
previous coding in deconstruct_recurse mistakenly labeled the clause as
"is_pushed_down", resulting in wrong semantics if the clause were applied
at the join node, as per an example submitted awhile ago by Jeremy Evans.
To fix, postpone processing of such clauses until we return back up to
the appropriate recursion depth in deconstruct_recurse.

In addition, tighten the is-safe-to-pull-up checks in is_simple_subquery;
we previously missed the possibility that the LATERAL subquery might itself
contain an outer join that makes lateral references in lower quals unsafe.

A regression test case equivalent to Jeremy's example was already in my
commit of yesterday, but was giving the wrong results because of this
bug.  This patch fixes the expected output for that, and also adds a
test case for the second problem.
2013-08-19 13:19:41 -04:00
Alvaro Herrera
78e1220104 Fix pg_upgrade failure from servers older than 9.3
When upgrading from servers of versions 9.2 and older, and MultiXactIds
have been used in the old server beyond the first page (that is, 2048
multis or more in the default 8kB-page build), pg_upgrade would set the
next multixact offset to use beyond what has been allocated in the new
cluster.  This would cause a failure the first time the new cluster
needs to use this value, because the pg_multixact/offsets/ file wouldn't
exist or wouldn't be large enough.  To fix, ensure that the transient
server instances launched by pg_upgrade extend the file as necessary.

Per report from Jesse Denardo in
CANiVXAj4c88YqipsyFQPboqMudnjcNTdB3pqe8ReXqAFQ=HXyA@mail.gmail.com
2013-08-19 12:56:18 -04:00
Bruce Momjian
1bc5935b67 release notes: remove username from 9.3 major item
Etsuro Fujita
2013-08-19 12:26:22 -04:00
Peter Eisentraut
a2f2e902b8 Translation updates 2013-08-18 23:41:03 -04:00
Kevin Grittner
28154bb23b Remove relcache entry invalidation in REFRESH MATERIALIZED VIEW.
This was added as part of the attempt to support unlogged matviews
along with a populated status.  It got missed when unlogged
support was removed pre-commit.

Noticed by Noah Misch.  Back-patched to 9.3 branch.
2013-08-18 16:19:22 -05:00
Peter Eisentraut
fe885c6e36 libpq: Report strerror on pthread_mutex_lock() failure 2013-08-17 21:46:32 -04:00
Tom Lane
f1d5fce7cf Fix thinko in comment. 2013-08-17 20:36:29 -04:00
Tom Lane
9e7e29c75a Fix planner problems with LATERAL references in PlaceHolderVars.
The planner largely failed to consider the possibility that a
PlaceHolderVar's expression might contain a lateral reference to a Var
coming from somewhere outside the PHV's syntactic scope.  We had a previous
report of a problem in this area, which I tried to fix in a quick-hack way
in commit 4da6439bd8, but Antonin Houska
pointed out that there were still some problems, and investigation turned
up other issues.  This patch largely reverts that commit in favor of a more
thoroughly thought-through solution.  The new theory is that a PHV's
ph_eval_at level cannot be higher than its original syntactic level.  If it
contains lateral references, those don't change the ph_eval_at level, but
rather they create a lateral-reference requirement for the ph_eval_at join
relation.  The code in joinpath.c needs to handle that.

Another issue is that createplan.c wasn't handling nested PlaceHolderVars
properly.

In passing, push knowledge of lateral-reference checks for join clauses
into join_clause_is_movable_to.  This is mainly so that FDWs don't need
to deal with it.

This patch doesn't fix the original join-qual-placement problem reported by
Jeremy Evans (and indeed, one of the new regression test cases shows the
wrong answer because of that).  But the PlaceHolderVar problems need to be
fixed before that issue can be addressed, so committing this separately
seems reasonable.
2013-08-17 20:22:37 -04:00
Bruce Momjian
175ec8de47 release notes: update 9.3 major feature list
Backpatch to 9.3.
2013-08-16 18:01:05 -04:00
Bruce Momjian
e91f2bb3ee release notes: Update to 9.3 git current
Backpatch to 9.3, of course.
2013-08-16 16:54:48 -04:00
Robert Haas
2dee7998f9 Move more bgworker code to bgworker.c; also, some renaming.
Per discussion on pgsql-hackers.

Michael Paquier, slightly modified by me.  Original suggestion
from Amit Kapila.
2013-08-16 15:31:28 -04:00
Bruce Momjian
ac76ec27b9 pg_upgrade: shut down server after auth failure
Register atexit() server shutdown if pg_ctl successfully started the
server, but we can't connect to it.

Backpatch to 9.3.

Pavel Raiskup
2013-08-16 11:09:09 -04:00
Heikki Linnakangas
05cbce6f30 Fix typo in comment. 2013-08-16 16:26:22 +03:00
Kevin Grittner
3f78b1715c Don't allow ALTER MATERIALIZED VIEW ADD UNIQUE.
Was accidentally allowed, but not documented and lacked support
for rename or drop once created.

Per report from Noah Misch.
2013-08-15 13:14:48 -05:00
Magnus Hagander
62e28b3e41 Add tab completion for \dx in psql 2013-08-15 18:44:50 +02:00
Peter Eisentraut
229fb58d4f Treat timeline IDs as unsigned in replication parser
Timeline IDs are unsigned ints everywhere, except the replication parser
treated them as signed ints.
2013-08-14 23:18:49 -04:00
Peter Eisentraut
32f7c0ae17 Improve error message when view is not updatable
Avoid using the term "updatable" in confusing ways.  Suggest a trigger
first, before a rule.
2013-08-14 23:02:59 -04:00
Tom Lane
1b1d3d92c3 Remove ph_may_need from PlaceHolderInfo, with attendant simplifications.
The planner logic that attempted to make a preliminary estimate of the
ph_needed levels for PlaceHolderVars seems to be completely broken by
lateral references.  Fortunately, the potential join order optimization
that this code supported seems to be of relatively little value in
practice; so let's just get rid of it rather than trying to fix it.

Getting rid of this allows fairly substantial simplifications in
placeholder.c, too, so planning in such cases should be a bit faster.

Issue noted while pursuing bugs reported by Jeremy Evans and Antonin
Houska, though this doesn't in itself fix either of their reported cases.
What this does do is prevent an Assert crash in the kind of query
illustrated by the added regression test.  (I'm not sure that the plan for
that query is stable enough across platforms to be usable as a regression
test output ... but we'll soon find out from the buildfarm.)

Back-patch to 9.3.  The problem case can't arise without LATERAL, so
no need to touch older branches.
2013-08-14 18:38:47 -04:00
Bruce Momjian
5368a23eeb docs: document TRIM "comma" syntax
This syntax is supported by the parser, but is non-standard.

_Not_ backpatched to 9.3 in case we change our minds.
2013-08-14 17:26:36 -04:00
Kevin Grittner
e2cd368678 Remove Assert that matview is not in system schema from REFRESH.
We don't want to prevent an extension which creates a matview from
being installed in pg_catalog.

Issue was raised by Hitoshi Harada.
Backpatched to 9.3.
2013-08-14 12:36:55 -05:00
Peter Eisentraut
5e3e8e4daa Update Emacs configuration
Update emacs.samples with new configuration snippets that match pgindent
et al. formatting more accurately and follow Emacs Lisp best practices
better.

Add .dir-locals.el with a subset of that configuration for casual
editing and viewing.

Reviewed-by: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Reviewed-by: Noah Misch <noah@leadboat.com>
2013-08-13 20:08:44 -04:00
Tom Lane
3d5282c6f0 Emit a log message if output is about to be redirected away from stderr.
We've seen multiple cases of people looking at the postmaster's original
stderr output to try to diagnose problems, not realizing/remembering that
their logging configuration is set up to send log messages somewhere else.
This seems particularly likely to happen in prepackaged distributions,
since many packagers patch the code to change the factory-standard logging
configuration to something more in line with their platform conventions.

In hopes of reducing confusion, emit a LOG message about this at the point
in startup where we are about to switch log output away from the original
stderr, providing a pointer to where to look instead.  This message will
appear as the last thing in the original stderr output.  (We might later
also try to emit such link messages when logging parameters are changed
on-the-fly; but that case seems to be both noticeably harder to do nicely,
and much less frequently a problem in practice.)

Per discussion, back-patch to 9.3 but not further.
2013-08-13 15:24:52 -04:00
Bruce Momjian
b52cd9d022 9.3 release notes: move foreign table item
Move item about foreign data wrappers supporting inserts/updates/deletes
to object manipulation.

From Etsuro Fujita
2013-08-13 12:49:24 -04:00
Bruce Momjian
808f8f5d6d pg_dump: avoid schema qualification for ALTER ... OWNER
We already use search_path to specify the schema, so there is no need
for pg_dump to schema-qualify the name.  Also remove dead code.
2013-08-13 11:45:56 -04:00
Peter Eisentraut
527ea66849 PL/Python: Adjust the regression tests for Python 3.3
Similar to 2cfb1c6f77, the order in which
dictionary elements are printed is not reliable.  This reappeared in the
tests of the string representation of result objects.  Reduce the test
case to one result set column so that there is no question of order.
2013-08-11 09:20:16 -04:00
Bruce Momjian
f738156f51 docs: mention Julian is midnight _UTC_
(Yes, there was no UTC back then, but we compute it that way.)
Backpatch to 9.3.
2013-08-09 21:46:13 -04:00
Bruce Momjian
72039b1d8d Docs: Document to_*() Julian values are integers
Backpatch to 9.3.
Per request from Marc Dahn
2013-08-09 19:25:51 -04:00
Fujii Masao
0e65755c08 Document how auto_explain.log_timing can be changed. 2013-08-09 22:13:28 +09:00
Peter Eisentraut
072457b360 Message punctuation and pluralization fixes 2013-08-09 08:02:44 -04:00
Peter Eisentraut
9d775d8894 Message style improvements 2013-08-07 22:48:40 -04:00
Fujii Masao
91c3613d37 Fix assertion failure by an immediate shutdown.
In PM_WAIT_DEAD_END state, checkpointer process must be dead already.
But an immediate shutdown could make postmaster's state machine
transition to PM_WAIT_DEAD_END state even if checkpointer process is
still running,  and which caused assertion failure. This bug was introduced
in commit 457d6cf049.

This patch ensures that postmaster's state machine doesn't transition to
PM_WAIT_DEAD_END state in an immediate shutdown while checkpointer
process is running.
2013-08-08 02:48:53 +09:00
Bruce Momjian
f347f26807 pgtest: allow passing parameters, e.g. -s/--silent
Previously only -n was recognized.
2013-08-05 19:59:52 -04:00
Tom Lane
3ced8837db Simplify query_planner's API by having it return the top-level RelOptInfo.
Formerly, query_planner returned one or possibly two Paths for the topmost
join relation, so that grouping_planner didn't see the join RelOptInfo
(at least not directly; it didn't have any hesitation about examining
cheapest_path->parent, though).  However, correct selection of the Paths
involved a significant amount of coupling between query_planner and
grouping_planner, a problem which has gotten worse over time.  It seems
best to give up on this API choice and instead return the topmost
RelOptInfo explicitly.  Then grouping_planner can pull out the Paths it
wants from the rel's path list.  In this way we can remove all knowledge
of grouping behaviors from query_planner.

The only real benefit of the old way is that in the case of an empty
FROM clause, we never made any RelOptInfos at all, just a Path.  Now
we have to gin up a dummy RelOptInfo to represent the empty FROM clause.
That's not a very big deal though.

While at it, simplify query_planner's API a bit more by having the caller
set up root->tuple_fraction and root->limit_tuples, rather than passing
those values as separate parameters.  Since query_planner no longer does
anything with either value, requiring it to fill the PlannerInfo fields
seemed pretty arbitrary.

This patch just rearranges code; it doesn't (intentionally) change any
behaviors.  Followup patches will do more interesting things.
2013-08-05 15:01:09 -04:00
Kevin Grittner
841c29c8b3 Various cleanups for REFRESH MATERIALIZED VIEW CONCURRENTLY.
Open and lock each index before checking definition in RMVC.  The
ExclusiveLock on the related table is not viewed as sufficient to
ensure that no changes are made to the index definition, and
invalidation messages from other backends might have been missed.
Additionally, use RelationGetIndexExpressions() and check for NIL
rather than doing our own loop.

Protect against redefinition of tid and rowvar operators in RMVC.
While working on this, noticed that the fixes for bugs found during
the CF made the UPDATE statement useless, since no rows could
qualify for that treatment any more.  Ripping out code to support
the UPDATE statement simplified the operator cleanups.

Change slightly confusing local field name.

Use meaningful alias names on queries in refresh_by_match_merge().

Per concerns of raised by Andres Freund and comments and
suggestions from Noah Misch.  Some additional issues remain, which
will be addressed separately.
2013-08-05 09:57:56 -05:00
Tom Lane
221e92f64c Make sure float4in/float8in accept all standard spellings of "infinity".
The C99 and POSIX standards require strtod() to accept all these spellings
(case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity",
"-infinity".  However, pre-C99 systems might accept only some or none of
these, and apparently Windows still doesn't accept "inf".  To avoid
surprising cross-platform behavioral differences, manually check for each
of these spellings if strtod() fails.  We were previously handling just
"infinity" and "-infinity" that way, but since C99 is most of the world
now, it seems likely that applications are expecting all these spellings
to work.

Per bug #8355 from Basil Peace.  It turns out this fix won't actually
resolve his problem, because Python isn't being this careful; but that
doesn't mean we shouldn't be.
2013-08-03 12:40:27 -04:00
Alvaro Herrera
706f9dd914 Fix old visibility bug in HeapTupleSatisfiesDirty
If a tuple is locked but not updated by a concurrent transaction,
HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,
causing callers to wait on it, when it is not necessary (in fact, if the
other transaction had used a multixact instead of a plain Xid to mark
the tuple, HeapTupleSatisfiesDirty would have behave differently and
*not* returned the Xmax).

This bug was introduced in commit 3f7fbf85dc, dated December 1998,
so it's almost 15 years old now.  However, it's hard to see this
misbehave, because before we had NOWAIT the only consequence of this is
that transactions would wait for slightly more time than necessary; so
it's not surprising that this hasn't been reported yet.

Craig Ringer and Andres Freund
2013-08-02 17:02:36 -04:00
Alvaro Herrera
88c556680c Fix crash in error report of invalid tuple lock
My tweak of these error messages in commit c359a1b082 contained the
thinko that a query would always have rowMarks set for a query
containing a locking clause.  Not so: when declaring a cursor, for
instance, rowMarks isn't set at the point we're checking, so we'd be
dereferencing a NULL pointer.

The fix is to pass the lock strength to the function raising the error,
instead of trying to reverse-engineer it.  The result not only is more
robust, but it also seems cleaner overall.

Per report from Robert Haas.
2013-08-02 13:18:37 -04:00
Robert Haas
05ee328d66 Fix typo in comment.
Etsuro Fujita
2013-08-02 09:15:42 -04:00