for query details.
LOCATION: DeadLockReport, deadlock.c:1135
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Sep 6, 2024 at 4:48 PM vignesh C wrote:
>
> On Mon, 2 Sept 2024 at 18:22, Dilip Kumar wrote:
> >
> > On Mon, Sep 2, 2024 at 3:32 PM Amit Kapila wrote:
> > >
> > > On Mon, Sep 2, 2024 at 11:21 AM Dilip Kumar wrote:
> > > >
> >
'ri_onConflictArbiterIndexes' and checking if any of these
is a subset of the indexes that is returned by
ExecInsertIndexTuples().
Why are we doing that, I think we can directly use the
'recheckIndexes' which is returned by ExecInsertIndexTuples(), and
those index
On Tue, Jul 30, 2024 at 1:49 PM Zhijie Hou (Fujitsu)
wrote:
>
> > On Monday, July 29, 2024 6:59 PM Dilip Kumar
> > wrote:
> > >
> > > On Mon, Jul 29, 2024 at 11:44 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > >
>
ode-1. But maybe it would be more difficult to get a consistent
value if we are setting up a mess replication topology right? Maybe
there I think a more advanced timestamp-based option would work better
IMHO.
I am doing code level review as well and will share my comments soon
on 0003 and 0004
On Tue, Jul 30, 2024 at 4:56 PM shveta malik wrote:
>
> On Tue, Jul 30, 2024 at 4:04 PM Dilip Kumar wrote:
> >
> > On Fri, Jul 26, 2024 at 9:50 AM Ajin Cherian wrote:
> >
> > Comment in 0002,
> >
> > 1) I do not see any test case that set a proper co
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 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 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 number of
k overhead as expalined previously [1]. I feel
> 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 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
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
> >
er the flags
set in the infomask 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 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
> &
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_sta
eaming case we can
use it as common solution whether it streams due to the memory
overflow or due to the commit.
--
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:
> > >
(RELCACHE_INIT_FILENAME) that
> have obsolete information about 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 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
> - (errcode_for_file_access(),
> - errmsg("could not create 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 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
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 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 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
> > >
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 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 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
> > >
can also provide 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 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.
>
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 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 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
> > > X
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 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 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 ho
ubscription-recurse] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [check-world-src/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 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:
> >
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 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
ffer *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 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
> > &g
;size >= 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 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 forever
ppen only on StartReplicationSlot. See below
snippet from patch 0007. 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
e=66.396..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
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
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 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 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 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 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:
> > > >
>
> streaming commit if we want but not sure if that is of use. If we
> > > need to 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 fo
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:
> > > >
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 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: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 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:
> > >
pdated
> 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 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 done an ad
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 have
@mail.gmail.com
--
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
On Fri, Jul 17, 2020 at 4:16 PM Dilip Kumar wrote:
>
> The attached patch allows the vacuum to continue by emitting WARNING
> for the corrupted tuple instead of immediately error out as discussed
> at [1].
>
> Basically, it provides a new GUC called vacuum_tolerate_damage, to
&g
On Sun, Jul 19, 2020 at 4:56 PM Andrey M. Borodin wrote:
>
> Hi Dilip!
>
>
> > 17 июля 2020 г., в 15:46, Dilip Kumar написал(а):
> >
> > The attached patch allows the vacuum to continue by emitting WARNING
> > for the corrupted tuple instead of immediat
there is no specific
process who is generating the data while workers are busy inserting
the data. So IMHO, if we have a specific leader process then there
will always be work available for all the workers. I agree that we
need to find the correct point when the leader will work as a worker.
One idea could be that when the queue is full and there is no space to
push more work to queue then the leader himself processes that work.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
on for that is that those conditions are
+ * evaluated later, already after skipping was applied.
+ *
+ * TODO: This implementation is too restrictive, and doesn't allow e.g.
+ * index expressions. For that we need to examine index_clauses too.
+ */
+ if (root->parse->jointree != NULL)
+ {
+ ListCell *lc;
+
+ foreach(lc, (List *)root->parse->jointree->quals)
+ {
+ Node *expr, *qual = (Node *) lfirst(lc);
+ Var *var;
I think we can avoid checking for expression if can_skip is already false.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh wrote:
>
> On Thu, Apr 9, 2020 at 2:40 PM Dilip Kumar wrote:
> >
> > I have rebased the patch on the latest head. I haven't yet changed
> > anything for xid assignment thing because it is not yet concluded.
> &g
On Mon, Apr 13, 2020 at 6:12 PM Kuntal Ghosh wrote:
>
> On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> > On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> > wrote:
> > >
> > > +#define SizeOfTransactionId (sizeof(TransactionId) + sizeof(char))
> >
On Tue, Apr 14, 2020 at 2:57 PM Amit Kapila wrote:
>
> On Mon, Apr 13, 2020 at 6:12 PM Kuntal Ghosh
> wrote:
> >
> > On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> > > On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> > > wrote:
> > >
On Tue, Apr 14, 2020 at 3:57 PM Amit Kapila wrote:
>
> On Tue, Apr 14, 2020 at 3:41 PM Dilip Kumar wrote:
> >
> >
> > >
> > > > @@ -281,6 +281,24 @@ DecodeXactOp(LogicalDecodingContext *ctx,
> > > > XLogRecordBuffer *buf)
> > >
On Tue, Apr 14, 2020 at 9:14 PM Erik Rijkers wrote:
>
> On 2020-04-14 12:10, Dilip Kumar wrote:
>
> > v14-0001-Immediately-WAL-log-assignments.patch +
> > v14-0002-Issue-individual-invalidations-with.patch +
> > v14-0003-Extend-the-ou
00877b42 in PostmasterMain (argc=3, argv=0x2079120) at
postmaster.c:1400
#19 0x0077f256 in main (argc=3, argv=0x2079120) at main.c:210
To reproduce this issue
run start1.sh
then execute below commands on publishers.
insert into pgbench_accounts values(1,2);
update pgbench_accounts
On Tue, Apr 14, 2020 at 9:14 PM Erik Rijkers wrote:
>
> On 2020-04-14 12:10, Dilip Kumar wrote:
>
> > v14-0001-Immediately-WAL-log-assignments.patch +
> > v14-0002-Issue-individual-invalidations-with.patch +
> > v14-0003-Extend-the-ou
complete map
right. The latest snapshot timestamp will become the headtimestamp.
So in TransactionIdLimitedForOldSnapshots if (current_ts -
old_snapshot_threshold) is still >= head_timestap then we can still do
early pruning.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
(by the way: this build's regression tests 'ddl', 'toast', and
> 'spill' fail)
>
> I seem now able to run all my test programs on these instances without
> errors.
>
> Sorry, I seem to have raised a false alarm (although there was initially
> certainly a problem).
No problem, Thanks for confirming.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
fset = oldSnapshotControl->head_offset;
+ mapping->head_timestamp = oldSnapshotControl->head_timestamp;
+ mapping->count_used = oldSnapshotControl->count_used;
+ for (int i = 0; i < OLD_SNAPSHOT_TIME_MAP_ENTRIES; ++i)
+ mapping->xid_by_minute[i] = oldSnapshotControl->xid_by_minute[i];
+ LWLockRelease(OldSnapshotTimeMapLock);
I think memcpy would be a better choice instead of looping it for all
the entries, since we are doing this under a lock?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
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
> >
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: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
quot;);
+set_time('3000-01-01 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
[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]
>
> (
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
> > >
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',
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; ma
(final_rel,
> best_path);
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
e case at 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
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
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 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: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-aborts-
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 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 gene
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:
> > &g
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,
> it&#x
se questions, but I felt that
> they weren't the most important problems to solve first.
>
> What do you all think?
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 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
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 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
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 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
wise, we might have 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
1401 - 1500 of 1734 matches
Mail list logo
