Re: Why is lorikeet so unstable in v14 branch only?
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2022-03-27T13:42:05Z
Lists: pgsql-hackers
On 3/26/22 18:10, Tom Lane wrote: > >> If I understand correctly that you're only seeing this in v13 and >> HEAD, then it seems like bf68b79e5 (Refactor ps_status.c API) >> deserves a hard look. > I still stand by this opinion. Can you verify which of the ps_status.c > code paths gets used on this build? > > It appears that it is using PS_USE_NONE, as it doesn't have any of the defines required for the other paths. I note that the branch for that in get_ps_display() doesn't set *displen, which looks a tad suspicious. It could be left with any old junk. And maybe there's a good case for also surrounding some of the code in WaitOnLock() with "if (len) ..." cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
Fix breakage of get_ps_display() in the PS_USE_NONE case.
- 9016a2a3dc4e 13.7 landed
- 3f7a59c59b48 14.3 landed
- 0fb6954aa501 15.0 landed