--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 5421c567a168705272bde425a02eb248c4468cb0 Mon Sep 17 00:00:00 2001
From: dilipkumar
Date: Thu, 16 Jul 2020 11:41:28 +0530
Subject: [PATCH v1] Provide a GUC to allow vacuum to continue on corrupted
tuple
A new GUC to control whether
On Thu, Jul 16, 2020 at 8:44 AM Amit Kapila wrote:
>
> On Wed, Jul 15, 2020 at 8:06 AM Amit Kapila wrote:
> >
> > On Wed, Jul 15, 2020 at 12:32 AM Robert Haas wrote:
> > >
> > > On Sat, Jul 11, 2020 at 8:37 AM Dilip Kumar wrote:
> > > > I h
On Wed, Jul 15, 2020 at 6:59 PM Amit Kapila wrote:
>
> On Wed, Jul 15, 2020 at 9:29 AM Dilip Kumar wrote:
> >
> >
> > I have reviewed your changes and those look good to me, please find
> > the latest version of the patch set.
> >
>
> I have do
he updated
> value for wal_retrieve_retry_interval in ApplyLauncherMain.
>
> Attached is a patch having this change.
>
> Thoughts?
Yeah, it just looks like a typo so your fix looks good to me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jul 13, 2020 at 10:47 AM Dilip Kumar wrote:
>
> On Sun, Jul 12, 2020 at 9:56 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 6, 2020 at 11:43 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila
> > > wrote:
> > >
On Mon, Jul 13, 2020 at 4:00 PM Amit Kapila wrote:
>
> On Mon, Jul 13, 2020 at 3:04 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote:
> > >
> > > On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote:
> > > >
>
On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek wrote:
>
> Hi,
>
> On 14/07/2020 10:29, Amit Kapila wrote:
> > On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar wrote:
> >>
> >> On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila
> >> wrote:
> >&g
On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila wrote:
>
> On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar wrote:
> >
> > I have just notice that the parallelism is off even for the select
> > part of the query mentioned in the $subject. I see the only reason it
> > is n
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila wrote:
>
> On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila wrote:
> > >
> > > On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek wrote:
> > > >
send origin_lsn earlier than that then we need to record it
> > > with other WAL records (other than Commit WAL record).
> > >
> >
> > If we were to support the origin forwarding, then strictly speaking we
> > need everything only at commit time from correctn
On Mon, Jul 13, 2020 at 4:00 PM Amit Kapila wrote:
>
> On Mon, Jul 13, 2020 at 3:04 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote:
> > >
> > > On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote:
> > > >
>
On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote:
>
> On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila
> > wrote:
> > >
> > >
> > > I think you can refer to commit message as well
On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila wrote:
>
> On Mon, Jul 13, 2020 at 10:40 AM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 10:14 AM Amit Kapila
> > wrote:
> > >
> > > On Fri, Jul 10, 2020 at 3:37 PM Dilip Kumar wrote:
> >
On Sun, Jul 12, 2020 at 9:56 PM Dilip Kumar wrote:
>
> On Mon, Jul 6, 2020 at 11:43 AM Dilip Kumar wrote:
> >
> > On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
> > >
> > > On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote:
> > > >
>
On Mon, Jul 13, 2020 at 10:14 AM Amit Kapila wrote:
>
> On Fri, Jul 10, 2020 at 3:37 PM Dilip Kumar wrote:
> >
> > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote:
> > >
> > >
> > > 8. We can't stream the transaction before we reach the
> &
On Mon, Jul 6, 2020 at 11:43 AM Dilip Kumar wrote:
>
> On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
> >
> > On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote:
> > >
> > > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila
101.979 rows=33 loops=3)
Filter: (a < 100)
Rows Removed by Filter: 00
Planning Time: 0.154 ms
Execution Time: 110.158 ms
(9 rows)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
POC_parallel_insert_into.patch
Description: Binary data
. However, I agree during start replication
slot we might decode some of the extra walls of the transaction for
which we already got the commit confirmation and we must have a way to
avoid that. But I think we don't need to do anything for the
CONSISTENT snapshot point. What's your thought on this?
@@ -1016,6 +1016,12 @@ CreateReplicationSlot(CreateReplicationSlotCmd *cmd)
WalSndPrepareWrite, WalSndWriteData,
WalSndUpdateProgress);
+ /*
+ * Make sure streaming is disabled here - we may have the methods,
+ * but we don't have anywhere to send the data yet.
+ */
+ ctx->streaming = false;
+
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jul 10, 2020 at 11:01 AM Ajin Cherian wrote:
>
>
>
> On Fri, Jul 10, 2020 at 3:11 PM Dilip Kumar wrote:
>>
>> With your changes sometimes due to incomplete toast
>> changes, if it can not pick the largest top txn for streaming it will
>> hang for
ize >= logical_decoding_work_mem * 1024L)
{
/*
* Pick the largest transaction (or subtransaction) and evict it from
* memory by streaming, if supported. Otherwise, spill to disk.
*/
if (ReorderBufferCanStream(rb) &&
(txn = ReorderBufferLargestTopTXN(rb)) != NULL)
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 8, 2020 at 3:32 PM Amit Kapila wrote:
>
> On Wed, Jul 8, 2020 at 9:36 AM Amit Kapila wrote:
> >
> > On Sun, Jul 5, 2020 at 8:37 PM Dilip Kumar wrote:
> > >
> > > I have compared the changes logged at command end vs logged at commit
> >
(ReorderBuffer *rb)
> {
> ReorderBufferTXN *txn;
>
> /* bail out if we haven't exceeded the memory limit */
> if (rb->size < logical_decoding_work_mem * 1024L)
> return;
>
> This will prevent the streaming/spill to occur.
I think if the GUC is set then maybe we can bypass this check so that
it can try to stream every single change?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jul 6, 2020 at 3:09 PM Amit Kapila wrote:
>
> On Mon, Jul 6, 2020 at 11:44 AM Dilip Kumar wrote:
> >
> > On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
> > >
> >
> > > > > 10. I have got the below failure once. I have not investigate
On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
>
> On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote:
> >
> > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote:
> > >
> >
> > > 9.
> > > +ReorderBufferHandleConcurrentAb
On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote:
>
> On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote:
> >
> > On Mon, Jun 29, 2020 at 4:24 PM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 22, 2020 at 4:30 PM Amit Kapila
> > > wrote:
> >
rc/test-recurse] Error 2
Even I got the failure once and after that, it did not reproduce. I
have executed it multiple time but it did not reproduce again. Are
you able to reproduce it consistently?
> 11. Can we test by introducing a new GUC such that all the
> transactions (at least in existing tests) start to stream? Basically,
> it will allow us to disregard logical_decoding_work_mem and ensure
> that all regression tests pass through new-code. Note, I am
> suggesting this just for testing purposes, not for actual integration
> in the code.
Yeah, that's a good suggestion.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jun 30, 2020 at 5:20 PM Amit Kapila wrote:
>
> On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote:
> >
> > On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote:
> > >
> > > Can't we name the last parameter as 'commit_lsn' as that is how
>
On Sun, Jun 28, 2020 at 11:18 PM Mark Dilger
wrote:
>
>
>
> > On Jun 28, 2020, at 9:05 AM, Dilip Kumar wrote:
> >
> > Some more comments on v9_0001.
> > 1.
> > + LWLockAcquire(XidGenLock, LW_SHARED);
> > + nextFullXid = ShmemVariabl
On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote:
>
> On Mon, Jun 29, 2020 at 4:24 PM Dilip Kumar wrote:
> >
> > On Mon, Jun 22, 2020 at 4:30 PM Amit Kapila wrote:
> > >
> > >
> > > Other than above tests, can we somehow verify that the invalidation
On Mon, Jun 22, 2020 at 4:30 PM Amit Kapila wrote:
>
> On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote:
> >
> > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote:
> > >
> > > Yes, I have made the changes. Basically, now I am only using the
> > &g
On Sun, Jun 28, 2020 at 8:59 PM Dilip Kumar wrote:
>
> On Mon, Jun 22, 2020 at 5:44 AM Mark Dilger
> wrote:
> >
> >
> >
> > > On Jun 21, 2020, at 2:54 AM, Dilip Kumar wrote:
> > >
> > > I have looked into 0001 patch and I have a few commen
On Mon, Jun 22, 2020 at 5:44 AM Mark Dilger
wrote:
>
>
>
> > On Jun 21, 2020, at 2:54 AM, Dilip Kumar wrote:
> >
> > I have looked into 0001 patch and I have a few comments.
> >
> > 1.
> > +
> > + /* Skip over unused/dead/redirected
On Fri, Jun 26, 2020 at 11:47 AM Amit Kapila wrote:
>
> On Thu, Jun 25, 2020 at 7:11 PM Dilip Kumar wrote:
> >
> > On Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
> > >
> > >
> > > Review comments on various patches.
>
e a mechanism to create/drop the external
compression methods.
[1]
https://www.postgresql.org/message-id/20130621000900.GA12425%40alap2.anarazel.de
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jun 25, 2020 at 7:10 PM Dilip Kumar wrote:
>
> On Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
> >
> > On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
> > >
> > > Here is the POC patch to discuss the idea of a cleanup of shared
> > >
On Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
>
> On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
> >
> > Here is the POC patch to discuss the idea of a cleanup of shared
> > fileset on proc exit. As discussed offlist, here I am maintaining
> > the list
iOn Wed, Jun 24, 2020 at 4:04 PM Amit Kapila wrote:
>
> On Tue, Jun 23, 2020 at 7:00 PM Dilip Kumar wrote:
> >
> > Here is the POC patch to discuss the idea of a cleanup of shared
> > fileset on proc exit. As discussed offlist, here I am maintaining
> > the list
On Tue, Jun 23, 2020 at 10:13 AM Dilip Kumar wrote:
>
> On Tue, Jun 23, 2020 at 8:18 AM Amit Kapila wrote:
> >
> > On Mon, Jun 22, 2020 at 6:38 PM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila
> > >
On Tue, Jun 23, 2020 at 8:18 AM Amit Kapila wrote:
>
> On Mon, Jun 22, 2020 at 6:38 PM Dilip Kumar wrote:
> >
> > On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila wrote:
> > >
> > > > > @@ -2012,8 +2014,6 @@ ReorderBufferForget(ReorderBuffer *rb,
&
On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila wrote:
>
> On Mon, Jun 22, 2020 at 4:41 PM Dilip Kumar wrote:
> >
> > On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote:
> > >
> > > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote:
> > > >
> >
On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote:
>
> On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote:
> >
> > Yes, I have made the changes. Basically, now I am only using the
> > XLOG_XACT_INVALIDATIONS for generating all the invalidation messages.
> > So whene
te file \"%s\": %m",
> - path)));
> + if (ent->subxact_fileset)
> + {
> + cleanup_subxact_info();
> + BufFileDeleteShared(ent->subxact_fileset, path);
> + ent->subxact_fileset = NULL;
> ..
> }
>
> Here don't we need to free the subxact_fileset before setting it to NULL?
Yes, done
> 13.
> + /*
> + * Scan complete hash and delete the underlying files for the the xids.
> + * Also delete the memory for the shared file sets.
> + */
>
> /the the/the. Instead of "delete the memory", it would be better to
> say "release the memory".
Done
>
> 14.
> + /*
> + * We might not have created the suxact fileset if there is no sub
> + * transaction.
> + */
>
> /suxact/subxact
Done
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sat, Jun 13, 2020 at 2:36 AM Mark Dilger
wrote:
>
>
>
> > On Jun 11, 2020, at 11:35 PM, Dilip Kumar wrote:
> >
> > On Fri, Jun 12, 2020 at 12:40 AM Mark Dilger
> > wrote:
> >>
> >>
> >>
> >>> On Jun 11, 2020, at 9:14 A
relcache. The walsender process that
> is doing decoding doesn't require us to do anything about this. Also,
> if you see before this patch, we don't do anything about relcache
> files during decoding of invalidation messages. In short, I think we
> can remove this comment unless you see some use of it.
Now, we have removed the Invalidation change itself so this comment is gone.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jun 17, 2020 at 9:33 AM Amit Kapila wrote:
>
> On Tue, Jun 16, 2020 at 7:49 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 9, 2020 at 3:04 PM Amit Kapila wrote:
> > >
> > > On Mon, Jun 8, 2020 at 11:53 AM Amit Kapila
> > > wrote:
> >
ommon solution whether it streams due to the memory
overflow or due to the commit.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jun 12, 2020 at 4:35 PM Amit Kapila wrote:
>
> On Fri, Jun 12, 2020 at 11:38 AM Dilip Kumar wrote:
> >
> > - Currently, while reading/writing the streaming/subxact files we are
> > reporting the wait event for example
> > 'pgstat_report_wait_start(WA
On Fri, Jun 12, 2020 at 12:40 AM Mark Dilger
wrote:
>
>
>
> > On Jun 11, 2020, at 9:14 AM, Dilip Kumar wrote:
> >
> > I have just browsed through the patch and the idea is quite
> > interesting. I think we can expand it to check that whether the flags
nfomask are sane or not w.r.t other flags and xid status.
Some examples are
- If HEAP_XMAX_LOCK_ONLY is set in infomask then HEAP_KEYS_UPDATED
should not be set in new_infomask2.
- If HEAP_XMIN(XMAX)_COMMITTED is set in the infomask then can we
actually cross verify the transaction status from the CLOG and check
whether is matching the hint bit or not.
While browsing through the code I could not find that we are doing
this kind of check, ignore if we are already checking this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jun 10, 2020 at 4:00 PM Amit Kapila wrote:
>
> On Wed, Jun 10, 2020 at 2:30 PM Dilip Kumar wrote:
> >
> >
> > Currently, I am done with a working prototype of using the BufFile
> > infrastructure for the tempfile. Meanwhile, I want to discuss a few
On Sun, Jun 7, 2020 at 5:06 PM Dilip Kumar wrote:
>
> On Thu, Jun 4, 2020 at 2:05 PM Dilip Kumar wrote:
> >
> > On Wed, Jun 3, 2020 at 2:43 PM Amit Kapila wrote:
> > >
> > > On Tue, Jun 2, 2020 at 7:53 PM Dilip Kumar wrote:
> > > >
&g
el
> if the WAL overhead pinches any workload, we might want to do it under some
> new guc (which will disable streaming of transactions) but I don't think we
> need to go there.
>
> What do you think?
Even I feel so because the WAL overhead is only with wal_level=logical
and especially with DDL and ideally, there should not be a large amount
of DDL in the system compared to other operations. So I think we can live
with the current approach.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jun 5, 2020 at 11:37 AM Amit Kapila wrote:
>
> On Fri, May 29, 2020 at 8:31 PM Dilip Kumar wrote:
> >
> > Apart from this one more fix in 0005, basically, CheckLiveXid was
> > never reset, so I have fixed that as well.
> >
>
> I have made a numbe
On Thu, Jun 4, 2020 at 2:05 PM Dilip Kumar wrote:
>
> On Wed, Jun 3, 2020 at 2:43 PM Amit Kapila wrote:
> >
> > On Tue, Jun 2, 2020 at 7:53 PM Dilip Kumar wrote:
> > >
> > > On Tue, Jun 2, 2020 at 4:56 PM Amit Kapila
> > > wrote:
> > >
On Wed, Jun 3, 2020 at 2:43 PM Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 7:53 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 2, 2020 at 4:56 PM Amit Kapila wrote:
> > >
> > > On Tue, Jun 2, 2020 at 3:59 PM Dilip Kumar wrote:
> > > >
> > &
On Tue, Jun 2, 2020 at 4:56 PM Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 3:59 PM Dilip Kumar wrote:
> >
> > On Thu, May 28, 2020 at 5:22 PM Amit Kapila wrote:
> > >
> > >
> > > Also, what if the changes file size overflows "OS file size lim
On Thu, May 28, 2020 at 5:22 PM Amit Kapila wrote:
>
> On Wed, May 27, 2020 at 8:22 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 7:45 AM Dilip Kumar wrote:
> > >
> > >
> > > Okay, sending again.
> >
> > While reviewing/testi
On Tue, May 26, 2020 at 4:46 PM Amit Kapila wrote:
>
> On Tue, May 26, 2020 at 2:44 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 10:27 AM Amit Kapila
> > wrote:
> > >
> > > >
> > > > 2. There is a bug fix in handl
On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
>
> On Mon, May 25, 2020 at 8:07 PM Dilip Kumar wrote:
> >
> > On Fri, May 22, 2020 at 11:54 AM Amit Kapila
> > wrote:
> > >
> > > 4.
> > > + * XXX Do we need to allocate it
On Thu, May 28, 2020 at 2:41 PM Amit Kapila wrote:
>
> On Thu, May 28, 2020 at 12:46 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 12:00 PM Amit Kapila
> > wrote:
> > >
> > > Isn't this problem only for subxact file as we anyway create changes
On Thu, May 28, 2020 at 2:41 PM Amit Kapila wrote:
>
> On Thu, May 28, 2020 at 12:46 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 12:00 PM Amit Kapila
> > wrote:
> > >
> > > Isn't this problem only for subxact file as we anyway create changes
On Thu, May 28, 2020 at 3:15 PM Amit Kapila wrote:
>
> On Thu, May 28, 2020 at 12:57 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
> > >
> > > Why we need memory-related to subxacts till the worker is alive? As
> >
On Tue, May 26, 2020 at 3:04 PM Amit Kapila wrote:
>
> On Mon, May 25, 2020 at 8:07 PM Dilip Kumar wrote:
> >
> > On Fri, May 22, 2020 at 11:54 AM Amit Kapila
> > wrote:
> > >
> > > 4.
> > > + * XXX Do we need to allocate it
On Tue, May 26, 2020 at 12:00 PM Amit Kapila wrote:
>
> On Fri, May 22, 2020 at 6:22 PM Dilip Kumar wrote:
> >
> > On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote:
> > >
> > > On Sun, May 17, 2020 at 12:41 PM Dilip Kumar
> > > wrote:
> &g
On Tue, May 26, 2020 at 10:27 AM Amit Kapila wrote:
>
> On Fri, May 22, 2020 at 6:21 PM Dilip Kumar wrote:
> >
> > On Mon, May 18, 2020 at 5:57 PM Amit Kapila wrote:
> > >
> > >
> > > Few comments on v20-0010-Bugf
errmsg("could not truncate file \"%s\": %m", path)));
> ..
> }
>
> Will truncate works on Windows? I see in the code we ftruncate which
> is defined as chsize in win32.h and win32_port.h. I have not tested
> this so I am not very sure about this. I got a below warning when I
> tried to compile this code on Windows. I think it is better to
> ftruncate as it is used at other places in the code as well.
>
> worker.c(798): warning C4013: 'truncate' undefined; assuming extern
> returning int
I have changed to the ftruncate.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, May 19, 2020 at 5:34 PM Amit Kapila wrote:
>
> On Fri, May 15, 2020 at 2:47 PM Dilip Kumar wrote:
> >
> > On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote:
> > >
> >
> > > 4.
> > > +static void
> > > +stream_
On Tue, May 19, 2020 at 6:01 PM Amit Kapila wrote:
>
> On Fri, May 15, 2020 at 2:48 PM Dilip Kumar wrote:
> >
> > On Wed, May 13, 2020 at 4:50 PM Amit Kapila wrote:
> > >
> >
> > > 3.
> > > And, during catalog scan we can check the status of th
On Tue, May 19, 2020 at 4:33 PM Amit Kapila wrote:
>
> On Tue, May 19, 2020 at 3:31 PM Dilip Kumar wrote:
> >
> > On Tue, May 19, 2020 at 2:34 PM Amit Kapila wrote:
> > >
> > > On Mon, May 18, 2020 at 5:57 PM Amit Kapila
&g
On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote:
>
> On Sun, May 17, 2020 at 12:41 PM Dilip Kumar wrote:
> >
> > On Fri, May 15, 2020 at 4:04 PM Amit Kapila wrote:
> > >
> > >
> > > Review comments:
> > >
ng is successful then
> we can truncate the changes only up to completed changes LSN. What do
> you think?
>
> I wonder why you have done this as 0010 in the patch series, it should
> be as 0006 after the
> 0005-Implement-streaming-mode-in-ReorderBuffer.patch. If we can do
> that way then it would be easier for me to review. Is there a reason
> for not doing so?
No reason, I can do that. Actually, later we can merge the changes to
0005 only, I kept separate for review. Anyway, in the next version, I
will make it as 0006.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, 15 May 2020 at 6:06 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Wed, May 13, 2020 at 02:37:21PM +0530, Dilip Kumar wrote:
> >
> > + if (_bt_scankey_within_page(scan, so->skipScanKey, so->currPos.buf,
> dir))
> > + {
> >
> &g
On Fri, May 15, 2020 at 4:35 PM Amit Kapila wrote:
>
> On Fri, May 15, 2020 at 4:20 PM Dilip Kumar wrote:
> >
> > On Fri, May 15, 2020 at 4:04 PM Amit Kapila wrote:
> > >
> >
> > >
> > > > - In the example we can not show a real example,
On Fri, May 15, 2020 at 4:04 PM Amit Kapila wrote:
>
> On Fri, May 15, 2020 at 2:47 PM Dilip Kumar wrote:
> >
> > > 6. I think it will be good if we can provide an example of streaming
> > > changes via test_decoding at
> > > https://www.postgresql.org/do
On Wed, May 13, 2020 at 4:50 PM Amit Kapila wrote:
>
> On Wed, May 13, 2020 at 11:35 AM Dilip Kumar wrote:
> >
> > On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote:
> > >
> > >
> > > v20-0003-Ext
to worry that those
triggers could do something on the primary table before we check the
constraint. I am not sure if there are any other factors that I am
missing.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, May 13, 2020 at 4:50 PM Amit Kapila wrote:
>
> On Wed, May 13, 2020 at 11:35 AM Dilip Kumar wrote:
> >
> > On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote:
> > >
> > >
> > > v20-0003-Ext
On Mon, May 11, 2020 at 4:55 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, May 11, 2020 at 04:04:00PM +0530, Dilip Kumar wrote:
> >
> > > > +static inline bool
> > > > +_bt_scankey_within_page(IndexScanDesc scan, BTScanInsert
On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote:
>
> On Thu, May 7, 2020 at 6:17 PM Dilip Kumar wrote:
> >
> > On Tue, May 5, 2020 at 7:13 PM Dilip Kumar wrote:
> >
> > I have fixed one more issue in 0010 patch. The issue was that once
> > the transaction
gt;> build_replindex_scan_key needs to be updated.
>>
>> * This is not generic routine, it expects the idxrel to be replication
>> * identity of a rel and meet all limitations associated with that.
>>
> It is implicit that a primary key can be a replica identity so I think this
> comment is fine.
I like your idea of modifying the assert instead of completely removing.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, May 13, 2020 at 1:56 AM Robert Haas wrote:
>
> On Tue, May 12, 2020 at 4:32 AM Dilip Kumar wrote:
> > Some of the bbsink_libpq_* functions are directly calling pq_* e.g.
> > bbsink_libpq_begin_backup whereas others are calling SendCopy*
> > functions and there
ink?
The overall idea looks quite nice. I had a look at some of the
patches at least 0005 and 0006. At first look, I have one comment.
+/*
+ * Each archive is set as a separate stream of COPY data, and thus begins
+ * with a CopyOutResponse message.
+ */
+static void
+bbsink_libpq_begin_archive(bbsink *sink, const char *archive_name)
+{
+ SendCopyOutResponse();
+}
Some of the bbsink_libpq_* functions are directly calling pq_* e.g.
bbsink_libpq_begin_backup whereas others are calling SendCopy*
functions and therein those are calling pq_* functions. I think
bbsink_libpq_* function can directly call pq_* functions instead of
adding one more level of the function call.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sun, May 10, 2020 at 11:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Apr 11, 2020 at 03:17:25PM +0530, Dilip Kumar wrote:
> >
> > Some more comments...
>
> Thanks for reviewing. Since this patch took much longer than I expected,
>
On Tue, May 5, 2020 at 10:25 AM Amit Kapila wrote:
>
> On Tue, May 5, 2020 at 9:27 AM Dilip Kumar wrote:
> >
> > On Mon, May 4, 2020 at 5:16 PM Amit Kapila wrote:
> > >
> > > On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
> >
On Mon, May 4, 2020 at 5:16 PM Amit Kapila wrote:
>
> On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
> >
> 5. Shouldn't we add a check in table_scan_sample_next_block and
> table_scan_sample_next_tuple APIs as well?
I am not sure that we need to do that, Because generally
On Wed, Apr 29, 2020 at 2:56 PM Dilip Kumar wrote:
>
> On Tue, Apr 28, 2020 at 3:55 PM Dilip Kumar wrote:
> >
> > On Tue, Apr 28, 2020 at 3:11 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> > > >
> &
On Tue, Apr 28, 2020 at 3:55 PM Dilip Kumar wrote:
>
> On Tue, Apr 28, 2020 at 3:11 PM Amit Kapila wrote:
> >
> > On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> > >
> > [latest patches]
> >
> > v16-0004-Gracefully-handle-concurrent-abor
On Wed, Apr 29, 2020 at 12:37 PM Mahendra Singh Thalor
wrote:
>
> On Wed, 29 Apr 2020 at 11:15, Mahendra Singh Thalor
> wrote:
> >
> > On Fri, 24 Apr 2020 at 11:55, Dilip Kumar wrote:
> > >
> > > On Thu, Apr 23, 2020 at 2:28 PM Erik Rijkers wrote:
>
On Tue, Apr 28, 2020 at 3:11 PM Amit Kapila wrote:
>
> On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> >
> [latest patches]
>
> v16-0004-Gracefully-handle-concurrent-aborts-of-uncommitt
> - Any actions leading to transaction ID assignment are prohibit
On Mon, Apr 27, 2020 at 4:13 PM Amit Kapila wrote:
>
> On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> >
> > I have also fixed a couple of bugs internally reported by my colleague
> > Neha Sharma.
> >
>
> I think it would be good if you can briefly expl
least) and the result
> is correct,
> then we think about how to cost it. The purpose of my writing is about the
> first step
> and see what people think about it.
Ok
>
> As for how to cost it, I'm agreed with your suggestion, but we may need more
> than that, like. (1, 2, 1) and (1, 1, 2) is same for your suggestion, but
> they
> are not different in this path.
Valid point.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
th);
Can we just directly add the material path on top of the best path? I
mean there are possibilities that we might not get any benefit of the
material because there is no duplicate from the outer node but we are
paying the cost of materialization right? The correct idea would be
that we should select this based on the cost comparison. Basically,
we can consider how many duplicates we have from the outer table
variable no?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Apr 23, 2020 at 2:28 PM Erik Rijkers wrote:
>
> On 2020-04-23 05:24, Dilip Kumar wrote:
> > On Wed, Apr 22, 2020 at 9:31 PM Erik Rijkers wrote:
> >>
> >> The 'ddl' one is apparently not quite fixed - I get this in (cd
> >> contrib; make check)'
On Wed, Apr 22, 2020 at 9:31 PM Erik Rijkers wrote:
>
> On 2020-04-22 16:49, Dilip Kumar wrote:
> > On Tue, Apr 21, 2020 at 5:30 PM Dilip Kumar
> > wrote:
> >>
> >> >
> >> > (by the way: this build's regression tests 'ddl', 'toast', and
&g
On Tue, Apr 21, 2020 at 4:52 PM Dilip Kumar wrote:
>
> On Tue, Apr 21, 2020 at 3:44 PM Thomas Munro wrote:
> >
> > On Tue, Apr 21, 2020 at 2:05 PM Thomas Munro wrote:
> > > As before, these two apply on top of Robert's patches (or at least his
> > >
[v14-0007-Track-statistics-for-streaming.patch]
> > [v14-0008-Enable-streaming-for-all-subscription-TAP-tests.patch]
> > [v14-0009-Add-TAP-test-for-streaming-vs.-DDL.patch]
> > [v14-0010-Bugfix-handling-of-incomplete-toast-tuple.patch]
> > [bugfix_in_schema_sent.patch]
>
> (
02:19:00Z');
+is(summarize_mapping(), "20|02:00:00|02:19:00");
But, I think we should try to extend it to test that we have put the
new xid only in those slots where we suppose to and not in other
slots?.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Apr 20, 2020 at 11:31 PM Robert Haas wrote:
>
> On Mon, Apr 20, 2020 at 12:10 AM Dilip Kumar wrote:
> > I have started reviewing these patches. I think, the fixes looks right to
> > me.
> >
> > + LWLockAcquire(OldSnapshotTimeMapLock, LW_SHARE
On Mon, Apr 20, 2020 at 12:29 PM Thomas Munro wrote:
>
> On Mon, Apr 20, 2020 at 6:35 PM Dilip Kumar wrote:
> > On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro
> > wrote:
> > >
> > > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote:
> > > &g
On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro wrote:
>
> On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote:
> > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro
> > wrote:
> > > I think I found another bug in MaintainOldSnapshotTimeMapping(): if
> >
1201 - 1300 of 1655 matches
Mail list logo
