Fix GiST index deletion assert issue.
Avoid calling heap_index_delete_tuples() with an empty deltids array to
avoid an assertion failure.
This issue was arguably an oversight in commit b5f58cf2, though the
failing assert itself was added by my recent commit d168b666. No
backpatch, though, since
doc: Remove reference to views for TRUNCATE privilege
The page about privilege rights mentioned that TRUNCATE could be applied
to views or even other relation types. This is confusing as this
command can be used only on tables and on partitioned tables.
Oversight in afc4a78.
Reported-by: Harisa
doc: Remove reference to views for TRUNCATE privilege
The page about privilege rights mentioned that TRUNCATE could be applied
to views or even other relation types. This is confusing as this
command can be used only on tables and on partitioned tables.
Oversight in afc4a78.
Reported-by: Harisa
doc: Remove reference to views for TRUNCATE privilege
The page about privilege rights mentioned that TRUNCATE could be applied
to views or even other relation types. This is confusing as this
command can be used only on tables and on partitioned tables.
Oversight in afc4a78.
Reported-by: Harisa
Refactor code in tablecmds.c to check and process tablespace moves
Two code paths of tablecmds.c (for relations with storage and without
storage) use the same logic to check if the move of a relation to a
new tablespace is allowed or not and to update pg_class.reltablespace
and pg_class.relfilenod
Rethink recently-added SPI interfaces.
SPI_execute_with_receiver and SPI_cursor_parse_open_with_paramlist are
new in v14 (cf. commit 2f48ede08). Before they can get out the door,
let's change their APIs to follow the practice recently established by
SPI_prepare_extended etc: shove all optional ar
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
Report the true database name on connection errors
When reporting connection errors, we might show a database name in the
message that's not the one we actually tried to connect to, if the
database was taken from libpq defaults instead of from user parameters.
Fix such error messages to use PQdb()
I wrote:
> Michael Paquier writes:
>> On Tue, Jan 26, 2021 at 03:28:39AM +, Tom Lane wrote:
>>> Improve performance of repeated CALLs within plpgsql procedures.
>> lapwing is generating a warning here:
> Yeah, I saw that last night. It's weird, because that patch surely
> did not change any
Suppress compiler warnings from commit ee895a655.
For obscure reasons, some buildfarm members are now generating
complaints about plpgsql_call_handler's "retval" variable possibly
being used uninitialized. It seems no less safe than it was before
that commit, but these complaints are (mostly?) ne
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Code review for psql's helpSQL() function.
The loops to identify word boundaries could access past the end of
the input string. Likely that would never result in an actual
crash, but it makes valgrind unhappy.
The logic to try different numbers of words didn't work when the
input has two words b
Michael Paquier writes:
> On Tue, Jan 26, 2021 at 03:28:39AM +, Tom Lane wrote:
>> Improve performance of repeated CALLs within plpgsql procedures.
> lapwing is generating a warning here:
Yeah, I saw that last night. It's weird, because that patch surely
did not change anything that should
Hi Tom,
On Tue, Jan 26, 2021 at 03:28:39AM +, Tom Lane wrote:
> Improve performance of repeated CALLs within plpgsql procedures.
>
> This patch essentially is cleaning up technical debt left behind
> by the original implementation of plpgsql procedures, particularly
> commit d92bc83c4. That
Fix memory leak when deallocating prepared statement in postgres_fdw
The leak is minor, so no backpatch is done. Oversight in 21734d2.
Reported-by: Tom Lane
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7b4c660466dd8a1d25ca316ac02099a7cf0e5896
Modified Files
--
postgres_fdw: Fix test failure with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
The roles created by regression test should have names starting with
"regress_", and the test introduced in commit 411ae64997 did not do that.
Per buildfarm member longfin.
Discussion:
https://postgr.es/m/73fc5ae4-3
25 matches
Mail list logo
