Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling system tables errors #327

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

chanukya571
Copy link

added a function check_systemtables() which will check whether its a system table or not.

if its a system table it will throw a meaningful error to use VACUUM FULL.

Melkij and others added 17 commits November 28, 2019 10:41
Conflict changes was:
new argument for RenameRelationInternal (,,,is_index)
heap_open/heap_closewas moved to access/table.h (well, this is macro now, but I did not change callers code)
…s removed from pg_class, so create separate get_relhasoids C function
…ACE pg_default" sentence

Due late april postgresql commit 87259588d0ab0b8e742e30596afa7ae25caadb18
Try to get the lock in loop with timeouts using `lock_exclusive()`.
This allows to not stuck lock queue for readers if pg_repack
cannot take the lock fast enough.
It is better to raise ERROR message if lock_exclusive() failed during
calling repack.repack_drop() otherwise a user might not notice that
pg_repack didn't clean up leftovers.
* simple_prompt signature was changed

* Use SearchSysCacheCopy1 macro instead of SearchSysCacheCopy direct call as more future-proof

Per syscache.h:
> The use of the macros below rather than direct calls to the corresponding
> functions is encouraged, as it insulates the caller from changes in the
> maximum number of keys.

Also this fixes segfault on pg14, but still not sure why exactly.

* Get rid the custom array_accum aggregate in favor of postgresql's built-in array_agg and string_agg.

In postgresql 14, the signature of array_append was changed, and our create aggregate throws the error "function array_append(anyarray, anyelement) does not exist". Postgresql's built-in string_agg was introduced in postgresql 9.0, array_agg was from 8.4 release. Both are too old and no longer supported by pg_repack. So, instead of fixing the repack.array_accum, I want to drop it.
One notable behavior difference is handling empty sets: array_agg will produce NULL. So I put several coalesce to avoid altering the query results.

* Check for the existence of the tables specified by --table or --parent-table

PostgreSQL 14 will produce something like
 ERROR: pg_repack failed with error: ERROR:  relation "dummy_table" does not exist
 CONTEXT:  unnamed portal parameter $2 = '...'
The second line looks weird and breaks tests. The second word "ERROR" also looks strange. So an explicit check for the existence of a table has been added.

* Prepare release 1.4.7

First sketch to see what buildfarm thinks. Also recheck PGVER=9.6 build

* ubuntu xenial is EOL, try focal 20.04 LTS

* third party apt-repositories removed from the Bionic build image. Next try
https://docs.travis-ci.com/user/reference/bionic/#third-party-apt-repositories-removed

* amd64 packages only, please

* apt repository section was changed?

* postgresql-14 beta1 should be already in repo, retry

* try a workaround for pg9.5, 9.6
Possible we decide to drop these versions, but just check

* missing build dependency by postgresql-server-dev lz4

* update docs broken links

* Remove connection info from error log

* remove unnecessary plus operator

* fix typo in pgut.c

* Fix typo

Fix typo

* Reassure the user that it's ok to drop the extension

See reorg#281

Co-authored-by: melkij <sk@zsrv.org>
Co-authored-by: Valeriya Popova <waleriya@yandex-team.ru>
Co-authored-by: Daniel Merken <daniel.merken@gmail.com>
Co-authored-by: lincuiping <57204139+lincuiping@users.noreply.github.com>
Co-authored-by: sunhm89 <93200340+sunhm89@users.noreply.github.com>
Co-authored-by: zhuqx-fnst <94515051+zhuqx-fnst@users.noreply.github.com>
Co-authored-by: Daniele Varrazzo <daniele.varrazzo@gmail.com>
@@ -1981,7 +2030,16 @@ repack_cleanup_callback(bool fatal, void *userdata)
* so just use an unconditional reconnect().
*/
reconnect(ERROR);

command("BEGIN ISOLATION LEVEL READ COMMITTED", 0, NULL);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you included non-relevant changes. Can you remove them?

@@ -2011,7 +2069,16 @@ repack_cleanup(bool fatal, const repack_table *table)
/* do cleanup */
params[0] = utoa(table->target_oid, buffer);
params[1] = utoa(temp_obj_num, num_buff);

command("BEGIN ISOLATION LEVEL READ COMMITTED", 0, NULL);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above. This looks like a non-relevant change.

@@ -487,6 +529,12 @@ preliminary_checks(char *errbuf, size_t errsize){
goto cleanup;
}

if (check_systemtables()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would make sense to make this check inside repack_one_table and repack_table_indexes only? That way this check won't interrupt pg_repack completely, and it will skip only system tables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants