| Age | Commit message (Collapse) | Author |
|---|
|
As mentioned in 3a64cfdde3, some of the output differences (compared
to PostgreSQL 10) may be caused by XL advancing cmin more often, for
example due to splitting a single command into multiple steps.
So tweak the expected output using output from Postgres-XL 9.5r1.6.
|
|
Commit 1d14325822 randomized the choice of a starting node with
ROUNDROBIN distribution, so that the data in combocid tests are not
all placed on the first node but distributed randomly (despite using
single-row INSERTS as before).
So to stabilize the test, make the table replicated. The table only
has a single column and the test updates is, so we can't use any
other stable distribution (e.g. BY HASH).
The expected results were obtained by running the combocid.sql on
PostgreSQL 10, so there might be some cmin differences.
|
|
Commit e26a0e07d8 started ignoring distributions defined on partitions,
but omitted this place in 'rules' when accepting the warnings.
|
|
On stock PostgreSQL, CREATE INDEX also updates statistics in pg_class
(relpages and reltuples). But Postgres-XL does not do that, which may
result in plan differences when the test relies on this behavior.
This is the same issue as in cfb055553687c257dd1d1ed123356c892f48a804,
but affecting inherit regression tests. So fix it in the same way, by
doing an explicit vacuum on the tables.
|
|
The accepted plan changes seem correct, as the only difference with
respect to upstream plans is Limit distribution. The commit diff is
a bit more complicated, because the expected plan did not reflect
the switch from Result to ProjectSet.
|
|
The plan change is expected, as it simply expands
-> Limit
to
-> Limit
-> Remote Subquery Scan
-> Limit
It wasn't accepted before probably because it was hidden by other
failures in the test suite.
|
|
When checking if a query is eligible for FQS (fast-query shipping),
disable the optimization for queries in SCROLL cursors, as FQS does
not support backward scans.
Discussion: <[email protected]>
|
|
When adding standby nodes using pgxc_ctl, it's calling pg_basebackup
internally. But the "-x" option was removed in PostgreSQL 10, so the
call is failing.
A straightforward fix would be to use "-X fetch" which does exactly
what "-x" used to do. But I've decided to use "-X stream" instead,
as that does not rely on wal_keep_segments.
Reported by Tank.zhang"<[email protected]>, along with "-X fetch" fix.
|
|
The ATTACH PARTITION command was failing due to mismatching column
order. That in turn caused failure in sanity_check, as the table
was not dropped when dropping the parent.
|
|
The expected output did not match, likely due to some confusion when
merging upstream changes (where the query does not include the ORDER
BY clause).
The updated output matches exactly to what is produced by upstream
after adding the ORDER BY clause.
|
|
Our efforts to improve shared queue synchronization continues. We now have a
per queue producer lwlock that must be held for synchronization between
consumers and the producer. Consumers must hold this lock before setting the
producer latch to ensure the producer does not miss out any signals and does
not go into unnecessary waits.
We still can't get rid of all the timeouts, especially we see that sometimes a
producer finishes and tries to unbind from the queue, even before a consumer
gets chance to connect to the queue. We left the 10s wait to allow consumers to
connect. There is still net improvement because when the consumer is not going
to connect, it tells the producer and we avoid the 10s timeout, like we used to
see earlier.
|
|
We had an issue with tracking knownXids on the standby and it was overflowing
the allocated array in the shared memory. It turned out that the primary reason
for this is that the GTM leaves behind a hole in XID allocation when it's
restarted. The standby oblivious to this, was complaining about array overflow
and thus die.
We now fix this by allocating array which can hold CONTROL_INTERVAL worth
additional XIDs. This would mostly be a waste because the XIDs are never
allocated. But this seems like a quick fix to further test the Hot standby. The
good thing is that we might just waste memory, but not have any impact on the
performance because of larger array since we only loop for numKnownXids which
will be more accurate.
With this change, also fix the defaults for datanode and coordinator standbys
and make them Hot Standbys. The wal_level is changed too.
|
|
When communicating with other nodes, we send names of objects instead
of OIDs as those are assigned on each node independently. We failed to
do this for Aggref->aggargtypes, which worked fine for built-in data
types (those have the same OID on all nodes), but resulted in failures
for custom data types (like for example FIXEDDECIMAL).
ERROR: cache lookup failed for type 16731
This fixes it by implementing READ/WRITE_TYPID_LIST_FIELD, similarly
to what we had for RELID.
Note: Turns out the WRITE_RELID_LIST_FIELD was broken, but apparently
we never call it in XL as it's only used for arbiterIndexes field. So
fix that too, in case we enable the feature in the future.
|
|
Rules are converted in their string representation and stored in the catalog.
While building relation descriptor, this information is read back and converted
into a Node representation. Since relation descriptors could be built when we
are reading plan information sent by the remote server in a stringified
representation, trying to read the rules with portable input on may lead to
unpleasant behaviour. So we must first reset portable input and restore it back
after reading the rules. The same applies to RLS policies (even though we don't
have a test showing the impact, but it looks like a sane thing to fix anyways)
|
|
Commit f7d1d581c950191a465b8483173f2ad69ae8fffe converted a couple of
sequences to persistent (instead of temporary), but failed to update
the expected output.
|
|
Commit 04f96689945462a4212047f03eb3281fb56bcf2f incorrectly allowed
distributed grouping paths for grouping sets, causing failures in
'groupingsets' regression test suite. So fix that by making sure
try_distributed_aggregation=false for plans with grouping sets.
|
|
We now create views/materialised views on all nodes, unless they are temporary
objects in which case they are created only on the local coordinator and the
datanodes. Similarly, temporary sequences are created on the local coordinator
and the datanodes.
This solves many outstanding problems in the regression results where remote
nodes used to fail because of non-existent type for a view or similar such
issues. A few other test cases now started to work correctly and produce output
matching upstream PG. So the expected output for those test cases has been
appropriated fixed.
Couple of sequences in the rangefuncs test case have been converted into
permanent sequences because the subsequent SQL functions refer to them and
hence fail if they do not exist on the remote coordinators.
The problem with special RULE converting a regular table into a view goes away
with the fix since DROP VIEW commands are now propgataed to the datanodes too.
|
|
Furthre more simplification and consolidation of the code.
|
|
|
|
|
|
|
|
|
|
Trivial plan changes and missing bits (likely due to incorrect merge
or something like that).
|
|
Trivial changes due to distributing the queries.
|
|
Add explicit ORDER BY clause to stabilize ordering of test results.
|
|
Postgres-XL does not support FWD object, so the tests were failing
with "does not exist" errors, instead of testing that visibility on
FDW objects is not supported. So just remove the few test queries.
|
|
Postgres-XL does not support FWD object, so the tests were failing
with "does not exist" errors, instead of testing that visibility on
FDW objects is not supported. So just remove the few test queries.
|
|
Add explicit ORDER BY clause to stabilize ordering of results for
a few tests. Accept a simple plan change, distributing a LIMIT query.
|
|
The changes are fairly simple and generally expected due to distributing
upstream queries, so adding either Remote Fast Query Execution or Remote
Subquery Scan nodes.
An explicit ORDER BY was added to a few queries to stabilize the output.
|
|
The upstream plan changes due to distributing to multiple nodes.
|
|
The changes are fairly simple and generally expected due to distributing
upstream queries, so adding either Remote Fast Query Execution or Remote
Subquery Scan nodes.
|
|
Commit 665c224a6b2afa disabled CREATE PUBLICATION/SUBSCRIPTION, but
it was still possible to create a logical replication slot and call
pg_logical_slot_get_changes() on it.
That would however crash and burn as ReorderBufferCommit() relies on
subtransactions, and BeginInternalSubTransaction() is not expected
to fail, leading to segfaults in the PG_CATCH block.
Simply disallowing creating logical slots (and whatever else relies
on CheckLogicalDecodingRequirements) seems like the best fix.
|
|
The actual result matches with the upstream result. The diffs must have been
caused by incorrect merge. So accept those fully.
|
|
Some database objects are created only on a subset of nodes. For example, views
are created only on the coordinators. Similarly, temp tables are created on the
local coordinator and all datanodes. So we must consult the relation kind
before executing the CREATE STATISTICS command on the remote nodes. Otherwise
we might try to execute it on a node where the underlying object is missing,
resulting in errors.
Patch by senhu ([email protected]) which was later reworked by me.
|
|
The first diff was in fact a mistake and the actual output matched with the
upstream output. It must have been missed during the merge process. The other
diff was simply an error because XL doesn't allow updating distribution key
column.
|
|
There were two broad categories of problems.
1. Errors due to lack of savepoint support
2. Errors and side effects due to lack of trigger support.
For 1, we reorganised the test case so that they can be run without savepoint.
For 2, we mostly accepted the regression changes. Apart from usual errors while
creating/dropping triggers, there were differences in query results because
of changes to preceding update/insert/delete statements. The behaviour of those
statements change because of lack of triggers.
|
|
Because of XL's strict requirement on column ordering and positioning, change
the test case to avoid DROP COLUMN commands. This kinda makes the test case
useless because the sole purpose of the test was to test if things stand up
well when there is a mismatch in column numbering. Given the current
restriction, there is no other option to make these changes.
|
|
A dummy append node with no subpaths doesn't need any adjustment for
distribution. This allows us to actually correct handle UPDATE/DELETE in some
cases which were failing earlier.
|
|
- Some problems related to inherited tables fixed by ensuring column ordering.
- ORDER BY clauses added at some other places to ensure consistent row ordering.
- Changes related to TABLESAMPLE accepted as XL returns more rows than PG
- SAVEPOINTs removed and replaced by transaction blocks as XL does not support
subtransaction
- NOTICEs are not displayed in XL
- Append is pushed down to the remote node now that we impose stricter
restrictions on inheritance
|
|
As the table has just a single float8 column, XL automatically picks
ROUNDROBIN distribution. Commit 1d14325822 randomized selection of the
initial node, which with single-row inserts (used by the float8 tests)
effectively means random distribution, while before that all the rows
would be routed to the first node.
Some of the tests in float8 test suite seem to be sensitive to this, in
particular this overflow test:
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f ORDER BY f1;
ERROR: value out of range: overflow
One of the rows (containing 1.2345678901234e-200) triggers an underflow,
so when the database hits it first, it will report this error instead:
ERROR: value out of range: underflow
The probability of hitting this is however fairly low (less than 10%),
as the executor has to touch the underflowing value first.
|
|
Remove a SAVEPOINT statement, which otherwise fails. Once that is removed, a
few other test cases work fine and the associated expected output changes are
accepted.
|
|
It was a simple case of change in row ordering because the test case is
requesting order by column 'a', but the expected output had order by column 'c'
|
|
It's just an addition of a Remote Subquery Scan node on top of the regular
plan.
|
|
We don't support subtransactions and hence can't handle exception thrown by
trying to set invalid value. We'd already removed the exception, but the
transaction was being left in an aborted state. So fix this.
The test case still fails for some other reason which should be investigated
separately.
|
|
These changes were lost when we removed alternate expected output files for the
test case. So these are not new differences and the same ordering is exhibited
in XL9.5 as well.
NOTICEs are not shown by XL so accept those differences.
|
|
Accept some diffs which look sane and in-line with the upstream errors. Also
comment out a few tests which explictly test subtransactions, something we
don't currently support.
|
|
We don't support BACKWARD scan of RemoteSubplan and neither support WHERE
CURRENT OF. So accept the resulting errors.
|
|
We don't support BACKWARD scan of RemoteSubplan and neither support WHERE
CURRENT OF. So accept errors arising out of these limitations. These test case
changes are new in XL10 and hence we did not see these failures in the earlier
releases of XL.
|
|
SAVEPOINTs were used, which we don't support. So commented those out (along
with ROLLBACK calls). That does have an impact on the test case though because
at least in one place we were checking if the cmin goes back to 0 after rolling
back to a savepoint. But there is not much we can do about that until we add
SAVEPOINT support. Other changes include accepting diffs because of ctid
changes as rows come from different nodes and hence ctids are
duplicated/changed.
|
|
We do not support trigger and hence the regression differences.
|
