public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
6+ messages / 1 participants
[nested] [flat]
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/940489b46769eb2d2997227053ab6ca76a2ac857
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/8c785d354c6139467516ae2592338c99d0788f47
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f5a465f1a07474f380b54073a518602b342a188b
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/09f09884c18d725db7a60e03a8f78bafdbc78b95
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/43cca9de9a0adf3fb47aaa6310cc0022a78eee8a
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err
@ 2024-02-25 21:15 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-25 21:15 UTC (permalink / raw)
To: [email protected]
Promote assertion about !ReindexIsProcessingIndex to runtime error.
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/c0b4dad38e84d4b5f25391b97f0d51b66eb020f2
Modified Files
--------------
src/backend/access/index/genam.c | 6 ++++--
src/backend/access/index/indexam.c | 17 +++++++++++------
2 files changed, 15 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-02-25 21:15 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err Tom Lane <[email protected]>
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err Tom Lane <[email protected]>
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err Tom Lane <[email protected]>
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err Tom Lane <[email protected]>
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err Tom Lane <[email protected]>
2024-02-25 21:15 pgsql: Promote assertion about !ReindexIsProcessingIndex to runtime err 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