On Sat, 20 Mar 2021 at 02:19, John Naylor wrote:
> On Fri, Mar 19, 2021 at 8:57 AM Amit Khandekar wrote:
> > Regarding the alignment changes... I have removed the code that
> > handled the leading identically unaligned bytes, for lack of evidence
> > that percentage of such
On Sat, 17 Jul 2021 at 04:48, John Naylor wrote:
> v17-0001 is the same as v14. 0002 is a stripped-down implementation of Amit's
> chunk idea for multibyte, and it's pretty good on x86. On Power8, not so
> much. 0003 and 0004 are shot-in-the-dark guesses to improve it on Power8,
> with some succes
On Tue, 13 Jul 2021 at 01:15, John Naylor wrote:
> > It seems like it would be easy to have pg_utf8_verify_one in my proposed
> > pg_utf8.h header and replace the body of pg_utf8_verifychar with it.
>
> 0001: I went ahead and tried this for v15, and also attempted some clean-up:
>
> - Rename pg_u
ered savepoints. The restriction is retained for savepoints.
Thanks
-Amit Khandekar
Huawei Technologies
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 441445927e..c46e32ba37 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xac
On Wed, 28 Apr 2021 at 13:54, David Rowley wrote:
> So, given that I removed the parallel test in partition_prune.sql, and
> don't have any EXPLAIN ANALYZE output for parallel tests in
> resultcache.sql, it should be safe enough to put that cache_misses ==
> 0 test back into explain.c
>
> I've at
On Wed, 28 Apr 2021 at 16:14, David Rowley wrote:
> However, I did add 1 test that sets work_mem down to 64kB to ensure
> the eviction code does get some exercise. You'll notice that I pass
> "true" to explain_resultcache() to hide the hits and misses there. We
> can't test the exact number of hi
On Wed, 28 Apr 2021 at 15:08, Bharath Rupireddy
wrote:
>
> On Wed, Apr 28, 2021 at 1:54 PM David Rowley wrote:
> > I plan to push this in the next 24 hours or so.
>
> I happen to see explain_resultcache in resultcache.sql, seems like two
> of the tests still have numbers for cache hits and misses
for workers that are not launched. Attached is a
patch to do the same for Result Cache.
I was earlier thinking about using (instrument[n].nloops == 0) to
check for not-launched workers. But we are already using "if
(rcstate->stats.cache_misses == 0)" for the leader process, so for
if we cannot do anything in the gist index code, then we might have to
bring back the unaligned byte handling. I didn't get a chance to dig
deeper into the gist index implementation to see why they are not
always 8-byte aligned.
I have kept the 0002 patch as-is. Due to significant *additiona
On Tue, 9 Mar 2021 at 17:14, John Naylor wrote:
> On Tue, Mar 9, 2021 at 5:00 AM Amit Khandekar wrote:
> > Just a quick question before I move on to review the patch ... The
> > improvement looks like it is only meant for x86 platforms.
>
> Actually it's meant to b
Hi,
Just a quick question before I move on to review the patch ... The
improvement looks like it is only meant for x86 platforms. Can this be
done in a portable way by arranging for auto-vectorization ? Something
like commit 88709176236caf. This way it would benefit other platforms
as well.
I tri
On Wed, 3 Mar 2021 at 23:32, John Naylor wrote:
> Your performance numbers look like this is a fruitful area to improve. I have
> not yet tested performance, but I will do so at a later date.
Thanks for reviewing the patch !
> I did some
> microbenchmarking of our popcount implementation, since
I have added this one in the March commitfest.
https://commitfest.postgresql.org/32/3023/
On Tue, 15 Dec 2020 at 20:34, Amit Khandekar wrote:
>
> On Sun, 13 Dec 2020 at 9:28 PM, Andrey Borodin wrote:
> > +1
> > This will make all INSERTs and UPDATES for tsvector's GiSTs.
>
> Oh, I didn't realize that this code is getting used in GIST index
> i
On Sun, 13 Dec 2020 at 9:28 PM, Andrey Borodin wrote:
> +1
> This will make all INSERTs and UPDATES for tsvector's GiSTs.
Oh, I didn't realize that this code is getting used in GIST index
insertion and creation too. Will check there.
> Also I really like idea of taking advantage of hardware capa
is good. Still optimize index structure, minimizing disc pages access,
> etc. seems better in many cases.
Sure. Thanks for the pointers.
--
Thanks,
-Amit Khandekar
Huawei Technologies
if we can do some
optimizations. Although, this is unrelated to the optimization of this
mail thread, so this will need a different mail thread.
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Tue, 1 Dec 2020 at 15:33, Krunal Bauskar wrote:
> What I meant was outline-atomics support was added in GCC-9.4 and was made
> default in gcc-10.
> LSE support is present for quite some time.
FWIW, here is an earlier discussion on the same (also added the
proposal author here) :
https://www.
On Thu, 26 Nov 2020 at 10:55, Krunal Bauskar wrote:
> Hardware: ARM Kunpeng 920 BareMetal Server 2.6 GHz. 64 cores (56 cores for
> server and 8 for client) [2 numa nodes]
> Storage: 3.2 TB NVMe SSD
> OS: CentOS Linux release 7.6
> PGSQL: baseline = Release Tag 13.1
> Invocation suite:
> https://
On Thu, 17 Sep 2020 at 08:55, Andres Freund wrote:
>
> Hi,
>
> On 2020-09-17 14:20:50 +1200, Thomas Munro wrote:
> > I wonder if there is a way we could make "Minimal Tuples but with the
> > length travelling separately (and perhaps chopped off?)" into a
> > first-class concept... It's also a sha
ostgresql.org/29/2310/ since I do plan to do some
review on that one.
Thanks,
-Amit Khandekar
Huawei Technologies
aring figures with and
without fix. Use this GUC enable_fix to enable/disable the fix.
[1]
https://www.postgresql.org/message-id/CA%2BhUKGLrN2M18-hACEJbNoj2sn_WoUj9rkkBeoPK7SY427pAnA%40mail.gmail.com
--
Thanks,
-Amit Khandekar
Huawei Technologies
From 5d19626e35e50a5630e5f1a042f7ecee6acb7c70 Mon
then, modern compilers probably prefer the
> memset approach.
Thanks. I must admit it did not occur to me that I could have very
well installed clang on my linux machine and tried compiling this
file, or tested with some older gcc versions. I think I was using gcc
8. Do you know what was the gcc compiler version that gave these
warnings ?
--
Thanks,
-Amit Khandekar
Huawei Technologies
ysis=loop-vectorize]
> for (i2 = 0; i2 <= i; i2++)
Hmm, yeah that's unfortunate. My guess is that the compiler would do
vectorization only if 'i' is a constant, which is not true for our
case.
--
Thanks,
-Amit Khandekar
Huawei Technologies
7;::regclass)"
pg_table_size | pg_table_size
---+---
1261568 | 1687552
pgg:s2:pg$ time psql -c "select NULL from zlibtab where t like ''"
> /dev/null
real 0m0.127s
user0m0.000s
sys 0m0.002s
pgg:s2:pg$ time psql -c "select NULL from lztab where t like ''"
> /dev/null
real0m0.050s
user0m0.002s
sys 0m0.000s
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Mon, 13 Jul 2020 at 14:27, Amit Khandekar wrote:
> I tried this in utils/adt/Makefile :
> +
> +numeric.o: CFLAGS += ${CFLAGS_VECTOR}
> +
> and it works.
>
> CFLAGS_VECTOR also includes the -funroll-loops option, which I
> believe, had showed improvements in the check
can be already some scope for
auto-vectorizations in other similar regions in that file, so we don't
require a separate numeric_vectorize.c and just pass the CFLAGS_VECTOR
flag for this file itself.
[1]
https://www.postgresql.org/message-id/flat/CA%2BU5nML8JYeGqM-k4eEwNJi5H%3DU57oPLBsBDoZUv4cfcmdnpUA%40mail.gmail.com#2ec419817ff429588dd1229fb663080e
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Wed, 17 Jun 2020 at 13:54, Pavel Stehule wrote:
>
>
>
> st 17. 6. 2020 v 7:52 odesílatel Amit Khandekar
> napsal:
>>
>> On Wed, 10 Jun 2020 at 17:12, Pavel Stehule wrote:
>> > st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
>> > napsal:
>&g
FYI : this one is present in the July commitfest.
ust so the cfbot doesn't get confused about what
> it's supposed to test now.
Thanks for pushing all the three !
Thanks,
-Amit Khandekar
Huawei Technologies
On Thu, 2 Jul 2020 at 03:47, Tom Lane wrote:
>
> Amit Khandekar writes:
> > There are a couple of function call overheads I observed in pl/pgsql
> > code : exec_stmt() and exec_cast_value(). Removing these overheads
> > resulted in some performance gains.
>
>
On Wed, 10 Jun 2020 at 17:12, Pavel Stehule wrote:
> st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
> napsal:
>> Could you show an example testcase that tests this recursive scenario,
>> with which your earlier patch fails the test, and this v2 patch passes
>> it ? I
On Wed, 10 Jun 2020 at 04:20, Peter Eisentraut
wrote:
>
> On 2020-06-09 13:50, Amit Khandekar wrote:
> > Also, the regress/sql/numeric_big test itself speeds up by 80%
>
> That's nice. I can confirm the speedup:
>
> -O3 without the patch:
>
>
On Tue, 9 Jun 2020 at 21:49, Pavel Stehule wrote:
> Is your patch in commitfest in commitfest application?
Thanks for reminding me. Just added.
https://commitfest.postgresql.org/28/2590/
f expr->plan.
>
> It doesn't solve performance, and doesn't solve all memory problems, but
> significantly reduce memory requirements from 5007 bytes to 439 bytes per one
> CALL
So now this patch's intention is to reduce memory consumption, and it
doesn't target slowness improvement, right ?
--
Thanks,
-Amit Khandekar
Huawei Technologies
for -O3 it is always true. What we can do
in the future is to have a separate file that has such optimized code
that is proven to work with such optimization flags, and enable the
required compiler flags only for such files, if the build is done with
-O2.
[1] https://gcc.gnu.org/projects/tr
On Mon, 1 Jun 2020 at 12:27, Pavel Stehule wrote:
> po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar
> napsal:
>>
>> On Sat, 30 May 2020 at 11:11, Pavel Stehule wrote:
>> > I think so the effect of these patches strongly depends on CPU and compile
>>
>> I
On Sat, 30 May 2020 at 11:11, Pavel Stehule wrote:
> I think so the effect of these patches strongly depends on CPU and compile
I quickly tried pi() with gcc 10 as well, and saw more or less the
same benefit. I think, we are bound to see some differences in the
benefits across architectures, kern
On Sun, 31 May 2020 at 08:04, Michael Paquier wrote:
> This stuff is interesting. Do you have some perf profiles to share?
> I am wondering what's the effect of the inlining with your test
> cases.
Below are the perf numbers for asignmany.sql :
HEAD :
+ 16.88% postgres postgres [
n is not that big. I
am assuming you were referring to this point when you said it is a bit
against simplicity. But I didn't get what you implied by "but for
PLpgSQL with blocks structure it is correct"
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Tue, 26 May 2020 at 09:06, Amit Khandekar wrote:
>
> On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
> >
> >FOR counter IN 1..180 LOOP
> > id = 0; id = 0; id1 = 0;
> > id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> > id3 = 0; id = 0; id
On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
>
>FOR counter IN 1..180 LOOP
> id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0; id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0;
>END LOOP;
>
> This is no
But inlining exec_stmt() and exec_cast_value() together showed
benefits on both machines, as can be seen above.
--
Thanks,
-Amit Khandekar
Huawei Technologies
From 66c607ef6f0b7b655819b4b19383e024c5f8788c Mon Sep 17 00:00:00 2001
From: Amit Khandekar
Date: Sat, 23 May 2020 21:39:41 +0800
Subject
Subject changed. Earlier it was : spin_delay() for ARM
On Fri, 17 Apr 2020 at 22:54, Robert Haas wrote:
>
> On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar wrote:
> > Not relevant to the PAUSE stuff Note that when the parallel
> > clients reach from 24 to 32 (which equal
; way to do that is with a bunch of concurrent index scans that hit the
> heap in random order. Some notes about that:
>
> https://www.postgresql.org/message-id/flat/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com
Thanks all for the inputs. Will keep these two particular scenarios in
mind, and try to get some bandwidth on this soon.
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Mon, 13 Apr 2020 at 20:16, Amit Khandekar wrote:
> On Sat, 11 Apr 2020 at 04:18, Tom Lane wrote:
> >
> > I wrote:
> > > A more useful test would be to directly experiment with contended
> > > spinlocks. As I recall, we had some test cases laying about when
&g
Ok. Yes, it would be worth waiting to see if there are others in the
community with ARM systems that have implemented YIELD. May be after that
we might gain some confidence. I myself also hope that I will get one soon
to test, but right now I have one that does not support it, so it will be
just a no-op.
--
Thanks,
-Amit Khandekar
Huawei Technologies
--
Thanks,
-Amit Khandekar
Huawei Technologies
On Sat, 11 Apr 2020 at 00:47, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
> > On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
> > using a sample C program (attached spin.c). Here, many child processes
> > (
processor.h#L259
[4] http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html
[5]
http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-August/004880.html
--
Thanks,
-Amit Khandekar
Huawei Technologies
/*
* Sample program to test the effect of PAUSE/YIELD instruction in a highly
* contended scenario
On Fri, 17 Jan 2020 at 13:20, Andreas Joseph Krogh wrote:
>
> På torsdag 16. januar 2020 kl. 05:42:24, skrev Amit Khandekar
> :
>
> On Fri, 10 Jan 2020 at 17:50, Rahila Syed wrote:
> >
> > Hi Amit,
> >
> > Can you please rebase the patches as they don&#
On Fri, 10 Jan 2020 at 17:50, Rahila Syed wrote:
>
> Hi Amit,
>
> Can you please rebase the patches as they don't apply on latest master?
Thanks for notifying. Attached is the rebased version.
logicaldecodng_standby_v5_rebased.tar.gz
Description: GNU Zip compressed data
ck trace ? I mean, can we do
this before getting the patch committed ? I guess, we can run the
build script with a single branch specified, right ?
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
>
> On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
>>
>> On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila wrote:
>>>
>>> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
>>> wrote:
>>> >
>
On Tue, 24 Dec 2019 at 14:02, Amit Khandekar wrote:
>
> On Thu, 19 Dec 2019 at 01:02, Rahila Syed wrote:
> >
> > Hi,
> >
> >> Hi, do you consistently get this failure on your machine ? I am not
> >> able to get this failure, but I am going to a
On Tue, 24 Dec 2019 at 10:41, Amit Kapila wrote:
>
> On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar wrote:
> > Attached are the patches from master back up to 94 branch.
> >
> > PG 9.4 and 9.5 have a common patch to be applied :
> > pg94_95_use_vfd_for_logrep.patch
issue is :
on master, the catalog_xmin does not immediately get updated. It
happens only after the hot standby feedback reaches on master. And I
haven't used wait_for_xmins() for these failing cases. I should use
that. Working on the same ...
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Thu, 19 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Wed, Dec 18, 2019 at 12:34 PM Amit Khandekar
> wrote:
> >
> > On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> > > By the way, the backport patch is turning out to be simpler. It's
> > > be
On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> By the way, the backport patch is turning out to be simpler. It's
> because in pre-12 versions, the file offset is part of the Vfd
> structure, so all the offset handling is not required.
Please have a look at the attached back
On Mon, 16 Dec 2019 at 16:52, Amit Kapila wrote:
>
> On Mon, Dec 16, 2019 at 3:26 PM Amit Khandekar wrote:
> >
> > On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
> > >
> > > I have also made minor changes related to below code in patch:
On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 9:50 PM Amit Khandekar wrote:
> >
> > Attached is a v4 patch that also addresses your code comments so far.
> > I have included the test case in 006_logical_decoding.pl. I observed
> > tha
gt; executing this query:
> #
>
> Physical catalog_xmin is NULL on master after logical slot creation on
> standby .
Hi, do you consistently get this failure on your machine ? I am not
able to get this failure, but I am going to analyze when/how this can
fail. Thanks
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Thu, 12 Dec 2019 at 14:18, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar
> wrote:
> >
> > On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> >
> > > So max_changes_in_memory is the one
> > > that allows us to redu
On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> So max_changes_in_memory is the one
> that allows us to reduce the number of transactions required, so we
> can cut down on the outer loop iterations and make the test finish
> much earlier.
>
> But also note that, we
On Thu, 12 Dec 2019 at 09:49, Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 4:17 PM Amit Khandekar wrote:
> >
> > On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
> > >
> > > On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar
> > > wrote:
> > &
On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
>
> On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar wrote:
> >
> > On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> > >
> > >
> > > Few comments:
> > > --
> > >
&g
On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
>
> On Thu, Dec 5, 2019 at 4:20 PM Amit Kapila wrote:
> >
> > On Tue, Dec 3, 2019 at 11:10 AM Amit Khandekar
> > wrote:
> > >
> > >
> > > Done as stated above; attached v3 patch. I have ve
On Wed, 27 Nov 2019 at 14:16, Amit Khandekar wrote:
> What I found was : We do attempt to close the opened vfds in the
> PG_CATCH block. In ReorderBufferCommit(), ReorderBufferIterTXNFinish
> is called both in PG_TRY and PG_CATCH. This closes all the opened
> vfds. But the issue
On Tue, 26 Nov 2019 at 12:10, Amit Kapila wrote:
>
> On Tue, Nov 26, 2019 at 11:19 AM Amit Khandekar
> wrote:
> >
> > On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
> > >
> > >
> > > So, what is the next step here? How about if we somehow
On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
>
> On Fri, Nov 22, 2019 at 7:38 PM Amit Khandekar wrote:
> >
> > On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
> >>
> >> I think this is exactly the reason for the problem. In my test [1],
> >>
On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
> On Fri, Nov 22, 2019 at 11:00 AM Amit Khandekar
> wrote:
> >
> > On Fri, 22 Nov 2019 at 09:08, Amit Kapila
> wrote:
> > > Have you tried before that fix , if not, can you once try by
> > > temporarily
remains
open, and later even when the unlink() succeeds, the file will be left
there until it is closed. So subsequent operations will open the same
old file. Not sure what happens if we open a file that is marked for
deletion.
-
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Data
pening despite the file being
opened using FILE_SHARE_DELETE flag. I am going to investigate
(possibly the flag is not applicable in case a single process is
involved)
2. This existing issue where pg_replslot/slotname directory removal
will fail if someone else is accessing this directory. T
ed use-case. Having a new API will require all the
changes required to enable the virtual FDs feature that we need from
vfd. If nothing works out from the FILE_SHARE_DELETE thing, I am
thinking, we can use VFD, plus we can keep track of per-subtransaction
vfd handles, and do something similar to AtEOSu
On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
>
> On Tue, Nov 19, 2019 at 4:58 PM Amit Khandekar wrote:
> >
> > On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> > >
> > >
> > > Have you tried by injecting some error? After getting the error
&
end-of file, including the whole BLCKSZ.
- BufFileLoadBuffer() seems to deliberately ignore FileRead()'s return
value if it is -1
if (file->nbytes < 0) file->nbytes = 0;
- XLogPageRead() also seems to know that the offset is a valid offset.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
>
> On Mon, Nov 18, 2019 at 5:50 PM Amit Khandekar wrote:
> >
> > On Mon, 18 Nov 2019 at 17:20, Amit Kapila wrote:
> > > I see that you have made changes in ReorderBufferRestoreChanges to use
> &g
h
ReleaseLruFiles(). Whereas, for files opened through
OpenTransientFile(), VfdCache is not involved, so this needs
transaction end cleanup.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
with the patch applied, then this
needs investigation.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
slot gets dropped.
> IIUC, you mean `if any required rows get removed on *the master* the slot gets
> dropped`, right?
Yes, you are right. In fact, I think it is not necessary to explicitly
mention where the rows get removed. So I have just omitted "on
standby". Will include thi
the sleeps from the patch-series version
4 onwards.
By the way, the couple of patches out of the patch series had
bitrotten. Attached is the rebased version.
Thanks
-Amit Khandekar
logicaldecodng_standby_v4_rebased.tar.gz
Description: application/gzip
On Wed, 18 Sep 2019 at 12:24, Amit Khandekar wrote:
> Probably, for now at least, what everyone seems to agree is to take my
> earlier attached patch forward.
>
> I am going to see if I can add a TAP test for the patch, and will add
> the patch into the commitfest soon.
Attache
On Mon, 30 Sep 2019 at 23:38, Robert Haas wrote:
>
> On Mon, Sep 30, 2019 at 7:35 AM Amit Khandekar wrote:
> > Alright. Attached is the updated patch that splits the file into two
> > files, one that does only xmin related testing, and the other test
> > file that
On Fri, 27 Sep 2019 at 23:21, Robert Haas wrote:
>
> On Fri, Sep 27, 2019 at 12:41 PM Amit Khandekar
> wrote:
> > Preferably I want wait_for_xmins() to get rid of the $node parameter,
> > because we can deduce it using slot name. But that requires having
> > get
On Fri, 27 Sep 2019 at 01:57, Robert Haas wrote:
>
> On Thu, Sep 26, 2019 at 5:14 AM Amit Khandekar wrote:
> > Actually in some of the conflict-recovery testcases, I am still using
> > wait_for_xmins() so that we could test the xmin values back after we
> > drop th
-related testing and another for the recovery conflict
> testing.
Actually in some of the conflict-recovery testcases, I am still using
wait_for_xmins() so that we could test the xmin values back after we
drop the slots. So xmin-related testing is embedded in these recovery
tests as well. We can mo
On Tue, 17 Sep 2019 at 21:19, Andres Freund wrote:
> On 2019-09-14 14:34:21 -0400, Tom Lane wrote:
> > Amit Khandekar writes:
> > > Yeah, something like the attached patch. I think this tracking of
> > > offsets would have been cleaner if we add in-built support in VF
in VFD. But
yeah, for bank branches at least, we need to handle it outside of VFD.
Or may be we would add it if we find one more use-case.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
use_vfd_for_logrep.patch
Description: Binary data
fd cached file
is closed and reopened. Robert, are you suggesting to add this
capability to VFD ? I agree that we could do it, but for
back-patching, offhand I couldn't think of a simpler way.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Mon, 9 Sep 2019 at 16:06, Amit Khandekar wrote:
>
> On Tue, 3 Sep 2019 at 23:10, Alvaro Herrera wrote:
> >
> > On 2019-Jul-19, Amit Khandekar wrote:
> >
> > > Attached are the split patches. Included is an additional patch that
> > > has doc chan
rning from ReorderBufferRestoreChanges(), and keep track of
the file offset and file path, so that next time we can resume reading
from there.
Comments ?
[1]
https://www.postgresql.org/message-id/flat/738a590a-2ce5-9394-2bef-7b1caad89b37%402ndquadrant.com
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Tue, 3 Sep 2019 at 23:10, Alvaro Herrera wrote:
>
> On 2019-Jul-19, Amit Khandekar wrote:
>
> > Attached are the split patches. Included is an additional patch that
> > has doc changes. Here is what I have added in the docs. Pasting it
> > here so that all can easily
we only discard when the
+ * rm_undo_status callback tells us we can.
+ */
+status = RmgrTable[uur->uur_rmid].rm_undo_status(uur,
&wait_xid);
status variable could be declared in this block itself.
-
Some variable declaration alignments and comments spacing need changes
as per pgindent.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
On Tue, 23 Jul 2019 at 08:48, Amit Kapila wrote:
>
> On Mon, Jul 22, 2019 at 8:39 PM Amit Khandekar wrote:
> >
> > On Mon, 22 Jul 2019 at 14:21, Amit Kapila wrote:
> >
> > -
> >
> > +UndoWorkerGetSlotInfo(int slot, UndoRequestInfo *urinf
On Fri, 19 Jul 2019 at 17:24, Amit Khandekar wrote:
>
> On Thu, 9 May 2019 at 12:04, Dilip Kumar wrote:
>
> > Patches can be applied on top of undo branch [1] commit:
> > (cb777466d008e656f03771cf16ec7ef9d6f2778b)
> >
> > [1] https://github.com/EnterpriseDB/z
On Mon, 22 Jul 2019 at 14:21, Amit Kapila wrote:
I have started review of
0014-Allow-execution-and-discard-of-undo-by-background-wo.patch. Below
are some quick comments to start with:
+++ b/src/backend/access/undo/undoworker.c
+#include "access/xact.h"
+#include "access/undorequest.h"
Order is
e
mask_size. Probably abs() should do the work.
Also, an Assert(cid_data + mask_size <= page_end) would be nice. I
know cid position of a partial record cannot go beyond the page
boundary, but it's better to have this Assert to do sanity check.
+ * Process the undo record of the page a
On Wed, 10 Jul 2019 at 17:12, Amit Khandekar wrote:
>
> On Wed, 10 Jul 2019 at 08:44, Andres Freund wrote:
> >
> > Hi,
> >
> > Thanks for the new version! Looks like we're making progress towards
> > something committable here.
> >
> > I th
On Tue, 16 Jul 2019 at 22:56, Andres Freund wrote:
>
> Hi,
>
> On 2019-07-12 14:53:21 +0530, tushar wrote:
> > On 07/10/2019 05:12 PM, Amit Khandekar wrote:
> > > All right. Will do that in the next patch set. For now, I have quickly
> > > done the below chang
+ * standby, then it has to be killed so as to
> > release an
> > + * acquired logical slot.
> > + */
> > + if (am_cascading_walsender &&
> > + reason ==
> > PROCSIG_RECOVERY_CONFLICT_LOGICALSLOT &&
> > + MyReplicationSlot &&
> > SlotIsLogical(MyReplicationSlot))
> > + {
> > + RecoveryConflictPending = true;
> > + QueryCancelPending = true;
> > + InterruptPending = true;
> > + break;
> > + }
>
> Huh, I'm not following as to why that's needed for walsenders?
For normal backends, we ignore this signal if we aren't in a
transaction (block). But for walsender, there is no transaction, but
we cannot ignore the signal. This is because walsender can keep a
logical slot acquired when it was spawned by "pg_recvlogical --start".
So we can't ignore the signal. So the only way that we can make it
release the acquired slot is to kill it.
>
>
> > @@ -1499,6 +1499,7 @@ pg_stat_get_db_conflict_all(PG_FUNCTION_ARGS)
> >
> > dbentry->n_conflict_tablespace +
> > dbentry->n_conflict_lock +
> >
> > dbentry->n_conflict_snapshot +
> > +
> > dbentry->n_conflict_logicalslot +
> >
> > dbentry->n_conflict_bufferpin +
> >
> > dbentry->n_conflict_startup_deadlock);
>
> I think this probably needs adjustments in a few more places,
> e.g. monitoring.sgml...
Oops, yeah, to search for similar additions, I had looked for
"conflict_snapshot" using cscope. I should have done the same using
"git grep".
Done now.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
logical-decoding-on-standby_v12.patch
Description: Binary data
On Thu, 4 Jul 2019 at 17:21, Amit Khandekar wrote:
>
> On Thu, 4 Jul 2019 at 15:52, tushar wrote:
> >
> > On 07/01/2019 11:04 AM, Amit Khandekar wrote:
> >
> > Also, in the updated patch (v11), I have added some scenarios that
> > verify that slot is dro
1 - 100 of 239 matches
Mail list logo
