https://github.com/postgres/postgres
Revision d21690edbf414582f7f20c26bb355d49cbbeb8a0 authored by Tom Lane on 09 February 2024, 17:29:41 UTC, committed by Tom Lane on 09 February 2024, 17:29:41 UTC
Since its introduction, pg_get_expr() has intended to silently
return NULL if called with an invalid relation OID, as can happen
when scanning the catalogs concurrently with relation drops.
However, there is a race condition: we check validity of the OID
at the start, but it could get dropped just afterward, leading to
failures.  This is the cause of some intermittent instability we're
seeing in a proposed new test case, and presumably it's a hazard in
the field as well.

We can fix this by AccessShareLock-ing the target relation for the
duration of pg_get_expr().  Since we don't require any permissions
on the target relation, this is semantically a bit undesirable.  But
it turns out that the set_relation_column_names() subroutine already
takes a transient AccessShareLock on that relation, and has done since
commit 2ffa740be in 2012.  Given the lack of complaints about that, it
seems like there should be no harm in holding the lock a bit longer.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/31ddcc01-a71b-4e8c-9948-01d1c47293ca@eisentraut.org
1 parent 8ead39e
History
Tip revision: d21690edbf414582f7f20c26bb355d49cbbeb8a0 authored by Tom Lane on 09 February 2024, 17:29:41 UTC
Remove race condition in pg_get_expr().
Tip revision: d21690e
File Mode Size
config
contrib
doc
src
.dir-locals.el -rw-r--r-- 730 bytes
.editorconfig -rw-r--r-- 183 bytes
.git-blame-ignore-revs -rw-r--r-- 9.1 KB
.gitattributes -rw-r--r-- 1.5 KB
.gitignore -rw-r--r-- 515 bytes
COPYRIGHT -rw-r--r-- 1.2 KB
GNUmakefile.in -rw-r--r-- 4.2 KB
HISTORY -rw-r--r-- 277 bytes
Makefile -rw-r--r-- 1.6 KB
README -rw-r--r-- 1.2 KB
README.git -rw-r--r-- 721 bytes
aclocal.m4 -rw-r--r-- 445 bytes
configure -rwxr-xr-x 581.1 KB
configure.ac -rw-r--r-- 84.7 KB

README

back to top