public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Remove race condition in pg_get_expr().
6+ messages / 1 participants
[nested] [flat]
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4eb261165d1294f590c7c279a8825e73abe57ecd
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/26c89d10543ad832bd4d2ce6eb00948575c2db07
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d21690edbf414582f7f20c26bb355d49cbbeb8a0
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/ceb224b62b9d66bdf8584b01c103268d3b90d577
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f38903d1ed6fbafdfac0ba797337c682eeafe9f5
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove race condition in pg_get_expr().
@ 2024-02-09 17:29 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-09 17:29 UTC (permalink / raw)
To: [email protected]
Remove race condition in pg_get_expr().
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/[email protected]
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/ce571434ae7027462565706236a0c6fbdf603734
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 68 +++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 35 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-02-09 17:29 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
2024-02-09 17:29 pgsql: Remove race condition in pg_get_expr(). Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox