| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Why is lorikeet so unstable in v14 branch only? |
| Date: | 2022-03-27 13:42:05 |
| Message-ID: | f6d7b1f1-da4d-8806-a988-27e82acf65a0@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-03-27 14:13:00 | Re: Add LZ4 compression in pg_dump |
| Previous Message | Nikolay Shaplov | 2022-03-27 12:19:41 | Re: [PATCH] New [relation] option engine |