Hi hackers,
During logical replication, if there is a large write transaction, some
spill files will be written to disk, depending on the setting of
logical_decoding_work_mem.
This behavior can effectively avoid OOM, but if the transaction
generates a lot of change before commit, a large number
(Moving discussion from -bugs [1] to -hackers for more visibility.)
Background:
This started out as a performance fix for bug #17540 but has now
extended beyond that as fixing that only requires we don't add
redundant IS NOT NULL quals to Min/Max aggregate rewrites. The
attached gets rid of all
On 2023-Dec-07, Erik Rijkers wrote:
> Hm, this set doesn't apply for me. 0003 gives error, see below (sorrty for
> my interspersed bash echoing - seemed best to leave it in.
> (I'm using patch; should be all right, no? Am I doing it wrong?)
There's definitely something wrong with the patch file;
Hi,
I read the V6 patch and found something needs to be improved.
Prepared transactions should also be documented.
A value of zero (the default) disables the timeout.
+This timeout is not applied to prepared transactions. Only transactions
+with user connections are
two JsonCoercionState in src/tools/pgindent/typedefs.list.
+JsonCoercionState
JsonConstructorExpr
JsonConstructorExprState
JsonConstructorType
JsonEncoding
+JsonExpr
+JsonExprOp
+JsonExprPostEvalState
+JsonExprState
+JsonCoercionState
+ post_eval->jump_eval_coercion =
echoing - seemed best to leave it in.
(I'm using patch; should be all right, no? Am I doing it wrong?)
-- [2023.12.07 11:29:39 json_table2] patch 1 of 5 (json_table2)
[/home/aardvark/download/pgpatches/0170/json_table/20231207/v29-0001-Add-soft-error-handling-to-some-expression-nodes.patch]
rv
On Mon, Nov 13, 2023 at 7:02 PM Bharath Rupireddy
wrote:
>
> On Fri, Nov 10, 2023 at 2:28 AM Andres Freund wrote:
>
> > I think the code needs to make sure that *never* happens. That seems
> > unrelated
> > to holding or not holding WALBufMappingLock. Even if the page header is
> > already
On 06.12.23 22:08, Matthias van de Meent wrote:
PFA a patch that reduces the output size of nodeToString by 50%+ in
most cases (measured on pg_rewrite), which on my system reduces the
total size of pg_rewrite by 33% to 472KiB. This does keep the textual
pg_node_tree format alive, but reduces its
Hi Yong!
+1 to the idea to protect SLRUs from corruption. I'm slightly leaning towards
the idea of separating checksums from data pages, but anyway this checksums are
better than no checksums.
> On 7 Dec 2023, at 10:06, Li, Yong wrote:
>
> I am still working on patching the pg_upgrade. Just
On 05.12.23 11:55, Peter Eisentraut wrote:
I think the implementation would be very simple, something like
diff --git a/src/backend/utils/error/elog.c
b/src/backend/utils/error/elog.c
index 6aeb855e49..45d40abe92 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
Hi all,
I was trying to cross-compile PostgreSQL 16.1 using Buildroot which worked fine
until I executed "initdb" on my target device, where I faced the following
error:
2023-12-06 07:10:18.568 UTC [31] FATAL: could not load library
"/usr/lib/postgresql/dict_snowball.so":
Hi,
On 12/7/23 10:07 AM, shveta malik wrote:
On Thu, Dec 7, 2023 at 1:19 PM Drouvot, Bertrand
wrote:
Might be worth to add comments in the code (around the WalRcv->latestWalEnd
checks) that no "lagging" sync are possible if the walreceiver is not started
though?
I am a bit confused. Do you
On Thu, Dec 7, 2023 at 1:19 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 12/6/23 11:58 AM, shveta malik wrote:
> > On Wed, Dec 6, 2023 at 3:00 PM Drouvot, Bertrand
> > wrote:
> >>
> >> Hi,
> >>
> >> On 12/6/23 7:18 AM, shveta malik wrote:
> >>> On Wed, Dec 6, 2023 at 10:56 AM Amit Kapila
> >>>
Hello Thomas,
03.12.2023 09:00, Thomas Munro wrote:
On Sun, Dec 3, 2023 at 6:00 PM Alexander Lakhin wrote:
I've managed to reproduce the failure locally when running postgres_fdw_x/
regress in parallel (--num-processes 10). It reproduced for me on
on 04a09ee94 (iterations 1, 2, 4), but not on
On Thu, Dec 7, 2023 at 1:05 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 6 Dec 2023 22:07:51 +0800,
> Junwang Zhao wrote:
>
> > Should we extract both *copy to* and *copy from* for the first step, in that
> >
On Wed, Dec 06, 2023 at 11:00:01AM +0300, Alexander Lakhin wrote:
> So it looks like
> my $newregresssrc = "$srcdir/src/test/regress";
> is incorrect for meson.
> Maybe it should be?:
> my $newregresssrc = dirname($ENV{REGRESS_SHLIB});
> (With this line the test passes for me on Windows
On Thu, Dec 7, 2023 at 8:39 AM Michael Paquier wrote:
>
> On Wed, Dec 06, 2023 at 10:07:51PM +0800, Junwang Zhao wrote:
> > I read the thread[1] you posted and I think Andres's suggestion sounds
> > great.
> >
> > Should we extract both *copy to* and *copy from* for the first step, in that
> >
On Fri, 1 Dec 2023 at 14:30, David Rowley wrote:
>
> On Fri, 1 Dec 2023 at 13:14, Andres Freund wrote:
> > So I think adding an assert to ExecCopySlot(), perhaps with a comment saying
> > that the restriction could be lifted with a bit of work, would be fine.
>
> How about the attached? I wrote
Here are a couple of small patches to tidy up the parser a bit in your
v28-0004 (JSON_TABLE) patch. It's not a lot; the rest looks okay to me.
(I don't have an opinion on the concurrent discussion on resolving
some precedence issues.)
From 0dc7e7852702272f0bf12aaa4b56b9ac60c4d969 Mon Sep 17
On Mon, Sep 25, 2023 at 3:11 PM Richard Guo wrote:
> If the grouping expression is a Var or PHV, we can just set its
> nullingrels, very straightforward. For an expression that is neither a
> Var nor a PHV, I'm not quite sure how to set the nullingrels. I tried
> the idea of wrapping it in a
Hi.
Here are my review comments for patch v43-0002.
==
Commit message
1.
The nap time of worker is tuned according to the activity on the primary.
The worker starts with nap time of 10ms and if no activity is observed on
the primary for some time, then nap time is increased to 10sec. And if
101 - 121 of 121 matches
Mail list logo
