On Tue, Jun 1, 2021 at 3:39 PM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 12:29 PM tanghy.f...@fujitsu.com
> > I noticed that in case1, ExtractReplicaIdentity function returned NULL on
> > HEAD. But after your fix, it didn’t return NULL. There is no problem with
> >
On Wed, Jun 2, 2021 at 2:37 PM tanghy.f...@fujitsu.com
wrote:
>
> On Wed, Jun 2, 2021 2:44 PM Dilip Kumar wrote:
> > Attached patch fixes that, I haven't yet added the test case. Once
> > someone confirms on the approach then I will add a test case to the
> >
On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh wrote:
>
> On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar wrote:
> >
> > Yes, you are right. I will change it in the next version, along with
> > the test case.
> >
> +/*
> + * if the key hasn't changed a
h, serve both "set" and "search", but it
only search if the "minValue" is > 0. So if the minvalue is passed as
0 then the return value is ignored intentionally. I can see in both
places where the returned value is ignored the minvalue is passed as
0.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jun 2, 2021 at 7:23 PM Dilip Kumar wrote:
>
> On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh
> wrote:
> >
> > On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar wrote:
> > >
> > > Yes, you are right. I will change it in the next
On Thu, Jun 3, 2021 at 5:11 PM Bharath Rupireddy
wrote:
>
> On Thu, Jun 3, 2021 at 4:47 PM Dilip Kumar wrote:
> >
> > On Thu, Jun 3, 2021 at 4:24 PM Bharath Rupireddy
> > wrote:
> > >
> > > Hi,
> > >
> > > It looks like for some
our patch. I tested it for all branches(10,11,12,13,HEAD) and all
> of them passed.(This bug was introduced in PG-10.)
> I also tested the scenario where I found this bug, data could be synchronized
> after your fix.
Thanks for verifying this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jun 4, 2021 at 2:03 AM Robert Haas wrote:
>
> On Thu, May 27, 2021 at 2:26 AM Dilip Kumar wrote:
> > Changed as suggested.
>
> I don't think the code as written here is going to work on Windows,
> because your code doesn't duplicate enable_restoring's
On Mon, 7 Jun 2021 at 8:30 AM, Amit Kapila wrote:
> On Wed, Jun 2, 2021 at 11:52 AM Amit Kapila
> wrote:
> >
> > On Wed, Jun 2, 2021 at 11:38 AM Dilip Kumar
> wrote:
> > >
> > > On Wed, Jun 2, 2021 at 11:25 AM Amit Kapila
> wrote:
> > >
submitted patches with 2 approached
in that thread.
[1]
https://www.postgresql.org/message-id/CAFiTN-szfpMXF2H%2Bmk3m_9AB610v103NTv7Z1E8uDBr9iQg1gg%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jun 7, 2021 at 8:46 AM Dilip Kumar wrote:
> On Mon, 7 Jun 2021 at 8:30 AM, Amit Kapila
> wrote:
>
>> On Wed, Jun 2, 2021 at 11:52 AM Amit Kapila
>> wrote:
>> >
>> > On Wed, Jun 2, 2021 at 11:38 AM Dilip Kumar
>> wrote:
>> >
On Mon, Jun 7, 2021 at 6:34 PM Amit Kapila wrote:
> On Mon, Jun 7, 2021 at 6:04 PM Dilip Kumar wrote:
> >
> > I have fixed all pending review comments and also added a test case
> which is working fine.
> >
>
> Few observations and questions on testcase:
>
Maybe we can use it ?
# Wait until the node exits recovery.
$standby->poll_query_until('postgres', "SELECT pg_is_in_recovery() = 'f';")
or die "Timed out while waiting for promotion";
I will try to generate a version for 9.6 based on this idea and see how it goes
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jun 8, 2021 at 11:13 AM Dilip Kumar wrote:
>
> # Wait until the node exits recovery.
> $standby->poll_query_until('postgres', "SELECT pg_is_in_recovery() = 'f';")
> or die "Timed out while waiting for promotion";
>
> I will try
On Mon, Jun 7, 2021 at 6:45 PM Dilip Kumar wrote:
>>
>>
>> 2. In the test, there seems to be an assumption that we can unlock s2
>> and s3 one after another, and then both will start waiting on s-1 but
>> isn't it possible that before s2 start waiting on s1
002’:
No such file or directory
2021-06-09 12:11:08.627 IST [122456] LOG: redo starts at 0/228
2021-06-09 12:11:08.627 IST [122456] LOG: consistent recovery state
reached at 0/300
Next, I will investigate, without a fix on v11 (maybe v12, v10..) why it is
not hitting the defect location
On Wed, Jun 9, 2021 at 12:14 PM Dilip Kumar wrote:
>
> On Wed, Jun 9, 2021 at 2:07 AM Robert Haas wrote:
> 2021-06-09 12:11:08.618 IST [122456] LOG: entering standby mode
> 2021-06-09 12:11:08.622 IST [122456] LOG: restored log file
> "0002.history" from
On Wed, Jun 9, 2021 at 1:37 PM Dilip Kumar wrote:
>
> On Wed, Jun 9, 2021 at 12:14 PM Dilip Kumar wrote:
> >
> > On Wed, Jun 9, 2021 at 2:07 AM Robert Haas wrote:
> > 2021-06-09 12:11:08.618 IST [122456] LOG: entering standby mode
> > 2021-06-09 12:11:08.622 I
On Wed, Jun 9, 2021 at 11:03 AM Amit Kapila wrote:
> On Tue, Jun 8, 2021 at 5:16 PM Dilip Kumar wrote:
> >
> > Based on the off list discussion, I have modified the test based on
> > the idea showed in
> > "isolation/specs/insert-conflict-specconflict.spec&quo
On Wed, Jun 9, 2021 at 4:22 PM Amit Kapila wrote:
> On Wed, Jun 9, 2021 at 4:12 PM Dilip Kumar wrote:
> >> Few comments:
> >> 1. The test has a lot of similarities and test duplication with what
> >> we are doing in insert-conflict-specconflict.spec. Can we m
ther comments and also prepared patches for the back branches.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From dcea4c36267ad2dc58dd0a57733a6f6276e2d754 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Tue, 8 Jun 2021 17:06:39 +0530
Subject: [PATCH v5 1/2] Bug fix for spec
test/recovery/tmp_check/t_002_archiving_primary_data/archives\\0003.history"
2021-06-10 22:44:36.113 EDT [60c2ce0c.283c:5] LOG: received immediate
shutdown request
2021-06-10 22:44:36.129 EDT [60c2ce0c.283c:6] LOG: database system is shut down
I am not able to figure out why the archive command is failing.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
we have used base for our test so
let's not push this test until it becomes stable.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jun 14, 2021 at 9:44 AM Dilip Kumar wrote:
>
> On Mon, Jun 14, 2021 at 8:34 AM Amit Kapila wrote:
> >
> > I think the test in this patch is quite similar to what Noah has
> > pointed in the nearby thread [1] to be failing at some intervals. Can
> > you al
s more refactoring/cleanup and testing.
- Might need to relook into the SMGR level API usage.
Credits:
---
Thanks to Robert Haas, for suggesting this idea and the high-level design.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From e472d3cb744dc45641d36e919098f9570f8
On Tue, Jun 15, 2021 at 5:34 PM Heikki Linnakangas wrote:
>
> On 15/06/2021 14:20, Dilip Kumar wrote:
> > Design Idea:
. Then
> > we can get the relfilenode of every file we need to copy, and prepare
> > a list of all such relfilenode.
>
> I guess that would wor
x27;t it be good to
provide control to the user by providing two different commands, e.g.
COPY DATABASE for the existing method (copydir) and CREATE DATABASE
for the new method (fully wal logged)?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
()log_newpage()On Thu, Jun 17, 2021 at 3:28 AM Andres Freund
wrote:
>
> Hi,
>
> On 2021-06-15 16:50:24 +0530, Dilip Kumar wrote:
> > The patch modifies both CREATE DATABASE and ALTER DATABASE..SET
> > TABLESPACE to be fully WAL-logged.
>
> Generally quite a bit
ate_valid)
+ if (!found)
+ {
+ /*
+ * Make the new entry valid enough for the callbacks to look at, in
+ * case any of them get invoked during the more complicated
+ * initialization steps below.
+ */
On head:
if (!found)
{
/* immediately make a new entry valid enough to satisfy callbacks */
--
Regar
t the "new approach" is bloating WAL volume,
> no? Right now cloning a 1TB database costs a few hundred bytes of WAL and
> about
> 1TB of write IO. With the proposed approach, the write volume approximately
> doubles, because there'll also be about 1TB in WAL.
Make sense.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jun 17, 2021 at 2:50 PM Heikki Linnakangas wrote:
>
> On 17/06/2021 08:45, Dilip Kumar wrote:
> > Another problem with directly scanning the directory is, how we
> > are supposed to get the "relpersistence" which is stored in pg_class
> > tuple right?
&
On Fri, Jun 18, 2021 at 12:13 PM Michael Paquier wrote:
>
> On Thu, May 06, 2021 at 07:23:48PM +0530, Dilip Kumar wrote:
> > I have fixed some comments offlist reported by Justin. Apart from
> > that, I have also improved documentation and test case. Stil it has a
> > l
erified this for speculative aborts
> and it allows streaming once we receive the spec_abort change record.
Yeah, this improvement makes sense. And the patch looks fine to me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jun 30, 2021 at 9:29 AM Amit Kapila wrote:
>
> On Tue, Jun 29, 2021 at 12:57 PM Dilip Kumar wrote:
> >
> > On Fri, Jun 25, 2021 at 12:24 PM Amit Kapila
> > wrote:
> > >
> > > Till now, we didn't allow to stream the changes in logica
ernal mapping instead of completely ignoring
this option for lz4, or we can provide another option for lz4?
3. Should we also support LZ4 compression using dictionary?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
dly let me know your opinion.
>
I haven't looked into the patch yet but +1 for the idea.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
> 2
> 3
> (3 rows)
>
> Expected:
> c1
>
> 1
> 2
> (2 rows)
Yeah, this looks like a bug. I will look at the patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote:
>
> Yeah, this looks like a bug. I will look at the patch.
>
While looking into this, I think the main cause of the problem is that
schema rename does not invalidate the relation cache right? I also
tried other cases e.g. if there i
king might be very costly if the number of partitions is
more. Can't we provide some mid-way where the parallelism is enabled
by default for the normal table but for the partitioned table it is
disabled by default and the user has to set it safe for enabling
parallelism? I agree that such behavior might sound a bit hackish.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
dicting the
next wal segment? I think there is nothing wrong even if we try to
look for seg 0 in timeline 0, everytime we start the archivar but that
will be true only once in the history of the cluster so why not skip
this until we scan the directory once?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e can
> avoid doing that without creating too much ugliness elsewhere.
>
The patch was not getting applied on head so I have rebased it, along
with that now I have used bufmgr layer for writing writing/logging
destination pages as well instead of directly using sgmr layer.
--
Regards,
handle
> safely?
>
> A second question: at first glance it's intuitively the case we might
> not be able to handle byref values. But nodeAgg doesn't seem to have
> that restriction. What's the difference here?
>
I think tuplesort_begin_datum, doesn't have any such limitation, it
can handle any type of Datum so I think we don't need to consider the
only attbyval, we can consider any type of attribute for this
optimization.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jul 8, 2021 at 7:48 PM wrote:
>
> Dilip Kumar wrote:
>
> > Wouldn't it be better to call it compression method instead of
> > compression program?
>
> Agreed. This is inline with the suggestions of other reviewers.
> Find the change in the attached
On Mon, Jul 12, 2021 at 3:15 PM Magnus Hagander wrote:
>
> On Mon, Jul 12, 2021 at 11:33 AM wrote:
> >
> >
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Monday, July 12th, 2021 at 07:56, Michael Paquier
> > wrote:
> >
> > &
enforcing it on the apply
> > worker.
> >
>
> But doing it in the deparsing code will have the benefit that the
> other plugins won't have to develop similar logic.
Right, this makes sense.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
;
> > Is it worth adding additional complexity that is not a complete solution?
>
> The proposed approach helps to avoid some common possible problems
> that arise with simple scenarios (like cancelling a long running query
> while in SyncRepWaitForLSN) within sync replication.
IMHO, making it wait for some amount of time, based on GUC is not a
complete solution. It is just a hack to avoid the problem in some
cases.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, May 9, 2022 at 4:39 PM Andrey Borodin wrote:
> > On 9 May 2022, at 14:44, Dilip Kumar wrote:
> >
> > IMHO, making it wait for some amount of time, based on GUC is not a
> > complete solution. It is just a hack to avoid the problem in some
> > cases.
new version.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
il.com
[2]
https://www.postgresql.org/message-id/CA+TgmoZZDL_2E_zuahqpJ-WmkuxmUi8+g7=dLEny=18r-+c...@mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
n server's data, instead that the export should fetch the data
from the remote's pg_largeobject table. Then I just checked inserting
into the foriegn from your test as shown below[1] and I noticed that
the insert is also importing the large object into the local
pg_largeobject instead of the
On Mon, May 23, 2022 at 10:54 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > I don't think that the local pg_largeobject should maintain the
> > foreign server's data, instead that the export should fetch the data
> > from the remote's pg_largeobjec
an add comments to refer to that part of the code.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jun 20, 2022 at 3:16 PM vignesh C wrote:
>
> On Mon, Jun 20, 2022 at 2:37 PM Dilip Kumar wrote:
> >
> > On Thu, Jun 16, 2022 at 3:48 PM vignesh C wrote:
> > >
> > > On Wed, Jun 15, 2022 at 12:09 PM Peter Smith
> > > wrote:
> > >
ably some spare bytes on the ForkNumber, if we
> needed them later.
Yeah this is possible but I am not seeing the clear advantage. Of
Course we can widen the RelFileNumber to 64 instead of 56 but with the
added complexity of storing the mapping. I am not sure if it is
really worth it?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jun 30, 2022 at 10:57 PM Robert Haas wrote:
>
> On Wed, Jun 29, 2022 at 5:15 AM Dilip Kumar wrote:
> > >- It looks to me like you need to give significantly more thought to
> > > the proper way of adjusting the relfilenode-related test cases in
> > > alt
On Sat, Jul 2, 2022 at 9:38 AM Andres Freund wrote:
Thanks for the review,
> I'm not feeling inspired by "locator", tbh. But I don't really have a great
> alternative, so ...
>
>
> On 2022-07-01 16:12:01 +0530, Dilip Kumar wrote:
> > From f07ca9ef19e64
tion checks against such files existing
> when we don't expect them to. I.e. commit 1-3, add the asserts, then commit 4
> a bit later.
I think this is a good idea.
> > Okay, so you mean to say that we can first drop the remaining segment
> > and at last we drop the segment 0 right?
>
> I'd use the approach Robert suggested and delete from the end, going down.
Yeah, I got it, thanks.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
extent.
> >
>
> These results indicate that it is a good idea, especially for very small
> tables.
>
> > When the table size increases more, the advantage of reusing workers
> > becomes insignificant.
> >
>
> It seems from your results that performance degrades for large
> relations. Did you try to investigate the reasons for the same?
Yeah, that would be interesting to know that why there is a drop in some cases.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 6, 2022 at 2:48 PM Amit Kapila wrote:
>
> On Wed, Jul 6, 2022 at 1:47 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 6, 2022 at 9:06 AM Amit Kapila wrote:
> > >
> > > How would you choose the slot name for the table sync, right now it
> > >
I'm fine with Relation
> instead since I see it more intuitive than RelFileLocator in the
> function names.
>
> The attached is that.
I think the naming used in your patch looks better to me. So +1 for the change.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
for issuing a new WAL
> record. Maybe something like RFN_VALUES_PER_XLOG and
> RFN_NEW_XLOG_THRESHOLD, or something. And then work code that works
> correctly for any value of RFN_NEW_XLOG_THRESHOLD between 0 (don't log
> new RFNs until old allocation is completely exhausted)
Instead, we generate
typo "more tha none" -> "more than one"
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
cation origin catalog and identify whether it
is a local origin id or remote origin id and based on that filter out
the changes.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar wrote:
>
> On Tue, Jul 12, 2022 at 2:58 PM vignesh C wrote:
> >
> > On Tue, Jul 12, 2022 at 9:51 AM Amit Kapila wrote:
>
> I find one thing confusing about this patch. Basically, this has two
> option 'local'
On Thu, 14 Jul 2022 at 6:34 PM, vignesh C wrote:
> On Thu, Jul 14, 2022 at 11:26 AM Dilip Kumar
> wrote:
> >
> > On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar
> wrote:
> > >
> > > On Tue, Jul 12, 2022 at 2:58 PM vignesh C wrote:
> > > >
On Sat, Jul 16, 2022 at 9:05 AM vignesh C wrote:
>
> On Thu, Jul 14, 2022 at 6:42 PM Dilip Kumar wrote:
> >
> > On Thu, 14 Jul 2022 at 6:34 PM, vignesh C wrote:
> >>
> >> On Thu, Jul 14, 2022 at 11:26 AM Dilip Kumar wrote:
> >> >
&g
On Thu, Jul 14, 2022 at 5:18 PM Dilip Kumar wrote:
> Apart from this I have fixed all the pending issues that includes
>
> - Change existing macros to inline functions done in 0001.
> - Change pg_class index from (tbspc, relfilenode) to relfilenode and
> also change RelidByRelfi
consume multiple relfilenodes.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jul 21, 2022 at 9:53 AM Thomas Munro wrote:
>
> On Wed, Jul 20, 2022 at 11:27 PM Dilip Kumar wrote:
> > [v10 patch set]
>
> Hi Dilip, I'm experimenting with these patches and will hopefully have
> more to say soon, but I just wanted to point out that this
On Fri, Jul 22, 2022 at 4:21 PM vignesh C wrote:
>
> On Wed, Jul 20, 2022 at 4:57 PM Dilip Kumar wrote:
> >
> Thanks for the patch, my comments from the initial review:
> 1) Since we have changed the macros to inline functions, should we
> change the function names simila
On Tue, Jul 26, 2022 at 10:05 AM Amul Sul wrote:
>
> Few more typos in 0004 patch as well:
>
> the a value
> interger
> previosly
> currenly
>
Thanks for the review, I will fix it in the next version.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
are restricting very normal cases.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 26, 2022 at 2:30 PM Dilip Kumar wrote:
>
> On Fri, Jul 22, 2022 at 8:27 AM wangw.f...@fujitsu.com
> wrote:
> >
> > On Tues, Jul 19, 2022 at 10:29 AM I wrote:
> > > Attach the news patches.
> >
> > Not able to apply patches clea
strategies. Because when we switch from
CONCURRENCY to COMPACT it would immediately affect the insert/update
performance but it would control the bloat. So I am not sure whether
the selection should be completely based on the heuristic or there
should be some GUC parameter where the user can dec
ds we are continuously
creating/dropping tables. So we thought of choosing this number 512
so that it is not very low that can create the lock contention and it
is not very high so that we need to worry about wasting those many
relfilenumbers on the crash.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 27, 2022 at 10:06 AM Amit Kapila wrote:
>
> On Tue, Jul 26, 2022 at 2:30 PM Dilip Kumar wrote:
> >
> > On Fri, Jul 22, 2022 at 8:27 AM wangw.f...@fujitsu.com
> > wrote:
> > >
> > > On Tues, Jul 19, 2022 at 10:29 AM I wrote:
> > >
)
> we refer to this as a relfilenode.
No this is expected to be an internal error because in general during
the cluster lifetime ideally, we should never reach this number. So
we are putting this check so that it should not reach this number due
to some other computational/programming mistake.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, 27 Jul 2022 at 9:49 PM, Dilip Kumar wrote:
> On Wed, Jul 27, 2022 at 12:07 AM Robert Haas
> wrote:
> >
> > On Tue, Jul 26, 2022 at 2:07 AM Dilip Kumar
> wrote:
> > > I have thought about it while doing so but I am not sure whether it is
> > >
u",
> >rlocator.spcOid, rlocator.dbOid,
> > rlocator.relNumber,
> >forknum, blkno);
>
> Should this one be an ereport, and thus you do need to change it to that
> and handle it like that?
Okay, so you mean irrespective of this patch should this be converted
to ereport?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
atorBackend as key) I have avoided the padding bytes in size
by introducing this new macro[1].
[1]
#define SizeOfRelFileLocatorBackend \
(offsetof(RelFileLocatorBackend, backend) + sizeof(BackendId))
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
t List *lst, int N)
{
ForEachState r = {lst, N};
Assert(N >= 0);
return r;
}
static inline FullTransactionId
FullTransactionIdFromEpochAndXid(uint32 epoch, TransactionId xid)
{
FullTransactionId result;
result.value = ((uint64) epoch) << 32 | xid;
return result;
}
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
nged it so that we do not reuse the smgr after it
gets removed during interrupt processing, see discussion here[1]
[1]
https://www.postgresql.org/message-id/CA%2BTgmoYKovODW2Y7rQmmRFaKu445p9uAahjpgfbY8eyeL07BXA%40mail.gmail.com
>From the Valgrind report, it is clear that we are getting the smgr
entry whose smgr->smgr_owner is pointing into the fake relcache entry.
So I am investigating further how it is possible for the smgr created
during a previous create database attempt to survive beyond abort
transaction.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Aug 3, 2022 at 11:28 AM Dilip Kumar wrote:
>
> On Wed, Aug 3, 2022 at 3:53 AM Andres Freund wrote:
> >
> > On 2022-08-02 17:04:16 -0500, Justin Pryzby wrote:
> > > I got this interesting looking thing.
> > >
> > > ==11628== Invalid wr
On Wed, Aug 3, 2022 at 12:00 PM Dilip Kumar wrote:
>
> Okay, so AtEOXact_SMgr will only get rid of unowned smgr and ours are
> owned by a fake relcache and whose lifetime is just portal memory
> context which will go away at the transaction end. So as Andres
> suggested options
On Wed, Aug 3, 2022 at 1:41 PM Dilip Kumar wrote:
>
> On Wed, Aug 3, 2022 at 12:00 PM Dilip Kumar wrote:
> >
>
> > Okay, so AtEOXact_SMgr will only get rid of unowned smgr and ours are
> > owned by a fake relcache and whose lifetime is just portal memory
> >
as before, albeit that the attached patch has some additional
> optimizations (2, 3 above). So what this gives is a better flight
> envelope in case of a small number of occasional overflows.
>
> Please review. Thank you.
+1,
I had a quick look into the patch to understand the idea and I think
the idea looks really promising to me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, 3 Aug 2022 at 9:22 PM, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 7:15 AM Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> Hmm, but didn't we decide
On Wed, Aug 3, 2022 at 9:32 PM Justin Pryzby wrote:
>
> On Wed, Aug 03, 2022 at 04:45:23PM +0530, Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> Thanks for p
en critical system index 2662
Previous connection kept
postgres[14968]=#
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Aug 4, 2022 at 9:41 AM Dilip Kumar wrote:
>
> On Thu, Aug 4, 2022 at 12:18 AM Justin Pryzby wrote:
> >
> > On Wed, Aug 03, 2022 at 11:26:43AM -0700, Andres Freund wrote:
> > > Hm. This looks more like an issue of DROP DATABASE not being
> > > inter
at do we lose with this?
just 4 billion relfilenode? does that really matter provided the range
we get with the 56 bits relfilenumber.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ation a heap could withstand that, but its
> indexes won't be happy (and I guess t_ctid chain links won't either).
>
> I think you should just lose the if() stanza. There's no optimization to
> be had here that's worth any extra complication.
>
> (This
s I mentioned that we will still
have the target database pages in the shared buffers and we are not
bypassing the shared buffers also.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Aug 5, 2022 at 2:59 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-03 16:45:23 +0530, Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> What's
On Fri, Aug 5, 2022 at 10:43 AM Dilip Kumar wrote:
>
> Yeah maybe it is not necessary to close as these unowned smgr will
> automatically get closed on the transaction end. Actually the
> previous person of the patch had both these comments fixed. The
> reason for explicitly clo
On Thu, Aug 4, 2022 at 5:01 PM Dilip Kumar wrote:
>
> On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
>
> > One solution to all this is to do as Dilip proposes here: for system
> > relations, keep assigning the OID as the initial relfilenumber.
> > Actually, we real
On Sat, Aug 6, 2022 at 9:36 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> > On Fri, Aug 5, 2022 at 10:43 AM Dilip Kumar wrote:
> >> Yeah maybe it is not necessary to close as these unowned smgr will
> >> automatically get closed on the transaction end.
>
> I d
On Tue, Aug 2, 2022 at 5:16 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, July 27, 2022 4:22 PM houzj.f...@fujitsu.com wrote:
> >
> > On Tuesday, July 26, 2022 5:34 PM Dilip Kumar
> > wrote:
> >
> > > 3.
> > > Why are we restrict
On Mon, Aug 8, 2022 at 10:18 AM Dilip Kumar wrote:
>
> > Based on above, we plan to first introduce the patch to perform streaming
> > logical transactions by background workers, and then introduce parallel
> > apply
> > normal transaction which design is differe
On Mon, Aug 8, 2022 at 11:41 AM Dilip Kumar wrote:
>
> On Mon, Aug 8, 2022 at 10:18 AM Dilip Kumar wrote:
> >
> > > Based on above, we plan to first introduce the patch to perform streaming
> > > logical transactions by background workers, and then introduce para
1101 - 1200 of 1730 matches
Mail list logo
