From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cached plans and statement generalization |
Date: | 2017-05-18 16:47:17 |
Message-ID: | 20170518164717.jotsex4wilkzwyg5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-05-18 11:57:57 +0300, Konstantin Knizhnik wrote:
> From my own experience I found out that PG_TRY/PG_CATCH mechanism is not
> providing proper cleanup (unlike C++ exceptions).
Right, simply because there's no portable way to transparently do so.
Would be possible on elf glibc platforms, but ...
> If there are opened relations, catalog cache entries,... then throwing error
> will not release them.
> It will cause no problems if error is handled in PostgresMain which aborts
> current transaction and releases all resources in any case.
> But if I want to ignore this error and continue query execution, then
> warnings about resources leaks can be reported.
> Is it want you mean by unsafety of PG_TRY/PG_CATCH constructions?
There's worse than just leaking resources. Everything touching the
database might cause persistent corruption if you don't roll back.
Consider an insert that failed with a foreign key exception, done from
some function. If you ignore that error, the row will still be visible,
but the foreign key will be violated. If you want to continue after a
PG_CATCH you have to use a subtransaction/savepoint for the PG_TRY
contents, like several PLs do.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-05-18 18:06:02 | Re: NOT NULL constraints on range partition key columns |
Previous Message | Andres Freund | 2017-05-18 16:38:13 | Re: WIP Patch: Precalculate stable functions, infrastructure v1 |