| Age | Commit message (Collapse) | Author |
|---|
|
Masahiko Sawada
Discussion: https://www.postgresql.org/message-id/CAD21AoBCwcTNMdrVWq8T0hoOs2mWSYq9PRJ_fr6SH8HdO+m=0g@mail.gmail.com
|
|
As reported by Arthur Zakirov, Gcc 7.1 complained about this with
-Wpointer-compare.
Discussion: https://www.postgresql.org/message-id/CAKNkYnybV_NFVacGbW=VspzAo3TwRJFNi+9iBob66YqQMZopwg@mail.gmail.com
|
|
Commit c46c0e5202e8cfe750c6629db7852fdb15d528f3 failed to pass the
TransitionCaptureState object to ExecARInsertTriggers() in the case
where it's using heap_multi_insert and there are indexes. Repair.
Thomas Munro, from a report by David Fetter
Discussion: https://postgr.es/m/20170708084213.GA14720%40fetter.org
|
|
Also fix two other issues, while we're at it:
* In error message on connection failure, if multiple network addresses
were given as the host option, as in "host=127.0.0.1,127.0.0.2", the
error message printed the address twice.
* If there were many more ports than hostnames, the error message would
always claim that there was one port too many, even if there was more than
one. For example, if you gave 2 hostnames and 5 ports, the error message
claimed that you gave 2 hostnames and 3 ports.
Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
|
|
Commit e9c81b601 changed this, but missed updating the documentation.
The adjacent claim that we use TAP tests only in src/bin seems pretty
obsolete as well. Minor other copy-editing.
|
|
Original wording had confusingly vague antecedent for "they", so replace
that with a more repetitive but clearer formulation. In passing, make the
link to the installation requirements section more specific. Per gripe
from Martin Mai, though this is not the fix he initially proposed.
Discussion: https://postgr.es/m/CAN_NWRu-cWuNaiXUjV3m4H-riWURuPW=j21bSaLADs6rjjzXgQ@mail.gmail.com
|
|
Improve many item descriptions, improve markup, relocate some items
that seemed to be in the wrong section.
|
|
The optimizer was not generating correct distributed paths with Gather
Merge nodes, because those nodes always looked as if the data was not
distributed at all. There were two bugs causing this:
1) Gather Merge did not copy distribution from the subpath, leaving it
NULL (as if running on coordinator), so no Remote Subquery needed.
2) create_grouping_paths() did not check if a Remote Subquery is needed
on top of Gather Merge anyway.
After fixing these two issues, we're now generating correct plans (at
least judging by select_parallel regression suite).
|
|
All the accepted plan changes are simply adding Remote Subquery, and
seem correct and reasonable. Where possible, I've verified that the
older XL versions produce the same (or very similar) plan.
There are also three additional minor fixes:
1) An extra EXPLAIN query, as EXPLAIN ANALYZE hides the part below
Remote Subquery, making it mostly useless. The extra EXPLAIN
shows the whole plan and addresses this.
2) Postgres-XL does not support subtransactions, so the block setting
effective_io_concurrency was failing, and aborting the surrounding
transaction. Removing the EXCEPTION clause may cause issues on
systems not supporting this GUC, but that should be rare.
3) Removed a section of expected output, matching a block removed
from the SQL script.
|
|
|
|
Thinko in commit a892234f8.
Vik Fearing
Discussion: https://postgr.es/m/b6aaa23d-e26f-6404-a30d-e89431492d5d@2ndquadrant.com
|
|
The misc_sanity test checks for catalogs containing no pinned objects
after initdb. As pgxc_node is empty at that point (as expected), it got
caught by the new regression test. So add it to expected output.
|
|
Should have been part of the previous commit removing storm_catalog, but
I forgot to include this bit.
|
|
The storm_catalog schema is supposed to contain the same catalogs and
views as pg_catalog, but filtered to the current database. The use case
for this is multi-tenant systems, which was a StormDB feature.
But on XL this is mostly irrelevant, and the schema was not populated
since commit 8096e3edf17b260de15472eb04567d1beec1e3e6 which disabled
this part of initdb.
So instead of fixing the regression failures in misc_sanity caused by
this (initdb-time schema with no pinned objects), just rip all the
remaining bits out, including the pgxc_catalog_remap GUC etc.
This also removes the setup_storm() call disabled by 8096e3edf1, as the
function got removed since then.
|
|
The line number was incorrect for some reason. Should be 24 and not 23.
|
|
The last query in the test was not really doing anything as it failed
on the first object unsupported by Postgres-XL. So remove all such
unsupported objects, to make it work again.
|
|
The regression test was clearly missing a block of expected output,
likely due to a mistake during initial merge conflict resolution.
|
|
As the in-core logical replication is based on decoding WAL, there's no
easy way to support it on Postgres-XL as the WAL is spread over many
nodes. We essentially forward the actions to coordinators/datanodes,
and each of them has it's own local WAL. Reconstructing the global WAL
(which is needed for publications) would be challenging (e.g. because
replicated tables have data on all nodes), and it's certainly not
something we want to do during stabilization phase.
Supporting subscriptions would be challenging to, although for different
reasons (multiple subscriptions vs. multiple coordinators).
So instead just disable the CREATE PUBLICATION / SUBSCRIPTION commands,
just like we do for other unsupported features (e.g. triggers).
|
|
It generates an empty file, so libpq.dll advertises no version
information. Commit facde2a98f0b5f7689b4e30a9e7376e926e733b8
mistranslated "print O;" in this one place.
|
|
On platforms lacking both locale_t and ICU, collationcmds.c failed
to make any use of its static function is_all_ascii(), thus probably
drawing a compiler warning. Oversight in my commit ddb5fdc06.
Per buildfarm member gaur.
|
|
Those are new plans in upstream, and the only that happened to them is
adding "Remote Fast Query Execution" to the top of the plan.
|
|
This commit only accepts trivial plan changes, caused either by unique
joins patch (which may turn semijoins into regular joins), or by adding
a Remote Subquery on top of a new upstream plan.
There are multiple plans that change in a more complicated way,
requiring a more thorough investigation.
|
|
The expected output for one of the queries contained an extra row, most
likely due to a mistake during merge conflict resolution. There were in
fact 8 rows, yet the expected query output said '(7 rows)'.
|
|
The accepted plan changes are trivial and exactly match upstream changes
mostly due to commits 215b43cdc8 and 92a43e4857.
I've not accepted changes in the two UPDATE plans at the very end, as
those are more complicated and require more thorough investigation.
|
|
The accepted plans are actually new in the upstream, testing planning on
partitioned tables. The changes are just adding "Remote Subquery" node
at the top, to distribute the query to all datanodes.
The plans look reasonable and correct in general, but as a sanity check
I've also reproduced them on XL 9.5 using plain inheritance (because
partitioning is new in PostgreSQL 10). Naturally there are differences
)e.g. with partitioning the planner includes only leaf partitions in
the plan, while with inheritance we include the whole inheritance tree)
but otherwise the plans seem to be close enough.
|
|
Noticed while reviewing code.
|
|
The expected output of 'inherit' regression test was missing a whole
block of code, likely due to incorrect resolution of merge conflict.
Add the missing piece, copied from upstream.
|
|
Same issue as in c2392efc83, but in different regression test. Fixed the
same way, i.e. by adding ORDER BY clauses to stabilize the order.
|
|
Same issue as in c2392efc83, but in different regression test. Fixed the
same way, i.e. by adding ORDER BY clauses to stabilize the order.
|
|
The tests were relying on ordering of rows implied by storage, but that
does not work in multi-node clusters. Fixed by adding ORDER BY clauses
stabilizing the order, and updating the expected results.
|
|
Author: Masahiko Sawada <sawada.mshk@gmail.com>
|
|
get_object_address() expects the second parameter to be (Node *) but
we've been passing (List *), so that compilers were complaining. Just
change the type to fix this.
|
|
Multiple switch statements on oclass values are intentionally missing
the default clause. As the PGXC oclass options were missing, compilers
were complaining about it.
|
|
Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and
it cleans all bits in t_infomask heap tuple field.
Backpatch to 9.3
|
|
partition_rbound_cmp() is intended to compare range partition bounds
in a way such that if all the bound values are equal but one is an
upper bound and one is a lower bound, the upper bound is treated as
smaller than the lower bound. This particular ordering is required by
RelationBuildPartitionDesc() when building the PartitionBoundInfoData,
so that it can consistently keep only the upper bounds when upper and
lower bounds coincide.
Update the function comment to make that clearer.
Also, fix a (currently unreachable) corner-case bug -- if the bound
values coincide and they contain unbounded values, fall through to the
lower-vs-upper comparison code, rather than immediately returning
0. Currently it is not possible to define coincident upper and lower
bounds containing unbounded columns, but that may change in the
future, so code defensively.
Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
|
|
The previous logic, whilst not actually wrong, was overly complex and
involved doing two binary searches, where only one was really
necessary. This simplifies that logic and improves the comments.
One visible change is that if the new partition overlaps multiple
existing partitions, the error message now always reports the overlap
with the first existing partition (the one with the lowest
bounds). The old code would sometimes report the clash with the first
partition and sometimes with the last one.
Original patch idea from Amit Langote, substantially rewritten by me.
Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
|
|
Buildfarm members hornet and sungazer have shown multiple instances of
"Failed test 'xmin of non-cascaded slot with hs feedback has changed'".
The reason seems to be that the test is checking the current xmin of the
master server's replication slot against a past xmin of the first slave
server's replication slot. Even though the latter slot is downstream of
the former, it's possible for its reported xmin to be ahead of the former's
reported xmin, because those numbers are updated whenever the respective
downstream walreceiver feels like it (see logic in WalReceiverMain).
Instrumenting this test shows that indeed the slave slot's xmin does often
advance before the master's does, especially if an autovacuum transaction
manages to occur during the relevant window. If we happen to capture such
an advanced xmin as $xmin, then the subsequent wait_slot_xmins call can
fall through before the master's xmin has advanced at all, and then if it
advances before the get_slot_xmins call, we can get the observed failure.
Yeah, that's a bit of a long chain of deduction, but it's hard to explain
any other way how the test can get past an "xmin <> '$xmin'" check only
to have the next query find that xmin does equal $xmin.
Fix by keeping separate images of the master and slave slots' xmins
and testing their has-xmin-advanced conditions independently.
|
|
There were three simple issues:
1) missing headers, so shmem-related functions were not defined
2) using LWLockId instead of plain LWLock
3) missing ProcessUtility changes from commit ab1f0c8225714aaa18d
This commit fixes all of those compile-time issues.
|
|
Commit 9daec77e165de461fca9d5bc3ece86a91aba5804 simplified usage of
simple_prompt, so that it's not necessary to free the string etc.
This applies the call chage to pgxc_ctl.
|
|
Commit 1ae853654 missed this. Per Andrew Dunstan.
|
|
Since pg_ctl promote already waits for recovery to end, these calls are
obsolete.
|
|
If an operation being waited for does not complete within the timeout,
then exit with a nonzero exit status. This was previously handled
inconsistently.
|
|
WRITE_CHAR_FIELD() didn't do any escaping, so that for example a zero
byte would cause the whole output string to be truncated. To fix, pass
the char through outToken(), so it is escaped like a string. Adjust the
reading side to handle this.
|
|
Update the documentation for \pset to mention
columns|linestyle|pager_min_lines. Add various mentions of \pset
command equivalences that were previously inconsistent.
Author: Дилян Палаузов <dpa-postgres@aegee.org>
|
|
Reported-by: Константин Евтеев <konst583@gmail.com>
Bug: #14699
|
|
This avoids "tuple concurrently updated" errors when a ALTER or DROP
SUBSCRIPTION writes to pg_subscription_rel at the same time as a worker.
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>
|
|
Author: Michael Paquier <michael.paquier@gmail.com>
|
|
If the client closes an SSL connection, treat it the same as EOF on a
non-SSL connection. In particular, don't write a message in the log about
that.
Michael Paquier.
Discussion: https://www.postgresql.org/message-id/CAB7nPqSfyVV42Q2acFo%3DvrvF2gxoZAMJLAPq3S3KkjhZAYi7aw@mail.gmail.com
|
|
Previously, gen_random_uuid() would fall back to a weak random number
generator, unlike gen_random_bytes() which would just fail. And this was
not made very clear in the docs. For consistency, also make
gen_random_uuid() fail outright, if compiled with --disable-strong-random.
Re-word the error message you get with --disable-strong-random. It is also
used by pgp functions that require random salts, and now also
gen_random_uuid().
Reported by Radek Slupik.
Discussion: https://www.postgresql.org/message-id/20170101232054.10135.50528@wrigleys.postgresql.org
|
|
Since reducing pg_ctl's reaction time in commit c61559ec3, some
slower buildfarm members have shown erratic failures in this test.
The reason turns out to be that the test assumes synchronous
replication (because it does not provide any lag time for a commit
to replicate before shutting down the servers), but it had only
enabled sync rep in one direction. The observed symptoms correspond
to failure to replicate the last committed transaction in the other
direction, which can be expected to happen if the shutdown command
is issued soon enough and we are providing no synchronous-commit
guarantees.
Fix that, and add a bit more paranoid state checking at the bottom
of the script.
Michael Paquier and myself
Discussion: https://postgr.es/m/908.1498965681@sss.pgh.pa.us
|
