On Fri, Jul 30, 2021 at 6:17 PM Michael Paquier wrote:
>
> Hi Amit,
>
> On Wed, Jul 14, 2021 at 02:41:43AM +, Amit Kapila wrote:
> > Add support for prepared transactions to built-in logical replication.
>
> 021_twophase.pl, that has been introdeuced in this commit, is proving
> to be a bit un
On Fri, Jul 30, 2021 at 02:03:32PM -0400, Andrew Dunstan wrote:
> It's working. You can re-re-enable the tests.
Thanks! I have just re-enabled the tests. I wasn't really useful
here at the end :)
--
Michael
signature.asc
Description: PGP signature
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 runs or EACCES failures when writing
compressed WAL segme
Fix expect file for MinGW32 ECPG regression tests
On versions 11 and earlier, MinGW32 has a separate expect file for the
regression test changed by master commit 5fcf3945b.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fa27389c53ca095f52b146d8bdfeb62e8d7f4f
Fix expect file for MinGW32 ECPG regression tests
On versions 11 and earlier, MinGW32 has a separate expect file for the
regression test changed by master commit 5fcf3945b.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f3cd6aeb8d8e000414622bf07d26996ee1c5bc
Fix expect file for MinGW32 ECPG regression tests
On versions 11 and earlier, MinGW32 has a separate expect file for the
regression test changed by master commit 5fcf3945b.
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9455e7f5050fdc82ead9858b3aa531cc830b3b
Member walleye doesn't like this, since there is a separate .stdout file
for MinGW32. Will fix.
--
John Naylor
EDB: http://www.enterprisedb.com
Improve documentation for START_REPLICATION ... LOGICAL.
The starting point may not be exactly what the client requested; it
may be at the slot's confirmed_flush_lsn.
Also, upgrade the message from DEBUG1 to LOG when this happens.
Reviewed-by: Amit Kapila
Discussion:
https://postgr.es/m/c5c861d
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Fix range check in ECPG numeric to int conversion
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion:
https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.or
Doc: add a glossary entry for "domain".
Anton Voloshin and Jürgen Purtz, reviewed by Laurenz Albe
Discussion:
https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3dddb2a8219d3cfd163a83561d4b4613cd
On 7/30/21 8:40 AM, Michael Paquier wrote:
>
>> I will see if a more modern zlib helps matters.
It's working. You can re-re-enable the tests.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
In postgres_fdw, allow CASE expressions to be pushed to the remote server.
This is simple enough except for the need to check whether CaseTestExpr
nodes have a collation that is not derived from a remote Var. For that,
examine the CASE's "arg" expression and then pass that info down into the
recu
Hi Michael-san,
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 buildfarm here, like:
> https://buildfarm.postgresql.or
Hi Amit,
On Wed, Jul 14, 2021 at 02:41:43AM +, Amit Kapila wrote:
> Add support for prepared transactions to built-in logical replication.
021_twophase.pl, that has been introdeuced in this commit, is proving
to be a bit unstable:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiaca
Hi Fujita-san,
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 buildfarm here, like:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2021-07-30%2011%3A30%3A04
This i
On Fri, Jul 30, 2021 at 07:42:45AM -0400, Andrew Dunstan wrote:
> Well that unsticks the test, so now it fails in an ordinary way, so +1
> for doing that. I must say that --no-loop seems a little ill-designed.
> Effectively we have to choose between zero loops and infinite loops.
> But that seems
Remove unnecessary call to ReadCheckpointRecord().
It should always be the case that the last checkpoint record is still
readable, because otherwise, a crash would leave us in a situation
from which we can't recover. Therefore the test removed by this patch
should always succeed. For it to fail, e
Use --no-loop for new calls of pg_receivewal --endpos in TAP tests
Those tests are not designed to fail, but if they do, like on some cases
for Windows because of ZLIB (?), they could remain stuck. Using
--no-loop makes the test fail immediately. The oldest test with
--endpos already did that.
On 7/29/21 8:29 PM, Michael Paquier wrote:
> On Thu, Jul 29, 2021 at 01:26:22PM -0400, Andrew Dunstan wrote:
>> It gets stuck in a loop like this:
>>
>> ok 19 - one partial WAL segment was created
>> 0/2001968
>> # Running: pg_receivewal -D
>> H:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_baseback
Update obsolete comment that still referred to CheckpointLock
CheckpointLock was removed in commit d18e75664a, and commit ce197e91d0
updated a leftover comment in CreateCheckPoint, but there was another
copy of it in CreateRestartPoint still.
Branch
--
master
Details
---
https://git.post
Update obsolete comment that still referred to CheckpointLock
CheckpointLock was removed in commit d18e75664a, and commit ce197e91d0
updated a leftover comment in CreateCheckPoint, but there was another
copy of it in CreateRestartPoint still.
Branch
--
REL_14_STABLE
Details
---
https://g
postgres_fdw: Fix handling of pending asynchronous requests.
A pending asynchronous request is handled by process_pending_request(),
which previously not only processed an in-progress remote query but
performed ExecForeignScan() to produce a tuple to return to the local
server asynchronously from
postgres_fdw: Fix handling of pending asynchronous requests.
A pending asynchronous request is handled by process_pending_request(),
which previously not only processed an in-progress remote query but
performed ExecForeignScan() to produce a tuple to return to the local
server asynchronously from
29 matches
Mail list logo
