Re: Postgresql C extension and SIGSEGV - Mailing list pgsql-general

From Albe Laurenz
Subject Re: Postgresql C extension and SIGSEGV
Date
Msg-id A737B7A37273E048B164557ADEF4A58B50FA0585@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Postgresql C extension and SIGSEGV  (Etienne Champetier <champetier.etienne@gmail.com>)
Responses Re: Postgresql C extension and SIGSEGV
List pgsql-general
Etienne Champetier wrote:
> We are planning to add a C extension (https://github.com/petropavel13/pg_rrule) to our shared
> postgresql cluster, and wondering what are the risk? (looking for the worst case scenario here)
> 
> If there is a SIGSEGV, SIGBUS, SIGABRT ..., is the whole server stopping, or just the request?

All client connections will be terminated and the server will initiate
recovery from the latest checkpoint.  Until that is done, no client
can connect to the database.

That is something you normally don't want to have in a production database.

> Knowing that the extension is only used in select statement, is there a risk of (on disk) data
> corruption?

Even when run from a SELECT, a C function can do anything it wants with the server.

> Is the risk limited to the current database? (the extension will only be used by 1 application with 1
> database, and we prefer not to impact other applications/databases)

The C function can happily start removing arbitrary file owned by
the PostgreSQL user if it chooses to, so no.

> Are there any techniques to limit/mitigate these risks? (configuration/compile flags/...)

You should only use C functions that you trust.

Code review of the extension and good testing are your best protection.

Yours,
Laurenz Albe

pgsql-general by date:

Previous
From: marin@kset.org
Date:
Subject: Re: Slave promotion problem...
Next
From: Ray Stell
Date:
Subject: Re: bdr admin role