[06:07] <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:41] <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
[07:28] <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.
[11:47] <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:54] <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:57] <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.
[12:02] <cjwatson> guruprasad: Dev and test, yes
[12:03] <cjwatson> guruprasad: I don't remember whether you can do CREATE OR REPLACE FUNCTION hot
[12:06] <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:07] <cjwatson> guruprasad: Might as well do it cold though
[12:30] <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.