Try to stabilize reloptions test, again.
Since the test requires reproducible behavior from VACUUM, and since
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page
skipping, let's use a temporary table to avoid contention.
Back-patch to 12, like commit 3414099c.
Discussion:
Try to stabilize reloptions test, again.
Since the test requires reproducible behavior from VACUUM, and since
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page
skipping, let's use a temporary table to avoid contention.
Back-patch to 12, like commit 3414099c.
Discussion:
Try to stabilize reloptions test, again.
Since the test requires reproducible behavior from VACUUM, and since
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page
skipping, let's use a temporary table to avoid contention.
Back-patch to 12, like commit 3414099c.
Discussion:
Try to stabilize reloptions test, again.
Since the test requires reproducible behavior from VACUUM, and since
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page
skipping, let's use a temporary table to avoid contention.
Back-patch to 12, like commit 3414099c.
Discussion:
On Wed, Jan 19, 2022 at 12:08 PM Andres Freund wrote:
> On 2022-01-18 17:19:06 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > That's an extremely small shared_buffers for running the regression
> > > tests, it'd not
> > > be surprising if that provoked problems we don't otherwise see.
On Wed, Jan 19, 2022 at 11:19 AM Tom Lane wrote:
> Andres Freund writes:
> > Also, it's odd that there's "max_connections 25" without an equal sign. I'd
> > kind of expected that to cause an error
>
> I see that guc.c intentionally allows the equal sign to be optional.
> Too lazy to check if
On Tue, Jan 18, 2022 at 11:08 AM Thomas Munro wrote:
> commit fe246d1c111d43fd60a1b0afff25ed09b7ae11eb
> Author: Michael Paquier
> Date: Fri Apr 2 09:44:42 2021 +0900
>
> Improve stability of test with vacuum_truncate in reloptions.sql
>
> Hmm... looking at that comm
Try to stabilize the reloptions test.
Where we test vacuum_truncate's effects, sometimes this is failing to
truncate as expected on the build farm. That could be explained by page
skipping, so disable it explicitly, with the theory that commit fe246d1c
didn't go far enough.
Back-patch to 12,
Try to stabilize the reloptions test.
Where we test vacuum_truncate's effects, sometimes this is failing to
truncate as expected on the build farm. That could be explained by page
skipping, so disable it explicitly, with the theory that commit fe246d1c
didn't go far enough.
Back-patch to 12,
Try to stabilize the reloptions test.
Where we test vacuum_truncate's effects, sometimes this is failing to
truncate as expected on the build farm. That could be explained by page
skipping, so disable it explicitly, with the theory that commit fe246d1c
didn't go far enough.
Back-patch to 12,
Try to stabilize the reloptions test.
Where we test vacuum_truncate's effects, sometimes this is failing to
truncate as expected on the build farm. That could be explained by page
skipping, so disable it explicitly, with the theory that commit fe246d1c
didn't go far enough.
Back-patch to 12,
On Tue, Jan 18, 2022 at 9:37 AM Andres Freund wrote:
> diff -w -U3 c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> c:/cirrus/src/test/recovery/results/reloptions.out
> --- c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> 2022-01-17 07:08:52.779337800 +
Move 027_stream_regress.pl's output to tmp_check.
Cleanup for commit f47ed79c.
Discussion:
https://postgr.es/m/CA%2BhUKGKU%3DtiZoE7vp7qYFQNPdBd2pHoaOwkPMDg9YWk1h%3DFtmQ%40mail.gmail.com
Branch
--
master
Details
---
On Mon, Jan 17, 2022 at 8:02 PM Michael Paquier wrote:
> Butterflyfish has just failed in this new test:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=butterflyfish=HEAD
>
> Ad the pg_regress command has failed one of the tests:
> reloptions ... FAILED
On Tue, Jan 18, 2022 at 6:24 AM Tom Lane wrote:
> I wrote:
> > I'm quite appalled that this patch has apparently added an entire new run
> > of the core regression tests to the standard check-world/buildfarm cycle.
I wonder if there is a good way to share the resulting data directory
with the
Test replay of regression tests, attempt II.
See commit message for 123828a7fa563025d0ceee10cf1b2a253cd05319. The
only change this time is the order of the arguments passed to
pg_regress. The previously version broke in the build farm environment
due to the contents of EXTRA_REGRESS_OPTS (see
Revert "Add new simple TAP test for tablespaces."
This reverts commit d1511fe1b040853f6e10d353e56b42bb96ae239d.
Discussion:
https://postgr.es/m/CA%2BhUKG%2BGBC-6QhOKt6Y7ccrXSjbRHB7Di295%3D0rAGhE7a7hSrQ%40mail.gmail.com
Branch
--
master
Details
---
Revert "Test replay of regression tests."
This reverts commit 123828a7fa563025d0ceee10cf1b2a253cd05319.
Discussion:
https://postgr.es/m/CA%2BhUKG%2BGBC-6QhOKt6Y7ccrXSjbRHB7Di295%3D0rAGhE7a7hSrQ%40mail.gmail.com
Branch
--
master
Details
---
Test replay of regression tests.
Add a new TAP test under src/test/recovery to run the standard
regression tests while a streaming replica replays the WAL. This
provides a basic workout for WAL decoding and redo code, and compares
the replicated result.
Optionally, enable (expensive)
Use in-place tablespaces in regression test.
Remove the machinery from pg_regress that manages the testtablespace
directory. Instead, use "in-place" tablespaces, because they work
correctly when there is a streaming replica running on the same host.
Reviewed-by: Andres Freund
Reviewed-by:
Allow "in place" tablespaces.
Provide a developer-only GUC allow_in_place_tablespaces, disabled by
default. When enabled, tablespaces can be created with an empty
LOCATION string, meaning that they should be created as a directory
directly beneath pg_tblspc. This can be used for new testing
Add new simple TAP test for tablespaces.
The tablespace tests in the main regression tests have been changed to
use "in-place" tablespaces, so that they work when streamed to a replica
on the same host. Add a new TAP test that exercises tablespaces with
absolute paths, for coverage.
On Wed, Jan 12, 2022 at 8:36 AM Tom Lane wrote:
> 1. It lacks the usual anti-multiple-inclusion guard, i.e.
> #ifndef WIN32NTDLL_H
> or the like. Was there a specific reason to omit that?
Oops. Fixed.
> 2. headerscheck and cpluspluscheck don't like it, at least
> not on non-Windows:
>
Add missing include guard to win32ntdll.h.
Oversight in commit e2f0f8ed. Also add this file to the exclusion lists
in headerscheck and cpluscpluscheck, because Unix systems don't have a
header it includes.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/2760528.1641929756%40sss.pgh.pa.us
Make EXEC_BACKEND more convenient on Linux and FreeBSD.
Try to disable ASLR when building in EXEC_BACKEND mode, to avoid random
memory mapping failures while testing. For developer use only, no
effect on regular builds.
Suggested-by: Andres Freund
Tested-by: Bossart, Nathan
Discussion:
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Fix overly generic name in with.sql test.
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Change ProcSendSignal() to take pgprocno.
Instead of referring to target backends by pid, use pgprocno. This
means that we don't have to scan the ProcArray and we can drop some
special case code for dealing with the startup process.
Discussion:
Check for STATUS_DELETE_PENDING on Windows.
1. Update our open() wrapper to check for NT's STATUS_DELETE_PENDING
and translate it to Unix-like errors. This is done with
RtlGetLastNtStatus(), which is dynamically loaded from ntdll. A new
file win32ntdll.c centralizes lookup of NT functions, in
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
On Mon, Aug 23, 2021 at 2:10 PM Michael Paquier wrote:
> Fix backup manifests to generate correct WAL-Ranges across timelines
+$primary->append_conf('standby.signal');
I think this needs a second argument, to silence a warning visible in
regress_log_007_wal.
Track LLVM 14 API changes.
Only done on the master branch for now to fix build farm animal seawasp
(which tests bleeeding edge PostgreSQL with bleeding edge LLVM). We can
back-patch a consolidated fix closer to LLVM 14's release, once its API
has stopped moving around.
Discussion:
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Make EXEC_BACKEND more convenient on macOS.
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide
Further simplify a bit of logic in StartupXLOG().
Commit 7ff23c6d277d1d90478a51f0dd81414d343f3850 left us with two
identical cases. Collapse them.
Author: Robert Haas
Discussion:
https://postgr.es/m/CA%2BhUKGJ8NRsqgkZEnsnRc2MFROBV-jCnacbYvtpptK2A9YYp9Q%40mail.gmail.com
Branch
--
master
Run checkpointer and bgwriter in crash recovery.
Start up the checkpointer and bgwriter during crash recovery (except in
--single mode), as we do for replication. This wasn't done back in
commit cdd46c76 out of caution. Now it seems like a better idea to make
the environment as similar as
jit: Don't inline functions that access thread-locals.
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov
jit: Don't inline functions that access thread-locals.
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov
jit: Don't inline functions that access thread-locals.
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov
jit: Don't inline functions that access thread-locals.
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov
jit: Don't inline functions that access thread-locals.
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov
Don't use #if inside function-like macro arguments.
No concrete problem reported, but in the past it's been known to cause
problems on some compilers so let's avoid doing that.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/234364.1626704007%40sss.pgh.pa.us
Branch
--
master
Details
Support direct I/O on macOS.
Macs don't understand O_DIRECT, but they can disable caching with a
separate fcntl() call. Extend the file opening functions in fd.c to
handle this for us if the caller passes in PG_O_DIRECT.
For now, this affects only WAL data and even then only if you set:
Adjust commit 2dbe8905 for ancient macOS.
A couple of open flags used in an assertion didn't exist in macOS 10.4.
Per build farm animal prairiedog. Also add O_EXCL while here (there are
a few more standard flags but they're not relevant and likely to be
missing).
Branch
--
master
Details
On Thu, Jul 15, 2021 at 4:07 AM Tom Lane wrote:
> I've tested the attached on the GCC farm's Solaris machine (which
> I believe is the same machine wrasse runs on), and it seems OK.
> I think it's ready to go.
Pushed. Thanks!
Portability fixes for sigwait.
Build farm animals running ancient HPUX and Solaris have a non-standard
sigwait() from draft versions of POSIX, so they didn't like commit
7c09d279. To avoid the problem in general, only try to use sigwait() if
it's declared by and matches the expected
On Wed, Jul 14, 2021 at 4:08 PM Thomas Munro wrote:
> On Wed, Jul 14, 2021 at 6:17 AM Tom Lane wrote:
> > (I suppose a hacky solution might be to never define USE_SIGWAIT
> > on Solaris.)
>
> Yeah I was thinking about that. I've just got a shell on an illumos
> VM and wi
On Wed, Jul 14, 2021 at 6:17 AM Tom Lane wrote:
> Just how badly did you want to use sigwait here? I'm having
> considerable second thoughts about the value of that change
> versus the hoops we're going to have to jump through to use it.
I'm sure I could find another way if it comes to it. The
7341706c3ba1f37a4b202becc63537fb1bc61c8b Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 13 Jul 2021 19:52:55 +1200
Subject: [PATCH 1/2] Portability fixes for sigwait.
Build farm animals running ancient HPUX and Solaris have a non-standard
sigwait() from draft versions of POSIX, so didn't like commit 7c09d279.
Only
On Tue, Jul 13, 2021 at 5:18 PM Thomas Munro wrote:
> https://illumos.org/man/2/sigwait
> https://docs.oracle.com/cd/E36784_01/html/E36872/sigwait-2.html
Oh, hmm, that's something we already have to do elsewhere to get
standard conforming interfaces on that platform:
# Some platfor
know about, but now that I know that there are
also draft 6 systems out there...). Note also the errno change, which
I (ironically) did the pre-standard way by mistake.
From 6f03a0f82fa842e5d6f2b32807343907923961a4 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 13 Jul 2021 12:47:03 +1200
On Tue, Jul 13, 2021 at 1:09 PM Tom Lane wrote:
> Thomas Munro writes:
> > Oh, thanks for the advance warning. Wouldn't HAVE_SIGWAIT be better?
> > Like so.
>
> That won't help as-is, because it *does* have sigwait, just not with
> the POSIX API. thread_test.
On Tue, Jul 13, 2021 at 12:30 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > To make \watch react quickly when the user quits the pager or presses
> > ^C, and also to increase the accuracy of its timing and decrease the
> > rate of useless context switches, change the
gwait() rather than a sleeping/polling loop, on Unix.
Supported on Unix only for now (like pspg).
Author: Pavel Stehule
Author: Thomas Munro
Discussion:
https://postgr.es/m/CAFj8pRBfzUUPz-3gN5oAzto9SDuRSq-TQPfXU_P6h0L7hO%2BEhg%40mail.gmail.com
Branch
--
master
Details
---
https://gi
Fix pgbench timestamp bugs.
Commit 547f04e changed pgbench to use microsecond accounting, but
introduced a couple of logging and aggregation bugs:
1. We print Unix epoch timestamps so that you can correlate them with
other logs, but these were inadvertently changed to use a
system-dependent
Fix pgbench timestamp bugs.
Commit 547f04e changed pgbench to use microsecond accounting, but
introduced a couple of logging and aggregation bugs:
1. We print Unix epoch timestamps so that you can correlate them with
other logs, but these were inadvertently changed to use a
system-dependent
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove more obsolete comments about semaphores.
Commit 675f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson
Remove some dead stores.
Remove redundant local variable assignments left behind by commit
2fc7af5e966.
Author: Quan Zongliang
Reviewed-by: Jacob Champion
Discussion: https://postgr.es/m/de141d14-4fd6-3148-99bf-856b71aa948a%40yeah.net
Branch
--
master
Details
---
following commits 2941138e6 and 61752afb2.
Author: Justin Pryzby
Reviewed-by: Fujii Masao
Reviewed-by: Michael Paquier
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/20210529192321.GM2082%40telsasoft.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff
Prepare for forthcoming LLVM 13 API change.
LLVM 13 (due out in September) has changed the semantics of
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to
avoid a double-free that causes crashes and bad query results.
A proactive change seems necessary to avoid having a window
Prepare for forthcoming LLVM 13 API change.
LLVM 13 (due out in September) has changed the semantics of
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to
avoid a double-free that causes crashes and bad query results.
A proactive change seems necessary to avoid having a window
Prepare for forthcoming LLVM 13 API change.
LLVM 13 (due out in September) has changed the semantics of
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to
avoid a double-free that causes crashes and bad query results.
A proactive change seems necessary to avoid having a window
Prepare for forthcoming LLVM 13 API change.
LLVM 13 (due out in September) has changed the semantics of
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to
avoid a double-free that causes crashes and bad query results.
A proactive change seems necessary to avoid having a window
On Fri, Jun 25, 2021 at 10:06 AM Thomas Munro wrote:
> pgsql-hackers
(Oops, I meant to write pgsql-general).
On Fri, Jun 25, 2021 at 9:57 AM Bhavesh Mistry
wrote:
> I was trying to install PSQL 13 on Ubuntu 14.04 (trusty) but I could not
> find the package. It seems the path has been removed. Can you please tell
> me how to build deb package for trusty from psql source? I tried psql 13
> sources,
Back-patch "Tolerate version lookup failure for old style Windows locale names."
If users provide old style pre-standardized Windows locale names in a
CREATE COLLATION command, the OS is unable to provide version
information. Continue without capturing version information, rather
than exposing
On Thu, Jun 17, 2021 at 11:28 PM Fujii Masao
wrote:
> Attached patch changes archiver so that it also handles barrier events.
LGTM. Thanks!
On Mon, Mar 15, 2021 at 5:14 PM Fujii Masao wrote:
> Make archiver process an auxiliary process.
>
> This commit changes WAL archiver process so that it's treated as
> an auxiliary process and can use shared memory. This is an infrastructure
> patch required for upcoming shared-memory based stats
Fix error handling in replacement pthread_barrier_init().
Commit 44bf3d50 incorrectly used an errno-style interface when supplying
missing pthread functionality (i.e. on macOS), but it should check for
and return error numbers directly.
Branch
--
master
Details
---
Fix race condition when sharing tuple descriptors.
Parallel query processes that called BlessTupleDesc() for identical
tuple descriptors at the same moment could crash. There was code to
handle that rare case, but it dereferenced a bogus DSA pointer. Repair.
Back-patch to 11, where commit
Fix race condition when sharing tuple descriptors.
Parallel query processes that called BlessTupleDesc() for identical
tuple descriptors at the same moment could crash. There was code to
handle that rare case, but it dereferenced a bogus DSA pointer. Repair.
Back-patch to 11, where commit
Fix race condition when sharing tuple descriptors.
Parallel query processes that called BlessTupleDesc() for identical
tuple descriptors at the same moment could crash. There was code to
handle that rare case, but it dereferenced a bogus DSA pointer. Repair.
Back-patch to 11, where commit
Fix race condition when sharing tuple descriptors.
Parallel query processes that called BlessTupleDesc() for identical
tuple descriptors at the same moment could crash. There was code to
handle that rare case, but it dereferenced a bogus DSA pointer. Repair.
Back-patch to 11, where commit
Revert recovery prefetching feature.
This set of commits has some bugs with known fixes, but at this late
stage in the release cycle it seems best to revert and resubmit next
time, along with some new automated test coverage for this whole area.
Commits reverted:
dc88460c: Doc: Review for
Revert per-index collation version tracking feature.
Design problems were discovered in the handling of composite types and
record types that would cause some relevant versions not to be recorded.
Misgivings were also expressed about the use of the pg_depend catalog
for this purpose. We're out
Doc: Update notes about libc collation versions.
The per-index collation version tracking feature was reverted, but we
still have the ability to ask Windows (352f6f2d) and FreeBSD
(ca051d8b) for collation versions to store in pg_collation.collversion.
So, from the reverted patch, take a few words
On Sun, Apr 18, 2021 at 1:28 AM Thomas Munro wrote:
> Linux: "Blocked signals are never ignored, since the signal handler
> may change by the time it is unblocked."
I should add, that's what the source says. The man page for
sigpending(2) makes the opposite claim in its NOT
Explain postmaster's treatment of SIGURG.
Add a few words of comment to explain why SIGURG doesn't follow the
dummy_handler pattern used for SIGUSR2, since that might otherwise
appear to be a bug.
Discussion: https://postgr.es/m/4006115.1618577212%40sss.pgh.pa.us
Branch
--
master
Details
On Sat, Apr 17, 2021 at 8:49 AM Tom Lane wrote:
> (I would've thought that a SIG_IGN'd signal would be dropped
> immediately even if blocked; that's the behavior that dummy_handler
> is designed to prevent, and I'm pretty sure that that code is there
> because we saw it actually behaving that way
On Sat, Apr 17, 2021 at 12:46 AM Tom Lane wrote:
> It might be good to extend the comment in postmaster.c though, perhaps
> along the lines of "Ignore SIGURG for now. Child processes may change
> this (see InitializeLatchSupport), but they will not receive any such
> signals until they wait on a
On Thu, Apr 15, 2021 at 10:50 PM Thomas Munro wrote:
> On Thu, Apr 15, 2021 at 2:26 PM Tom Lane wrote:
> > It's possible that that argument doesn't apply to the way SIGURG is used
> > in this patch, but I don't see a good reason to ignore the convention of
> > setting up
Doc: Document known problem with Windows collation versions.
Warn users that locales with traditional Windows NLS names like
"English_United States.1252" won't provide version information, and that
something like initdb --lc-collate=en-US would be needed to fix that
problem for the initial
501 - 600 of 1112 matches
Mail list logo
