– Resolve timing issue with logging locks for Hot Standby. We log
AccessExclusiveLocks for replay onto standby nodes, but because of
timing issues on ProcArray it is possible to log a lock that is
still held by a just committed transaction that is very soon to be
removed. To avoid any timing issue we avoid applying locks made by
transactions with InvalidXid. Simon Riggs, bug report Tom Lane,
diagnosis Pavan Deolaseehttp://git.postgresql.org/pg/commitdiff/c172b7b02e6f6008d6dad66ddee8f67faf223c5b

– Adjustments to regression tests for security_barrier views. Drop
the role we create, so regression tests pass even when run more than
once against the same cluster, a problem noted by Tom Lane and Jeff
Janes. Also, rename the temporary role so that it starts with
“regress_”, to make it unlikely that we’ll collide with an existing
role name while running “make installcheck”, per further gripe from
Tom Lane.http://git.postgresql.org/pg/commitdiff/49562f5eb66f31940dd7b64555bbd81bae952387

– Be more clear when a new column name collides with a system column
name. We now use the same error message for ALTER TABLE .. ADD
COLUMN or ALTER TABLE .. RENAME COLUMN that we do for CREATE TABLE.
The old message was accurate, but might be confusing to users not
aware of our system columns. Vik Reykja, with some changes by me,
and further proofreading by Tom Lanehttp://git.postgresql.org/pg/commitdiff/2d1371d3ee5cf7e96d16fb503c27e060df9497f7

– Adjust tuplesort.c based on the fact that we never use the OS’s
qsort(). Our own qsort_arg() implementation doesn’t have the defect
previously observed to affect only QNX 4, so it seems sufficiently
to assert that it isn’t broken rather than retesting. Also, update
a few comments to clarify why it’s valuable to retain a tie-break
rule based on CTID during index builds. Peter Geoghegan, with
slight tweaks by me.http://git.postgresql.org/pg/commitdiff/c5a03256c725c09c32a5c498bd7c8799ed3ec2a0

– Use parameterized paths to generate inner indexscans more flexibly.
This patch fixes the planner so that it can generate nestloop-with-
inner-indexscan plans even with one or more levels of joining
between the indexscan and the nestloop join that is supplying the
parameter. The executor was fixed to handle such cases some time
ago, but the planner was not ready. This should improve our plans
in many situations where join ordering restrictions formerly forced
complete table scans. There is probably a fair amount of tuning
work yet to be done, because of various heuristics that have been
added to limit the number of parameterized paths considered.
However, we are not going to find out what needs to be adjusted
until the code gets some real-world use, so it’s time to get it in
there where it can be tested easily. Note API change for index AM
amcostestimate functions. I’m not aware of any non-core index AMs,
but if there are any, they will need minor adjustments.http://git.postgresql.org/pg/commitdiff/e2fa76d80ba571d4de8992de6386536867250474

– Undo 8.4-era lobotomization of subquery pullup rules. After the
planner was fixed to convert some IN/EXISTS subqueries into
semijoins or antijoins, we had to prevent it from doing that in some
cases where the plans risked getting much worse. The reason the
plans got worse was that in the unoptimized implementation,
subqueries could reference parameters from the outer query at any
join level, and so full table scans could be avoided even if they
were one or more levels of join below where the semi/anti join would
be. Now that we have sufficient mechanism in the planner to handle
such cases properly, it should no longer be necessary to play dumb
here. This reverts commits 07b9936a0f10d746e5076239813a5e938f2f16be
and cd1f0d04bf06938c0ee5728fc8424d62bcf2eef3. The latter was a
stopgap fix that wasn’t really sufficiently analyzed at the time.
Rather than just restricting ourselves to cases where the new join
can be stacked on the right-hand input, we should also consider
whether it can be stacked on the left-hand input.http://git.postgresql.org/pg/commitdiff/0816fad6eebddb8f1f0e21635e46625815d690b9

– Fix handling of data-modifying CTE subplans in EvalPlanQual. We
can’t just skip initializing such subplans, because the referencing
CTE node will expect to find the subplan available when it
initializes. That in turn means that ExecInitModifyTable must allow
the case (which actually it needed to do anyway, since there’s no
guarantee that ModifyTable is exactly at the top of the CTE plan
tree). So move the complaint about not being allowed in
EvalPlanQual mode to execution instead of initialization. Testing
turned up yet another problem, which is that we’d try to
re-initialize the result relation’s index list, leading to leaks and
dangling pointers. Per report from Phil Sorber. Back-patch to 9.1
where data-modifying CTEs were introduced.http://git.postgresql.org/pg/commitdiff/7c1719bc68ec1c347e7c80c3735bf3373e765f35

– Add simple tests of EvalPlanQual using the isolationtester
infrastructure. Much more could be done here, but at least now we
have *some* automated test coverage of that mechanism. In
particular this tests the writable-CTE case reported by Phil Sorber.
In passing, remove isolationtester’s arbitrary restriction on the
number of steps in a permutation list. I used this so that a single
spec file could be used to run several related test scenarios, but
there are other possible reasons to want a step series that’s not
exactly a permutation. Improve documentation and fix a couple other
nits as well.http://git.postgresql.org/pg/commitdiff/759d9d67695783f6d04a85aba383a41c5382548c

– Fix handling of init_plans list in inheritance_planner(). Formerly
we passed an empty list to each per-child-table invocation of
grouping_planner, and then merged the results into the global list.
However, that fails if there’s a CTE attached to the statement,
because create_ctescan_plan uses the list to find the plan
referenced by a CTE reference; so it was unable to find any CTEs
attached to the outer UPDATE or DELETE. But there’s no real reason
not to use the same list throughout the process, and doing so is
simpler and faster anyway. Per report from Josh Berkus of “could
not find plan for CTE” failures. Back-patch to 9.1 where we added
support for WITH attached to UPDATE or DELETE. Add some regression
test cases, too.http://git.postgresql.org/pg/commitdiff/4ec6581c0cdddfda767641f535116ee9a0412149

– Fix pushing of index-expression qualifications through UNION ALL.
In commit 57664ed25e5dea117158a2e663c29e60b3546e1c, I made the
planner wrap non-simple-variable outputs of appendrel children (IOW,
child SELECTs of UNION ALL subqueries) inside PlaceHolderVars, in
order to solve some issues with EquivalenceClass processing.
However, this means that any upper-level WHERE clauses mentioning
such outputs will now contain PlaceHolderVars after they’re pushed
down into the appendrel child, and that prevents indxpath.c from
recognizing that they could be matched to index expressions. To
fix, add explicit stripping of PlaceHolderVars from index operands,
same as we have long done for RelabelType nodes. Add a regression
test covering both this and the plain-UNION case (which is a totally
different code path, but should also be able to do it). Per bug
#6416 from Matteo Beccati. Back-patch to 9.1, same as the previous
change.http://git.postgresql.org/pg/commitdiff/b28ffd0fcc583c1811e5295279e7d4366c3cae6c

– Tweak index costing for problems with partial indexes.
btcostestimate() makes an estimate of the number of index tuples
that will be visited based on knowledge of which index clauses can
actually bound the scan within nbtree. However, it forgot to
account for partial indexes in this calculation, with the result
that the cost of the index scan could be significantly overestimated
for a partial index. Fix that by merging the predicate with the
abbreviated indexclause list, in the same way as we do with the full
list to estimate how many heap tuples will be visited. Also,
slightly increase the “fudge factor” that’s meant to give preference
to smaller indexes over larger ones. While this is applied to all
indexes, it’s most important for partial indexes since it can be the
only factor that makes a partial index look cheaper than a similar
full index. Experimentation shows that the existing value is so
small as to easily get swamped by noise such as
page-boundary-roundoff behavior. I’m tempted to kick it up more
than this, but will refrain for now. Per report from Ruben Blanco.
These are long-standing issues, but given the lack of prior
complaints I’m not going to risk changing planner behavior in back
branches by back-patching.http://git.postgresql.org/pg/commitdiff/21a39de5809cd3050a37d2554323cc1d0cbeed9d

– Do not access indclass through Form_pg_index. Normally, accessing
variable-length members of catalog structures past the first one
doesn’t work at all. Here, it happened to work because indnatts was
checked to be 1, and so the defined FormData_pg_index layout, using
int2vector[1] and oidvector[1] for variable-length arrays, happened
to match the actual memory layout. But it’s a very fragile
assumption, and it’s not in a performance-critical path, so code it
properly using heap_getattr() instead. bug analysis by Tom Lanehttp://git.postgresql.org/pg/commitdiff/8a3f745f160d8334ad978676828d3926ac949f43

– Hide most variable-length fields from Form_pg_* structs. Those
fields only appear in the structs so that genbki.pl can create the
BKI bootstrap files for the catalogs. But they are not actually
usable from C. So hiding them can prevent coding mistakes, saves
stack space, and can help the compiler. In certain catalogs, the
first variable-length field has been kept visible after manual
inspection. These exceptions are noted in C comments. reviewed by
Tom Lanehttp://git.postgresql.org/pg/commitdiff/8137f2c32322c624e0431fac1621e8e9315202f9

– Show default privileges in information schema. Hitherto, the
information schema only showed explicitly granted privileges that
were visible in the *acl catalog columns. If no privileges had been
granted, the implicit privileges were not shown. To fix that, add
an SQL-accessible version of the acldefault() function, and use that
inside the aclexplode() calls to substitute the catalog-specific
default privilege set for null values. reviewed by Abhijit
Menon-Senhttp://git.postgresql.org/pg/commitdiff/b376ec6fa57bc76037014ede29498e2d1611968e

– Have \copy go through SendQuery. This enables a bunch of features,
notably ON_ERROR_ROLLBACK. It also makes COPY failure (either in
the server or psql) as a whole behave more sanely in psql.
Additionally, having more commands in the same command line as COPY
works better (though since psql splits lines at semicolons, this
doesn’t matter much unless you’re using -c). Also tighten a couple
of switches on PQresultStatus() to add PGRES_COPY_BOTH support and
stop assuming that unknown statuses received are errors; have those
print diagnostics where warranted. Author: Noah Mischhttp://git.postgresql.org/pg/commitdiff/08146775acd8bfe0fcc509c71857abb928697171

– Make bgwriter sleep longer when it has no work to do, to save
electricity. To make it wake up promptly when activity starts
again, backends nudge it by setting a latch in MarkBufferDirty().
The latch is kept set while bgwriter is active, so there is very
little overhead from that when the system is busy. It is only armed
before going into longer sleep. Peter Geoghegan, with some changes
by me.http://git.postgresql.org/pg/commitdiff/6d90eaaa89a007e0d365f49d6436f35d2392cfeb