`ERROR: too late initialization of fmgr_plpgsql_cache`

[diraneyya]

A disclaimer.

I have no idea if this weird error is caused by the language server or the postgrestools vscode extension. It can also be caused by something entirely different.

Are you familiar with this weird error and has it been reported by anyone?

I started experiencing it after incorporating the language server and the vscode extension into my development workflow.

[psteinroe]

There is exactly one place in the internet with fmgr_plpgsql_cache according to google, and it's the source code of plpgsql_check. I could only find issue okbob/plpgsql_check#178 where this is mentioned as a source of problems. could you share where you see the error, and what version of the extension you have installed?

[diraneyya]

Haha. Amazing! Thank you for looking into this so quickly.

Where I see the error. Ahh! That is the difficult bit. It is unpredictable and seems to happen unpredictably at completely different times.

I am building a full-fledged scraper engine on top of PostgreSQL (open-core here https://forgejo.orwa.tech/open-source/pg_fetch_cycle). The worst is when the error happens during trigger processing because it leads to an infinite processing loop (due to how pg_net works, on which I have built my extension).

But I have just now experienced this happening while flushing one of my scrape buffer tables:

delete from only fetch_cycle_buffer_prototype where true;

│2025-09-17 07:49:27.600 +0200 [2274868] ERROR:  too late initialization of fmgr_plpgsql_cache                                      │
│2025-09-17 07:49:27.600 +0200 [2274868] HINT:  Use "load 'plpgsql_check'" before you use plpgsql_check functionality.              │
│2025-09-17 07:49:27.600 +0200 [2274868] STATEMENT:  delete from only fetch_cycle_buffer_prototype where true;

The issue is happening due to using plpgsql_check's functionality, which is why I suspect the vscode extension or the language server to be the culprit.

The deletion above was interrupted and cancelled due to the error. I tried again, and it worked without an issue (as is often the case with this obscure error).

A problem like this that is both obscure and hard to reproduce reliably is possibly the worst thing you can have in a scraping engine that works continuously to keep millions of records in sync. Haha.

I am using the following extension versions:

• plpgsql_check version 2.8
• pg_net 0.19.6

Not sure if it is related, but I am also using this hot reloading pattern and recently started using plpgsql_check's pragma function to avoid false warnings like the one I reported in #495:

create or replace function stellenangebote_update_audit_handler ()
    returns trigger language plpgsql as $audit$
declare
    aux int := plpgsql_check_pragma('disable:check');
    column_names text[] := array[
        'refnr',
        'beruf',
        'titel',
        'ort',
        'plz',
        'region',
        'land',
        'lat',
        'lon',
        'arbeitgeber',
        'veroeffentlichungsdatum',
        --'modifikationstimestamp',
        'eintrittsdatum',
        'kundennummerhash',
        'externeurl'
    ];
    t text := null;
    is_equal boolean;
begin 
    foreach t in array column_names loop
        execute format('select ($1).%1$I is not distinct from ($2).%1$I', t)
            using old, new into is_equal;
        if not is_equal then 
            execute format('insert into stellenangebote_update_audit '
                '(job_refnr, column_name, old_value, new_value) values '
                '($1, ''%1$s'', ($2).%1$I::text, ($3).%1$I::text)', t)
                using old.refnr, old, new;
        end if;
    end loop;
    return new;
end $audit$;

Not sure if any of the above has any direct link to this error, though.

[diraneyya]

After reading the link you posted, it seems that this should be fixed soon according to this comment okbob/plpgsql_check#178 (comment)