< 0.3.6 : Raising native exceptions in languages extensions/dynamic bindings

[tobacode]

EXCEPTION in function triggers causes PGlite to enter broken state

Raising an EXCEPTION within a function trigger causes PGlite to enter a broken state, similar to issue #92. All subsequent requests fail with various errors depending on the environment.

Vitest environment

• With transaction: Further queries throw: error: current transaction is aborted, commands ignored until end of transaction block
• Without transaction: Further queries throw: RuntimeError: null function or function signature mismatch

Browser environment (React app, Firefox)

• Without transaction: Further queries throw: Error: Dynamic linking error: cannot resolve symbol setTempRet0
• With transaction: Not tested

Reproduction

Repository with reproduction steps: https://github.com/Toba-bonjour/PGlite_issue

Related issues

• "memory access out of bounds" or "null function or function signature mismatch" with plpgsql; but works in Postgres 13/14.5/15.1 #92 (similar broken state behavior)

Edit: There seems to be easier steps to reproduce. Simply make sure that PG throws an exception (for instance updating a table that does not exist) and the DB becomes unusable.

Edit2: While I may not yet have the technical skills to resolve this issue, I would love to help the electric team with my design / motion design / graphic background.

[tdrz]

Hi @Toba-bonjour

Edit: There seems to be easier steps to reproduce. Simply make sure that PG throws an exception (for instance updating a table that does not exist) and the DB becomes unusable.

I've just added a simple unit test #727 but that seems to work just fine.

[umajho]

Here is my reproduction:

Source code in Deno (main.ts):

import { PGlite } from "npm:@electric-sql/pglite@0.3.5";

async function main() {
  const db = await PGlite.create();

  await db.query(`
    CREATE PROCEDURE raise_hello() LANGUAGE plpgsql AS $$
    BEGIN
      RAISE 'hello';
    END;
    $$;
  `);

  try {
    await db.query("CALL raise_hello()");
  } catch (error) {
    console.error("Caught error:", error);
  }
}

await main();

Output:

➜  pglite-reproduction-raise deno run main.ts
✅ Granted read access to "/Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/pglite.data".
✅ Granted read access to "/Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/pglite.wasm".
✅ Granted env access.
✅ Granted read access to <exec_path>.
✅ Granted run access to "/bin/sh".
Caught error: Error: Dynamic linking error: cannot resolve symbol setTempRet0
    at e.<computed> (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:1:89333)
    at <anonymous> (wasm://wasm/0009251e:1:109244)
    at <anonymous> (wasm://wasm/02190c76:1:2036126)
    at <anonymous> (wasm://wasm/02190c76:1:1422297)
    at <anonymous> (wasm://wasm/02190c76:1:2547460)
    at <anonymous> (wasm://wasm/02190c76:1:3316086)
    at invoke_viiiiii (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:3:237720)
    at <anonymous> (wasm://wasm/02190c76:1:2548529)
    at invoke_iiiiiiii (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:3:239021)
    at <anonymous> (wasm://wasm/02190c76:1:4924905)

---

Edit 1: Even with the attempt to catch the exception in Postgres, the problem still occurs:

    CREATE PROCEDURE raise_hello() LANGUAGE plpgsql AS $$
    BEGIN
      RAISE 'hello';
    EXCEPTION
      WHEN OTHERS THEN
        RETURN;
    END;
    $$;

➜  pglite-reproduction-raise deno run -A main-2.ts
Caught error: Error: Dynamic linking error: cannot resolve symbol setTempRet0
    at e.<computed> (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:1:89333)
    at <anonymous> (wasm://wasm/0009251e:1:32612)
    at <anonymous> (wasm://wasm/0009251e:1:57703)
    at invoke_iii (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:3:237029)
    at <anonymous> (wasm://wasm/0009251e:1:32307)
    at <anonymous> (wasm://wasm/0009251e:1:26850)
    at invoke_iiiiiii (file:///Users/um/Library/Caches/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.3.5/dist/index.js:3:241500)
    at <anonymous> (wasm://wasm/0009251e:1:109187)
    at <anonymous> (wasm://wasm/02190c76:1:2036126)
    at <anonymous> (wasm://wasm/02190c76:1:1422297)

---

Edit 2: I realized that this problem can be reproduced directly in the REPL embedded in the official website:

---

Edit 3: RAISE (DEBUG|LOG|INFO|NOTICE|WARNING) … does not cause this. Only RAISE (EXCEPTION)? … does.

[tobacode]

Thank you for responding @tdrz, I will try your test with my setup. @umajho, you're right, using the REPL is much simpler. I can confirm that all subsequent requests seem to fail after raising an exception, which is the behavior I meet in my tests.

[pmp-p]

Sorry, the cost to handle nested exceptions is way too high in current WebAssembly state. Try to pass exceptions by values ( maybe harder but faster and better )

[tobacode]

All right, thanks for the clarification and workaround suggestion.

[umajho]

Sorry, the cost to handle nested exceptions is way too high in current WebAssembly state. Try to pass exceptions by values ( maybe harder but faster and better )

Thanks for the explanation.

IMO this should be mentioned at least under the README's “Limitations” section.

Also, I think It would be better to keep this issue open, since maybe one day WebAssembly will be evolved well enough, such that this can be fixed without sacrificing performance.

[pmp-p]

yes keeping open until compiler is fixed - really no ETA - to handle those very tricky corner cases. Actually plpgsql is an optionnal extension not pglite itself and it does not have its own exception handler like PL/Python or PL/Perl.