| guruprasad | wgrant, cjwatson, 👋 I am currently working on getting the Launchpad test suite running against Postgres 14 (backported to focal, for the time being) and some tests are failing due to a schema change in the pg_stat_activity table causing the public.activity() plpgsql function to error out. I see that in the past there have been changes made for specific versions of Postgres and I am trying to figure out what changes to make here. Do you have | 06:07 |
|---|---|---|
| guruprasad | any pointers to share? | 06:07 |
| guruprasad | Also, since this function is in the current baseline schema file, I am not sure how to get it applied in production and whether there needs to be a new baseline created etc. Can you advise? | 06:07 |
| guruprasad | Okay, I figured out how to check for new columns that were added to pg_stat_activity after Postgres 12 similar to how it is done in the existing function. But I still don't understand how to apply this to production, what a baseline is, whether it is involved here, and how to create a new, if needed. | 06:41 |
| guruprasad | *how to create a new one | 06:41 |
| guruprasad | I even have the patch for Postgres >= 13 compatibility ready - https://paste.ubuntu.com/p/fMB3s2FhbB/. But not sure if the current baseline SQL file is the right place to add it. | 07:28 |
| cjwatson | guruprasad: We normally apply this sort of thing as a normal-ish patch first with CREATE OR REPLACE FUNCTION, and get it into production that way. Once that's settled, we do a rebaseline so that it's possible to initialize the DB on a newer PostgreSQL. Rebaselines are basically a pg_dump with a newer major version number (the last one was in commit 4d05a04da740472f57ef0b8c9c68dfc342e84034), but | 11:47 |
| cjwatson | I've forgotten all the details and it will probably involve some experimentation to make sure the diff between baselines is as expected. | 11:47 |
| guruprasad | cjwatson, thanks. Is this normal-ish patch a cold patch? That's what I suspect. Also, in this case, "initialize the DB on a newer PostgreSQL" is only for dev environments, right? | 11:54 |
| guruprasad | Because we will never have to initialize the production database on a newer PostgreSQL version because we always try to do in-place upgrades. | 11:57 |
| cjwatson | guruprasad: Dev and test, yes | 12:02 |
| cjwatson | guruprasad: I don't remember whether you can do CREATE OR REPLACE FUNCTION hot | 12:03 |
| cjwatson | guruprasad: I appear to have done https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/418572 as a cold patch | 12:06 |
| cjwatson | (though that also had CREATE EXTENSION, so ...) | 12:06 |
| cjwatson | guruprasad: Might as well do it cold though | 12:07 |
| guruprasad | cjwatson, thanks for the advice. I see https://dev.launchpad.net/Database/LivePatching#Stored_Procedures mentioning that stored procedures can be applied as a hot patch, but I am going to apply it using the fastdowntime method, just in case. | 12:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!