How to deploy pg_partman with rolling update on kubernetes #535
Replies: 1 comment
-
Not sure I fully understand what you're doing here, but if you're trying to make table renaming operations transparent to users, you can wrap all the relevant statements in a transaction (BEGIN/COMMIT) and immediately at the start of the transaction, obtain exclusive locks on all relevant objects. If the locks are obtained, that ensures that nothing else is accessing it and prevents anything else from accessing it until COMMIT. If possible, it would be good to limit as much client interaction with these objects as possible during this operation. Otherwise you run into both your own session waiting on locks and then all subsequent transactions being held up until COMMIT. You can see a similar transaction locking method in the example of online partitioning here - https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md#online-partitioning |
Beta Was this translation helpful? Give feedback.
-
I had a table with the name 'parcel_event'. I am partitioning it with pg_partman and scheduling monthly maintenance with pg_cron.
What am I doing:
I am using flyway for database migration, in which I am renaming 'parcel_event' to 'parcel_event_old', then creating a new table with the name 'parcel_event'. Then applying partition and scheduling with pg_partman and pg_cron.
After that, I am migrating the last 3 months' data from 'parcel_event_old' to 'parcel_event'.
Problems that I am facing doing deployment are:
When I rename the 'parcel_event' table then my already running pod with the old version will not find the table 'parcel_event' between renaming time and the new table 'parcel_event' creating + partitioning time.
What should I do?
Should I not rename or is there any other way?
Should I run these commands externally on Postgres?
Is there any way with locking?
Should I stop Kafka consumer inside the service?
Beta Was this translation helpful? Give feedback.
All reactions