Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Comparing changes

Choose two branches to see what's changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
base fork: szymong/postgres
head fork: szymong/postgres
Checking mergeability… Don't worry, you can still create the pull request.
Commits on Aug 23, 2013
Tom Lane In locate_grouping_columns(), don't expect an exact match of Var typm…

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.
Commits on Aug 24, 2013
@mhagander mhagander 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
Tom Lane Account better for planning cost when choosing whether to use custom …

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.
Commits on Aug 26, 2013
Robert Haas doc: Explain that ereport doesn't return for ERROR or higher levels.
Christophe Pettus
Commits on Aug 27, 2013
@alvherre alvherre Fix some "translator:" comments mangled by pgindent
@alvherre alvherre Initialize cached OID to Invalid in new hash entries
Andres Freund; bug detected by valgrind
Commits on Aug 28, 2013
@hlinnaka hlinnaka Accept multiple -I, -P, -T and -n options in pg_restore.
We already did this for -t (--table) in 9.3, but missed the other similar
options. For consistency, allow all of them to be specified multiple times.

Unfortunately it's too late to sneak this into 9.3, so commit to master
Robert Haas Partially restore comments discussing enum renumbering hazards.
As noted by Tom Lane, commit 813fb03
was overly optimistic about how safe it is to concurrently change
enumsortorder values under MVCC catalog scan semantics.  Restore
some of the previous text, with hopefully-correct adjustments for
the new state of play.
Robert Haas Allow discovery of whether a dynamic background worker is running.
Using the infrastructure provided by this patch, it's possible either
to wait for the startup of a dynamically-registered background worker,
or to poll the status of such a worker without waiting.  In either
case, the current PID of the worker process can also be obtained.
As usual, worker_spi is updated to demonstrate the new functionality.

Patch by me.  Review by Andres Freund.
Commits on Aug 29, 2013
@hlinnaka hlinnaka Use a non-locking initial test in TAS_SPIN on x86_64.
Testing done in 2011 by Tom Lane concluded that this is a win on Intel Xeons
and AMD Opterons, but it was not changed back then, because of an old
comment in tas() that suggested that it's a huge loss on older Opterons.
However, didn't have separate TAS() and TAS_SPIN() macros back then, so the
comment referred to doing a non-locked initial test even on the first
access, in uncontended case. I don't have access to older Opterons, but I'm
pretty sure that doing an initial unlocked test is unlikely to be a loss
while spinning, even though it might be for the first access.

We probably should do the same on 32-bit x86, but I'm afraid of changing it
without any testing. Hence just add a note to the x86 implementation
suggesting that we probably should do the same there.
@alvherre alvherre Make error wording more consistent
Commits on Aug 30, 2013
Tom Lane Reset the binary heap in MergeAppend rescans.
Failing to do so can cause queries to return wrong data, error out or crash.
This requires adding a new binaryheap_reset() method to binaryheap.c,
but that probably should have been there anyway.

Per bug #8410 from Terje Elde.  Diagnosis and patch by Andres Freund.
Tom Lane Add test case for bug #8410.
Per Andres Freund.
Commits on Aug 31, 2013
Tom Lane Improve regression test for #8410.
The previous version of the query disregarded the result of the MergeAppend
instead of checking its results.

Andres Freund
Commits on Sep 01, 2013
Tom Lane Update 9.3 release notes.
Some corrections, a lot of copy-editing.

Set projected release date as 2013-09-09.
Tom Lane Update "Using EXPLAIN" documentation examples using current code.
It seems like a good idea to update these examples since some fairly
basic planner behaviors have changed in 9.3; notably that the startup cost
for an indexscan plan node is no longer invariably estimated at 0.00.
Commits on Sep 02, 2013
@petere petere Translation updates
@adunstan adunstan Fix relfrozenxid query in docs to include TOAST tables.
The original query ignored TOAST tables which could result in tables
needing a vacuum not being reported.

Backpatch to all live branches.
Tom Lane Update time zone data files to tzdata release 2013d.
DST law changes in Israel, Morocco, Palestine, Paraguay.
Historical corrections for Macquarie Island.
Commits on Sep 03, 2013
@hlinnaka hlinnaka Fix typo in comment.
Also line-wrap an over-wide line in a comment that's ignored by pgindent.
@gsstark gsstark Fix thinko in worker_spi, count(*) returns a bigint. Thanks RhodiumToad
Robert Haas docs: Clarify that we also support Solaris versions greater than 10.
@bmomjian bmomjian Docs: add paragraph about date/timestamp subtraction
per suggestion from Francisco Olart
@bmomjian bmomjian doc: Fix SGML markup for date patch
Tom Lane Docs: wording improvements in discussion of timestamp arithmetic.
I started out just to fix the broken markup in commit
1c20857, but got distracted by
copy-editing.  I see Bruce already fixed the markup, but I'll
commit the wordsmithing anyway.
@alvherre alvherre Update obsolete comment
Tom Lane Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.

It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg().  However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it.  So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.

In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation.  That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about.  Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another

initdb forced because of new aggvariadic field in Aggref parse nodes.
Tom Lane Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies…
… off.

The previous coding attempted to activate all the GUC settings specified
in SET clauses, so that the function validator could operate in the GUC
environment expected by the function body.  However, this is problematic
when restoring a dump, since the SET clauses might refer to database
objects that don't exist yet.  We already have the parameter
check_function_bodies that's meant to prevent forward references in
function definitions from breaking dumps, so let's change CREATE FUNCTION
to not install the SET values if check_function_bodies is off.

Authors of function validators were already advised not to make any
"context sensitive" checks when check_function_bodies is off, if indeed
they're checking anything at all in that mode.  But extend the
documentation to point out the GUC issue in particular.

(Note that we still check the SET clauses to some extent; the behavior
with !check_function_bodies is now approximately equivalent to what ALTER
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)

This problem can be demonstrated in all active branches, so back-patch
all the way.
Tom Lane Update comments concerning PGC_S_TEST.
This GUC context value was once only used by ALTER DATABASE SET and
ALTER USER SET.  That's not true anymore, though, so rewrite the
comments to be a bit more general.

Patch in HEAD only, since this is just an internal documentation issue.
Commits on Sep 04, 2013
Robert Haas Expose fsync_fname as a public API.
Andres Freund
@hlinnaka hlinnaka Keep heavily-contended fields in XLogCtlInsert on different cache lines.
Performance testing shows that if the insertpos_lck spinlock and the fields
that it protects are on the same cache line with other variables that are
frequently accessed, the false sharing can hurt performance a lot. Keep
them apart by adding some padding.
@bmomjian bmomjian Remove dead URL mention in OSX startup script
Backpatch to 9.3.

Per suggestion from Gavan Schneider
@bmomjian bmomjian Add GUC descriptions for compile-time postgresql.conf settings
Previous text was "No description available".

Tianyin Xu
Commits on Sep 05, 2013
Jeff Davis Improve Range Types and Exclusion Constraints example.
Make the examples self-contained to avoid confusion. Per bug report
8367 from KOIZUMI Satoru.
Jeff Davis Revert WAL posix_fallocate() patches.
This reverts commit 269e780
and commit 5b571bb.

Unfortunately, the initial patch had insufficient performance testing,
and resulted in a regression.

Per report by Thom Brown.
@hlinnaka hlinnaka Make catalog cache hash tables resizeable.
If the hash table backing a catalog cache becomes too full (fillfactor > 2),
enlarge it. A new buckets array, double the size of the old, is allocated,
and all entries in the old hash are moved to the right bucket in the new

This has two benefits. First, cache lookups don't get so expensive when
there are lots of entries in a cache, like if you access hundreds of
thousands of tables. Second, we can make the (initial) sizes of the caches
much smaller, which saves memory.

This patch dials down the initial sizes of the catcaches. The new sizes are
chosen so that a backend that only runs a few basic queries still won't need
to enlarge any of them.
@kgrittn kgrittn Eliminate pg_rewrite.ev_attr column and related dead code.
Commit 95ef6a3 removed the
ability to create rules on an individual column as of 7.3, but
left some residual code which has since been useless.  This cleans
up that dead code without any change in behavior other than
dropping the useless column from the catalog.