feat: handle pg_net persistence mismatch for PG14 upgrade#2230
feat: handle pg_net persistence mismatch for PG14 upgrade#2230cfunkhouser wants to merge 3 commits into
Conversation
Crispy1975
left a comment
Crispy1975
left a comment
There was a problem hiding this comment.
LGTM; we have a ConfigCat allowPg14LaunchOrgs flag which allows an org slug to be added. This mean we can spin up a PG14 project and then do surgery to mimic the conditions we're gonna fix.
| # pg_net's net.http_request_queue was created UNLOGGED on PG14. Newer pg_net | ||
| # defines it as LOGGED, so the persistence mismatch breaks pg_upgrade. | ||
| # Convert it to LOGGED before making any other changes to the source server. |
There was a problem hiding this comment.
Confused with the above as it's not true, the table is UNLOGGED since pg_net v0.5 and has been kept that way until v0.20.3 now, see:
There was a problem hiding this comment.
Okay, interesting. We do have cases where the table is unlogged, but the sequence is logged. I'm assuming this is because unlogged sequences were introduced in PG15, so the sequence being logged is sticky from before upgrade.
Also, since unlogged is default for pg_net, setting the table to logged and leaving it that way is likely not the whole solution. Likely, we should be setting table and sequence back to unlogged after upgrading to versions which support that. Does that make sense?
I'll make that change, and will scrub that incorrect comment.
…e-mismatch-before-pg14-auto-upgrades
3 participants
Execute
ALTER TABLE net.http_request_queue SET LOGGEDon PG14 databases before upgrade.There is a state mismatch in which
net.http_request_queue_id_seqsequence is logged, but the tablenet.http_request_queueis not. This mismatch preventspg_upgradefrom proceeding. This change forces that alteration to occur at upgrade initiation time, before any of the other upgrade process has occurred.