At Wed, 16 Mar 2022 11:13:53 +1300, Thomas Munro wrote
in
> On Wed, Mar 16, 2022 at 10:28 AM Tom Lane wrote:
> > David Steele writes:
> > > On 3/14/22 19:31, Thomas Munro wrote:
> > >> Fix pg_basebackup with in-place tablespaces.
> >
> > > Perhaps I'm being picky, but seems like this logic sho
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
Fix race between DROP TABLESPACE and checkpointing.
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a wi
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
pageinspect: Fix memory context allocation of page in brin_revmap_data()
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d
Fix documentation typo in commit 5e6368b4.
Back-patch to 14.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ea70f6945029b622ea28d53c7a32354d1d033246
Modified Files
--
doc/src/sgml/monitoring.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Fix documentation typo in commit 5e6368b4.
Back-patch to 14.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/501c66c81b755583fa516c88e1cc7c760dc88bd5
Modified Files
--
doc/src/sgml/monitoring.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Mar 16, 2022 at 11:45:14AM +0900, Michael Paquier wrote:
> I have reproduced the problem locally, just looking into why the page
> alignment and/or the allocation change seem to matter here..
Bleh. That's a simple oversight with the multi-call memory context
where the aligned copy of the
Fix waiting in RegisterSyncRequest().
If we run out of space in the checkpointer sync request queue (which is
hopefully rare on real systems, but common with very small buffer pool),
we wait for it to drain. While waiting, we should report that as a wait
event so that users know what is going on,
Fix waiting in RegisterSyncRequest().
If we run out of space in the checkpointer sync request queue (which is
hopefully rare on real systems, but common with very small buffer pool),
we wait for it to drain. While waiting, we should report that as a wait
event so that users know what is going on,
Fix waiting in RegisterSyncRequest().
If we run out of space in the checkpointer sync request queue (which is
hopefully rare on real systems, but common with very small buffer pool),
we wait for it to drain. While waiting, we should report that as a wait
event so that users know what is going on,
Fix waiting in RegisterSyncRequest().
If we run out of space in the checkpointer sync request queue (which is
hopefully rare on real systems, but common with very small buffer pool),
we wait for it to drain. While waiting, we should report that as a wait
event so that users know what is going on,
On Wed, Mar 16, 2022 at 02:21:42AM +, Michael Paquier wrote:
> pageinspect: Fix handling of page sizes and AM types
sifaka and some other animals have been complaining here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2022-03-16%2002%3A24%3A28
I have reproduced the probl
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a
Wake up for latches in CheckpointWriteDelay().
The checkpointer shouldn't ignore its latch. Other backends may be
waiting for it to drain the request queue. Hopefully real systems don't
have a full queue often, but the condition is reached easily when
shared_buffers is small.
This involves defi
Wake up for latches in CheckpointWriteDelay().
The checkpointer shouldn't ignore its latch. Other backends may be
waiting for it to drain the request queue. Hopefully real systems don't
have a full queue often, but the condition is reached easily when
shared_buffers is small.
This involves defi
Back-patch LLVM 14 API changes.
Since LLVM 14 has stopped changing and is about to be released,
back-patch the following changes from the master branch:
e6a7600202105919bffd62b3dfd941f4a94e082b
807fee1a39de6bb8184082012e643951abb9ad1d
a56e7b66010f330782243de9e25ac2a6596be0e1
Back-patch to
Back-patch LLVM 14 API changes.
Since LLVM 14 has stopped changing and is about to be released,
back-patch the following changes from the master branch:
e6a7600202105919bffd62b3dfd941f4a94e082b
807fee1a39de6bb8184082012e643951abb9ad1d
a56e7b66010f330782243de9e25ac2a6596be0e1
Back-patch to
Back-patch LLVM 14 API changes.
Since LLVM 14 has stopped changing and is about to be released,
back-patch the following changes from the master branch:
e6a7600202105919bffd62b3dfd941f4a94e082b
807fee1a39de6bb8184082012e643951abb9ad1d
a56e7b66010f330782243de9e25ac2a6596be0e1
Back-patch to
Back-patch LLVM 14 API changes.
Since LLVM 14 has stopped changing and is about to be released,
back-patch the following changes from the master branch:
e6a7600202105919bffd62b3dfd941f4a94e082b
807fee1a39de6bb8184082012e643951abb9ad1d
a56e7b66010f330782243de9e25ac2a6596be0e1
Back-patch to
Silence LLVM 14 API deprecation warnings.
We are going to need to handle the upcoming opaque pointer API
changes[1], possibly in time for LLVM 15, but in the meantime let's
silence the warnings produced by LLVM 14.
[1] https://llvm.org/docs/OpaquePointers.html
Reviewed-by: Andres Freund
Discuss
On Wed, Mar 16, 2022 at 10:28 AM Tom Lane wrote:
> David Steele writes:
> > On 3/14/22 19:31, Thomas Munro wrote:
> >> Fix pg_basebackup with in-place tablespaces.
>
> > Perhaps I'm being picky, but seems like this logic should be wrapped in:
> > if (allow_in_place_tablespaces)
> > {
> > <..
David Steele writes:
> On 3/14/22 19:31, Thomas Munro wrote:
>> Fix pg_basebackup with in-place tablespaces.
> Perhaps I'm being picky, but seems like this logic should be wrapped in:
> if (allow_in_place_tablespaces)
> {
> <...>
> }
> I worry about strange effects when this GUC is not enabl
On 3/14/22 19:31, Thomas Munro wrote:
Fix pg_basebackup with in-place tablespaces.
Previously, pg_basebackup from a cluster that contained an 'in-place'
tablespace, as introduced by commit 7170f215, would produce a harmless
warning on Unix and fail completely on Windows.
Perhaps I'm being pick
Hi,
On 2022-03-15 17:33:12 +, Robert Haas wrote:
> Add 'basebackup_to_shell' contrib module.
>
> As a demonstration of the sort of thing that can be done by adding a
> custom backup target, this defines a 'shell' target which executes a
> command defined by the system administrator. The comma
Hi,
On 2022-03-15 12:12:44 +1300, Thomas Munro wrote:
> Shortly I'll do the back-patch of LLVM 14 API changes (their final
> release tag is scheduled for tomorrow, as I've been reminded by
> package maintainers trying and failing to build).
+1
> But I figured I
> should also follow up on this b
Remove accidentally-committed file.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8ef1fa3ee05d7acfe3f69d28daabec33db84d870
Modified Files
--
src/backend/replication/Makefile.orig | 49 ---
1 file changed, 49 deletions(-)
Allow extensions to add new backup targets.
Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc allowed for base backup
targets, meaning that we could do something with the backup other than
send it to the client, but all of those targets had to be baked in to
the core code. This commit makes it possi
Add 'basebackup_to_shell' contrib module.
As a demonstration of the sort of thing that can be done by adding a
custom backup target, this defines a 'shell' target which executes a
command defined by the system administrator. The command is executed
once for each tar archive generate by the backup
Change HAVE_LIBLZ4 and HAVE_LIBZSTD tests to USE_LZ4 and USE_ZSTD.
These tests were added recently, but older code tests USE_LZ4 rathr
than HAVE_LIBLZ4, so let's follow the established precedent. It
also seems more consistent with the intent of the configure tests,
since I think that the USE_* sym
43 matches
Mail list logo
