doc: Fix typos
introduced by 222b697ec077047024a96392a2f5cb9b1803ccf7
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a6f12520bed073d1d548a691e85d7f5371cc4ed4
Modified Files
--
doc/src/sgml/func.sgml | 8
1 file changed, 4 insertions(+), 4 delet
Fix some whitespace in documentation markup
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7d6a4fdf3243a7a18e2cfc6cf03bce01cc6ce651
Modified Files
--
doc/src/sgml/func.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Update SQL features
Update a few items that have become supported or mostly supported but
weren't updated at the time.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7e367924e33e47e0b0b135b0649c406a589bd496
Modified Files
--
src/backend/catalog/sql_fea
Fix typo in origin.c
Introduced in 5aa2350.
Author: Peter Smith
Discussion:
https://postgr.es/m/cahut+psuwz6_7acmivnu5fahgqxdutqtc3+__xnwkbzqcfn...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/59a32f00937c85fe944cf1fac3e8b98d091e2bc6
Modified Fi
Clear the OpenSSL error queue before cryptohash operations
Setting up an EVP context for ciphers banned under FIPS generate
two OpenSSL errors in the queue, and as we only consume one from
the queue the other is at the head for the next invocation:
postgres=# select md5('foo');
ERROR: could
pgcrypto: remove questionmark from error message
The PXE_CIPHER_INIT error is used to report initialization errors, so
appending a questionmark to the error isn't entirely accurate (using a
space before the questionmark doubly so).
Discussion: https://postgr.es/m/c89d932c-501e-4473-9750-638cfcd90
pgcrypto: report init errors as PXE_CIPHER_INIT
Report OpenSSL errors during initialization as PXE_CIPHER_INIT since
that's just what they were, and not generic unknown errors. This also
removes the last users of the generic error, and thus it can be removed.
Discussion: http://postgr.es/m/c89d93
On 03.05.22 03:11, Andres Freund wrote:
Backpatch addition of wait_for_log(), pump_until().
These were originally introduced in a2ab9c06ea1 and a2ab9c06ea1, as they are
needed by a about-to-be-backpatched test.
I see this warning:
Subroutine pump_until redefined at t/013_crash_restart.pl line
Fix misleading comments about background worker registration.
Since 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c, the maximum number
of backends can't change as background workers are registered, but
these comments still reflect the way things worked prior to that.
Also, per recent discussion, some m
On 2022-05-02 Mo 03:06, Michael Paquier wrote:
> On Sun, May 01, 2022 at 10:18:37AM -0400, Andrew Dunstan wrote:
>> IIRC we know that tar will be available on Windows.
> What about gzip? Are the binaries and the libraries split into
> different packages for this package manager on Windows? We'v
Hi,
Not sure if these compiler-mutterings are worth reporting but I guess
we're trying to get a silent compile.
System: Debian 4.9.303-1 (2022-03-07) x86_64 GNU/Linux
Compiling with gcc 12.1.0 causes the below 'warning' and 'note'.
Compiling with --enable-cassert --enable-debug is silent, no
Backpatch addition of pump_until() more completely.
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realiz
Backpatch addition of pump_until() more completely.
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realiz
Backpatch addition of pump_until() more completely.
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realiz
Backpatch addition of pump_until() more completely.
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realiz
Hi,
On 2022-05-06 15:29:43 +0200, Peter Eisentraut wrote:
> On 03.05.22 03:11, Andres Freund wrote:
> > Backpatch addition of wait_for_log(), pump_until().
> >
> > These were originally introduced in a2ab9c06ea1 and a2ab9c06ea1, as they are
> > needed by a about-to-be-backpatched test.
>
> I see
Temporarily skip recovery deadlock test in back branches.
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleare
Temporarily skip recovery deadlock test in back branches.
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleare
Temporarily skip recovery deadlock test in back branches.
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleare
Temporarily skip recovery deadlock test in back branches.
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleare
Temporarily skip recovery deadlock test in back branches.
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleare
On Fri, May 06, 2022 at 10:12:36AM -0400, Andrew Dunstan wrote:
> On 2022-05-02 Mo 03:06, Michael Paquier wrote:
> vcpkg doesn't install any.exe files AFAICS, just DLLs, headers, .lib
> files etc.
Okay, thanks for confirming.
>>> I don't think we should do that check for every time we call
>>> vc
Fix old-fd issues using global barriers everywhere.
Commits 4eb21763 and b74e94dc introduced a way to force every backend to
close all relation files, to fix an ancient Windows-only bug.
This commit extends that behavior to all operating systems and adds
a couple of extra barrier points, to fix a
Rethink PROCSIGNAL_BARRIER_SMGRRELEASE.
With sufficiently bad luck, it was possible for IssuePendingWritebacks()
to reopen a file after we'd processed PROCSIGNAL_BARRIER_SMGRRELEASE and
before the file was unlinked by some other backend. That left a small
hole in commit 4eb21763's plan to fix all
24 matches
Mail list logo
