These two options were not included when creating the sequences on the
workers as part of metadata syncing.
The missing `data_type` part of the definition made finding the cause
of #5126 harder than necessary, because of confusing errors.
Before this commit, we always synced the metadata with superuser.
However, that creates various edge cases such as visibility errors
or self distributed deadlocks or complicates user access checks.
Instead, with this commit, we use the current user to sync the metadata.
Note that, `start_metadata_sync_to_node` still requires super user
because accessing certain metadata (like pg_dist_node) always require
superuser (e.g., the current user should be a superuser).
However, metadata syncing operations regarding the distributed
tables can now be done with regular users, as long as the user
is the owner of the table. A table owner can still insert non-sense
metadata, however it'd only affect its own table. So, we cannot do
anything about that.
With this commit, we add (`CREATE INDEX` / `REINDEX`) `CONCURRENTLY` support for columnar tables.
For that, we implement `columnar_index_validate_scan` callback.
The reasoning behind the implementation is as follows:
* Postgres function `validate_index` provides all the TIDs that are currently in the
index to `columnar_index_validate_scan` callback via a `tupleSort` object..
* We start scanning the table by using `columnar_getnextslot` as usual.
Before moving forward, note that `columnar_getnextslot` guarantees
to return tuples in the order of their TIDs.
* For us to use during table scan, postgres provides a snapshot guaranteeing
that any tuples that are valid according to that snapshot but are not in the
index must be added to the index.
* Then for each tuple that we read from our table, we continue iterating
given `tupleSort` to find the first TID that is greater than or equal to our
tuple's TID.
If both TID's are equal to each other, then we skip the tuple since it's already
indexed.
If the TID that we read from tupleSort is greater then our tuple's TID, then
we decide to insert this tuple into index.
systable_getnext already uses ForwardScanDirection if relation has any
open indexes, but let's be more explicit doing ordered scan on columnar
catalog tables.
Remove stripeList (list of StripeMetadata) & currentStripe (stripeList index of the
current stripe being read) from ColumnarReadState, introduce currentStripeMetadata.
DESCRIPTION: Fixes an issue that could cause citus_finish_pg_upgrade to fail
Rewiring Citus upgrade scripts to fix the prepare/finish PG upgrade scripts.
Users who upgrade to the patch release of 9.4 will get the fix via 9.4-1--9.4-2.
Users who upgrade to the patch release of 9.5 will get the fix via 9.5-1--9.5-2.
Users who upgrade to the patch release of 10.0 will get the fix via 10.0-3--10.0-4.
Users who upgrade to Citus 10.1 will also get it as part of the 10.0-3--10.0-4 upgrade path.
Given that we use CREATE OR REPLACE, it's ok to get the fix multiple times.
Fixes#5068, but not #5069.
Jelte Fennema
Önder Kalacı
Onder Kalaci
Hanefi Onaldi
Onur Tirtir
Ahmet Gedemenli
Nils Dijk
Marco Slot