Remove unused include
This was added in add5cf28d4 but was apparently never used.
Discussion:
https://www.postgresql.org/message-id/flat/f84640e3-00d3-5abd-3f41-e6a19d33c...@eisentraut.org
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/eb36c6ac8478e664edebe8131ff
Fix behavior of "force" in pgstat_report_wal()
As implemented in 5891c7a8ed8f, setting "force" to true in
pgstat_report_wal() causes the routine to not wait for the pgstat
shmem lock if it cannot be acquired, in which case the WAL and I/O
statistics finish by not being flushed. The origin of the
Fix behavior of "force" in pgstat_report_wal()
As implemented in 5891c7a8ed8f, setting "force" to true in
pgstat_report_wal() causes the routine to not wait for the pgstat
shmem lock if it cannot be acquired, in which case the WAL and I/O
statistics finish by not being flushed. The origin of the
Fix behavior of "force" in pgstat_report_wal()
As implemented in 5891c7a8ed8f, setting "force" to true in
pgstat_report_wal() causes the routine to not wait for the pgstat
shmem lock if it cannot be acquired, in which case the WAL and I/O
statistics finish by not being flushed. The origin of the
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
doc: Tell about "vcregress taptest" for regression tests on Windows
There was no mention of this command in the documentation, and it is
useful to run the TAP tests of a target source directory.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20230925153204.926d685d347ee1c8f5270...@sraoss.co
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Fix edge-case for xl_tot_len broken by bae868ca.
bae868ca removed a check that was still needed. If you had an
xl_tot_len at the end of a page that was too small for a record header,
but not big enough to span onto the next page, we'd immediately perform
the CRC check using a bogus large length.
Add worker type to pg_stat_subscription.
Thanks to commit 2a8b40e368, the logical replication worker type is
easily determined. The worker type could already be deduced via
other columns such as leader_pid and relid, but that is unnecessary
complexity for users.
Bumps catversion.
Author: Peter
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should no
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
Collect dependency information for parsed CallStmts.
Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL. We failed to detect
this for CALLs in plpgsql routines, because no depend
docs: Clarify --with-segsize-blocks documentation
Without the added "relation" it's not immediately clear that the option
relates to the relation segment size and not e.g. the WAL segment size.
The option was added in d3b111e32.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/837536.16953
docs: Clarify --with-segsize-blocks documentation
Without the added "relation" it's not immediately clear that the option
relates to the relation segment size and not e.g. the WAL segment size.
The option was added in d3b111e32.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/837536.16953
Pack struct ParsedWord more tightly.
In a 64-bit build there's an awful lot of useless pad space in
ParsedWords. Since we may allocate large arrays of these,
it's worth some effort to reduce their size.
Here we reduce the alen field from uint32 to uint16, and then re-order
the fields to avoid un
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Limit to_tsvector_byid's initial array allocation to something sane.
The initial estimate of the number of distinct ParsedWords is just
that: an estimate. Don't let it exceed what palloc is willing to
allocate. If in fact we need more entries, we'll eventually fail
trying to enlarge the array.
Doc: improve cross-reference in Makefile comment.
Per gripe from Japin Li.
Discussion:
https://postgr.es/m/meyp282mb16692171f13b5df40db768eeb6...@meyp282mb1669.ausp282.prod.outlook.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3aff1d3fd0fb7f00da3c9994114e596
vacuumdb: Fix excluding multiple schemas with -N
When specifying multiple schemas to exclude with -N parameters, none
of the schemas are actually excluded (a single -N worked as expected).
This fixes the catalog query to handle multiple exclusions and adds a
test for this case.
Backpatch to v16 w
vacuumdb: Reword --help message for clarity
The --help output stated that schemas were specified using PATTERN
when they in fact aren't pattern matched but are required to be
exact matches. This changes to SCHEMA to make that clear.
Backpatch through v16 where this was introduced.
Author: Kuwamu
vacuumdb: Fix excluding multiple schemas with -N
When specifying multiple schemas to exclude with -N parameters, none
of the schemas are actually excluded (a single -N worked as expected).
This fixes the catalog query to handle multiple exclusions and adds a
test for this case.
Backpatch to v16 w
vacuumdb: Reword --help message for clarity
The --help output stated that schemas were specified using PATTERN
when they in fact aren't pattern matched but are required to be
exact matches. This changes to SCHEMA to make that clear.
Backpatch through v16 where this was introduced.
Author: Kuwamu
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
pg_upgrade: check for types removed in pg12
Commit cda6a8d01d39 removed a few datatypes, but didn't update
pg_upgrade --check to throw error if these types are used. So the users
find that pg_upgrade --check tells them that everything is fine, only to
fail when the real upgrade is attempted.
Rev
Fix typo in numutils.c comments
s/messges/messages/
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c1609cf3c014294937058d4ca2b3160ec1b5be8c
Modified Files
--
src/backend/utils/adt/numutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Add GUC for temporarily disabling event triggers
In order to troubleshoot misbehaving or buggy event triggers, the
documented advice is to enter single-user mode. In an attempt to
reduce the number of situations where single-user mode is required
(or even recommended) for non-extraordinary mainte
55 matches
Mail list logo
