MVP working transaction fix #8750
Conversation
* Automaticly migrate pg16 to pg17 * Formatting and cleanup --------- Co-authored-by: Joe Hanley <joehanley@google.com>
| await tempOldDb.close(); | ||
| await oldDb.close(); | ||
|
|
||
| // 4. Nuke old data directory |
There was a problem hiding this comment.
Can we do this step last so that if something goes wrong during the import, the developer can still go back to an older CLI version?
Even better, what if we create a subdirectory in dataDir, say pg17 and only write to that subdirectory starting from this PR? In this way, the old and new CLI versions should not mess with each other. Ever time we change the on-disk format we can move to a different subdir name.
There was a problem hiding this comment.
That is a good call, implemented it:
When we migrate you, we'll copy your old dataDir over to dataDir/pg16. Then, we will use dataDir/pg17 going forward.
There was a problem hiding this comment.
Thanks, this looks great. I think we can make it even better by leaving existing data prefixless instead of pg16. In this way, downgrades are 100% safe out of the box without changing the dataDir settings.
Fixes transactions issues by updating to the latest version and removing the extended query patching because the upstream issue was fixed (electric-sql/pglite#294)
Updating pglite to 0.3.x also meant upgrading to Postgres 17 under the hood, which makes old data directories incompatible. To address this, we've added some automatic migration code based on https://pglite.dev/docs/upgrade
Fixes #8679 and #8658
Scenarios Tested
I grabbed a old data directory, ran
cat myData/PG_VERSIONto confirm it was PG16, and then ran this code against it and confirmed that it migrated and started up correctly. I then rerancat myData/PG_VERSIONto confirm it had been upgrade to PG17Code Samples