On Sat, Jul 31, 2021 at 07:16:22AM -0400, Andrew Dunstan wrote:
> And now jacana is unhappy. I'll get it fixed shortly. If it ends up that
> we have somehow found a situation where Msys/Mingw and MSVC can no
> longer share a zlib implementation I'm going to be unhappy too.
In the worse case, could
Doc: alphabetize the regexp_foo() function descriptions in 9.7.3.
For no visible reason (other than historical accident no doubt),
regexp_replace() was out of order. Re-order to match the way
that these functions are listed in 9.4. (That means substring()
remains first, because it's SQL-standard
Etsuro Fujita writes:
> I couldn’t reproduce this in my environment, but I noticed this, which
> didn’t happen in my environment: the case of delivering notifications
> to both of the parent async-capable nodes in ExecAppendAsyncEventWait
> when processing the added test case query. In that case,
Use elog, not Assert, to report failure to provide an outer snapshot.
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple
Use elog, not Assert, to report failure to provide an outer snapshot.
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple
Use elog, not Assert, to report failure to provide an outer snapshot.
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple
Use elog, not Assert, to report failure to provide an outer snapshot.
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple
Use elog, not Assert, to report failure to provide an outer snapshot.
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple
On Fri, Jul 30, 2021 at 10:00 PM Etsuro Fujita wrote:
> On Fri, Jul 30, 2021 at 9:45 PM Michael Paquier wrote:
> > On Fri, Jul 30, 2021 at 08:08:07AM +, Etsuro Fujita wrote:
> > > postgres_fdw: Fix handling of pending asynchronous requests.
> >
> > You have angered many members of the buildfa
Remove redundant setting of pg_attribute.attcompression
Since e6241d8e0, no attribute needs a non-default value of this during
initdb, so let the usual machinery for defaults take care of it.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/89404a01b4dadab8231dfa08ca
On 7/30/21 9:28 PM, Michael Paquier wrote:
> Enable TAP tests of pg_receivewal for ZLIB on Windows, take three
>
> This reverts commit 6a2c532. fairywren and bowerbird failed those tests
> because of incorrect versions of ZLIB linked to, causing errors like
> SIGBREAKs that stopped buildfarm run
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Fix corner-case errors and loss of precision in numeric_power().
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
Don't use O_SYNC or similar when opening signal file to fsync it.
No need to use get_sync_bit() when we're calling pg_fsync() on the file.
We're not writing to the files, so it doesn't make any difference in
practice, but seems less surprising this way.
Reviewed-by: Andres Freund
Discussion:
htt
Move InRecovery and standbyState global vars to xlogutils.c.
They are used in code that runs both during normal operation and during
WAL replay, and needs to behave differently during replay. Move them to
xlogutils.c, because that's where we have other helper functions used by
redo routines.
Revi
Remove unnecessary 'restoredFromArchive' global variable.
It might've been useful for debugging purposes, but meh. There's
'readSource' which does almost the same thing.
Reviewed-by: Andres Freund
Discussion:
https://www.postgresql.org/message-id/b3b71061-4919-e882-4857-27e370ab134a%40iki.fi
Br
Extract code to describe recovery stop reason to a function.
StartupXLOG() is very long, this makes it a little bit more readable.
Reviewed-by: Andres Freund
Discussion:
https://www.postgresql.org/message-id/b3b71061-4919-e882-4857-27e370ab134a%40iki.fi
Branch
--
master
Details
---
htt
22 matches
Mail list logo
