Comments (16)
@dvarrazzo @Melkij @za-arthur Do you have any insight into why this statement is in the documentation, or if it can be removed?
from pg_repack.
Since we don't support scripts for alter extension .. update
, I think this sentence is still appropriate.
from pg_repack.
Looked through the changes. Are there any fundamental incompatible changes which prevent an upgrade?
Or can the next upgrade start providing update scripts.
from pg_repack.
What would be use case for an update script? It could be necessary in case if pg_repack would create types or functions, on which other DB objects could depend on, or if pg_repack would create relations with data, which need to be preserved.
from pg_repack.
The update script doesn't have to do anything, if there is no changes in the data types or views or tables.
from pg_repack.
Only upgrade scripts? (some releases will be no-op because the sql interface rarely changed)
Or do you mean to relax the requirement that the versions of the loaded lib and the control program match?
I don't mind making support for alter extension .. update if we continue to require repack.version() check. Otherwise, support and somehow test with another version of the extension (SQL representation) or another version of the loadable module (with SQL representation from another version)... Many surprises without obvious benefit.
from pg_repack.
Or do you mean to relax the requirement that the versions of the loaded lib and the control program match?
No, that's a lot of work, and not necessary at all.
Just enabling upgrades, and not forcing a reinstall.
from pg_repack.
Ok, soons good.
I just realized that we won’t have empty scripts: we need to update CREATE FUNCTION repack.version_sql()
with each release, even if nothing has changed on the SQL side. Hm, maybe replace it by select extversion from pg_extension where extname=?
from pg_repack.
There were reasons, which now I don't remember, for which it was advisable to get the version from a version in the schema rather than from the extension metadata.
Making the extension upgradeable requires work because you need to provide an upgrade path, even if the diff is nil. If there is no change between 1.0.0 and 1.0.1 and a change in 1.0.2, you still need to provide a 1.0.0--1.0.1 file otherwise you can't go from 1.0.0 to 1.0.2.
pg_repack is a stateless extension and no object will depend on it. Dropping and re-creating it is the easiest way to upgrade it.
from pg_repack.
There were reasons, which now I don't remember, for which it was advisable to get the version from a version in the schema rather than from the extension metadata.
Well, one obvious-ish consideration is that we want to check if the sql is consistent with the c, and the extension version is neither of the two...
from pg_repack.
There were reasons, which now I don't remember, for which it was advisable to get the version from a version in the schema rather than from the extension metadata.
The main reason for version_sql(), I think, was that pg_extension and create extension
as such did not exist at all.
repack.version() is indeed needed to check the actual version of the library.
from pg_repack.
Making the extension upgradeable requires work because you need to provide an upgrade path, even if the diff is nil. If there is no change between 1.0.0 and 1.0.1 and a change in 1.0.2, you still need to provide a 1.0.0--1.0.1 file otherwise you can't go from 1.0.0 to 1.0.2.
We can provide these version upgrades for compatible upgrades, going forward.
Would not bother doing the testing for older versions.
As long as the functions don't change, it's a relatively small file anyway. And we can integrate upgrade tests, I think I have some code for that somewhere.
from pg_repack.
What would be the advantage of providing an upgrade feature for this extension?
from pg_repack.
Not forcing users to uninstall and reinstall the extension.
Got asked this by two different persons during pgconf.de 2024.
from pg_repack.
In my opinion it is a viable upgrade path: it has the advantage that it can't go wrong, whereas allowing upgrade can make the installed resources diverge in many ways. It is easier to maintain, and it causes no problem for end users.
from pg_repack.
Except that users need to uninstall and reinstall it. And that is not how other extensions work in PostgreSQL.
This is not easy to maintain.
from pg_repack.
Related Issues (20)
- All target table reads & writes blocked because of autovacuum on repack temporary table HOT 3
- Missing changes in `swap_head_or_index_files()`
- Respect table order list passed as argument HOT 1
- pg_repack 1.5.0 signed integer in name of log table lead to errors HOT 4
- Notices in pg_repack1.4.5 logs for AWS Aurora PostgreSQL 12.8 indicate waiting for transactions to finish with specific PIDs unrelated to the table being repacked. HOT 13
- Passwords in .pgpass with spaces cause error Unable to set up worker conn #0: missing "=" HOT 2
- LOCK TABLE can only be used in transaction blocks HOT 2
- Usage without client? HOT 2
- version 1.5.0 pg_repack the pg_repack command returns an ERROR: the request was not executed: ERROR: the tablespace ""XXXX"" does not exist HOT 5
- pg_repack v.1.4.7 won't build HOT 2
- repacking partitioned table indexes failed with: Could not find index/cannot create index on partitioned table concurrently HOT 5
- Error if the table is renamed concurrently during repacking
- Validate switch_threshold parameter is not greater than or equal to APPLY_COUNT
- unable to install pg_repack-1.4.7 on centos and amazon linux HOT 2
- over-ruled default search_path breaks index usage HOT 5
- Silent data loss due to two vacuum running logically different tables using the same relfilenode. HOT 1
- Can I install pg-repack (make && make install) during database runtime? HOT 1
- repack error HOT 3
- PG17 compatibility
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pg_repack.