Autovacuum process cancels itself if any modification starts
on the table in order to avoid blocking your regular Postgres
sessions. That's normal and expected. Thus, any locks held by
autovacuum process cannot involve in a distributed deadlock
since it'll be released if needed.
These locks are held for a very short duration time and cannot
contribute to a deadlock. Speculative locks are used by Postgres
for internal notification mechanism among transactions.
While attaching a partition to a distributed table in schema, we mistakenly
used unqualified name to find partitioned table's oid. This caused problems
while using partitioned tables with schemas. We are fixing this issue in
this PR.
Short-term share/exclusive page-level locks are used for
read/write access. Locks are released immediately after
each index row is fetched or inserted.
Since those locks may not lead to any deadlocks, it's safe
to ignore them in the distributed deadlock detection.
In DistributedTablesSize() we didn't close the relations that had
replication factor > 2. This caused relcache reference leaks, and
warning messages like following in logs:
WARNING: relcache reference leak: relation "researchers" not closed
It's possible to build INSERT SELECT queries which include implicit
casts, currently we attempt to support these by adding explicit casts to
the SELECT query, but this sometimes crashes because we don't update all
nodes with the new types. (SortClauses, for instance)
This commit removes those explicit casts and passes an unmodified SELECT
query to the COPY executor (how we implement INSERT SELECT under the
scenes). In lieu of those cases, COPY has been given some extra logic to
inspect queries, notice that the types don't line up with the table it's
supposed to be inserting into, and "manually" casting every tuple before
sending them to workers.
Previously we compiled PostgreSQL for PR and we used already compiled
PostgreSQL packages for push builds. Compiling PostgreSQL allows us to
run isolation/vanilla tests. Thus we only ran those tests for PR builds.
We did not used compiled PostgreSQL for both builds because;
- We wanted to run our tests against packages
- Compiling takes too much time.
However, there are some benefits in using custom compiled PostgreSQL
in push builds instead of PR builds such as;
- At the moment, we do not run isolation/vanilla tests until we open a
PR, which does not make any sense.
- After merging a PR (i.e. after push to the master) push builds run
and we do not run isolation tests.
- While merging community to enterprise, we have to open a temporary
PR to make travis run isolation/vanilla tests.
- With this change master branch will have its own cache that means
every branch originated from master branch can re-use master branch's
cache. (Currently we cannot use cache for the first PR build)
With this PR we switch from using custom compiled for PR builds to push
builds.
ShardPlacementList's implementation can return NIL. In previous implementation
we got a segmentation fault in this case. The relation can be dropped after
getting distributed table list but before calling SingleReplicatedTable().
If we don't propagate the errors we are catching in PG_CATCH(), database's
internal state might not be clean. So we do PG_TRY() inside a subtransaction
so we can rollback to it after catching errors.
This patch adds --with-reports-host configure option, which sets the
REPORTS_BASE_URL constant. The default is reports.citusdata.com.
It also enables stats collection in tests.
Mehmet Furkan ŞAHİN
mehmet furkan şahin
Önder Kalacı
Marco Slot
Marco Slot
Brian Cloutier
Burak Velioglu
velioglu
Metin Döşlü
metdos
Burak Yücesoy
Murat Tuncer
Hadi Moshayedi