ue to some reason, the walreceiver goes down, we won't be able to
> send the required WAL and users won't be able to ensure that because
> even after restart the same situation can happen. The ideal way is to
> have something that puts the system in READ ONLY state during shutdo
ng to prune the other target pages as well which we are
getting from FSM? Because in the patch you have put a check in a loop
it will try to prune every page it gets from the FSM not just the
current target page of the backend. Just wanted to understand if this
is intentional.
In general, al
ck | MultiXactOffsetBuffer
687 |
427 LWLock | BufferContent
Credits:
- The base patch v1-0001 is authored by Thomas Munro and I have just rebased it.
- 0002 and 0003 are new patches written by me based on design ideas
from Robert and Myself.
--
On Wed, Oct 11, 2023 at 4:34 PM Dilip Kumar wrote:
>
> The small size of the SLRU buffer pools can sometimes become a
> performance problem because it’s not difficult to have a workload
> where the number of buffers actively in use is larger than the
> fixed-size buffer pool
On Wed, Oct 11, 2023 at 5:57 PM Dilip Kumar wrote:
>
> On Wed, Oct 11, 2023 at 4:34 PM Dilip Kumar wrote:
> In my last email, I forgot to give the link from where I have taken
> the base path for dividing the buffer pool in banks so giving the same
> here[1]. And looking at this
at is what we want no?
I mean instead of resetwal directly modifying the control file we
will modify that value in the server using the binary_upgrade function
and then have that value flush to the disk by shutdown checkpoint.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
control file by itself with the required value of OID. The point I am
> slightly worried about doing via server-side function is that some
> online and or shutdown checkpoint can update other values in the
> control file as well whereas if we do via pg_upgrade, we can have
> bet
nsion lock on the same relation.
- Handled the error case.
In addition to that prepared a WIP patch for handling the PageLock.
First, I thought that we can use the same counter for the PageLock and
the RelationExtensionLock because in assert we just need to check
whether we are trying to acquire
On Wed, Mar 11, 2020 at 2:23 PM Amit Kapila wrote:
>
> On Tue, Mar 10, 2020 at 8:53 AM Dilip Kumar wrote:
> >
> > Please find the updated patch (summary of the changes)
> > - Instead of searching the lock hash table for assert, it maintains a
> > counter.
> &g
es to
> the main page, it might need to add a new page that will require us to
> take a relation extension lock. Now, unlike relation extension lock,
> after acquiring page lock, we do acquire another heavy-weight lock
> (relation extension lock), but as we never acquire it in reverse
> order, this is safe.
>
> So, as per this analysis, we can add Asserts for relation extension
> and page locks which will indicate that they won't participate in
> deadlocks. It would be good if someone else can also do independent
> analysis and verify my findings.
I have also analyzed the usage for the RelationExtensioLock and the
PageLock. And, my findings are on the same lines.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Mar 11, 2020 at 2:23 PM Amit Kapila wrote:
>
> On Tue, Mar 10, 2020 at 8:53 AM Dilip Kumar wrote:
> >
> > Please find the updated patch (summary of the changes)
> > - Instead of searching the lock hash table for assert, it maintains a
> > counter.
> &g
On Wed, Mar 11, 2020 at 2:36 PM Amit Kapila wrote:
>
> On Tue, Mar 10, 2020 at 6:39 PM Robert Haas wrote:
> >
> > On Fri, Mar 6, 2020 at 11:27 PM Dilip Kumar wrote:
> > > I think instead of the flag we need to keep the counter because we can
> > > acqu
On Thu, Mar 12, 2020 at 5:28 PM Amit Kapila wrote:
>
> On Thu, Mar 12, 2020 at 11:15 AM Dilip Kumar wrote:
> >
> > I have fixed this in the attached patch set.
> >
>
> I have modified your
> v4-0003-Conflict-Extension-Page-lock-in-group-member patch. The
&
On Fri, Mar 13, 2020 at 8:29 AM Amit Kapila wrote:
>
> On Thu, Mar 12, 2020 at 7:50 PM Kuntal Ghosh
> wrote:
> >
> > On Thu, Mar 12, 2020 at 5:28 PM Amit Kapila wrote:
> > >
> > > On Thu, Mar 12, 2020 at 11:15 AM Dilip Kumar
> > > wrote:
&
On Fri, Mar 13, 2020 at 11:08 AM Amit Kapila wrote:
>
> On Thu, Mar 12, 2020 at 3:04 PM Dilip Kumar wrote:
> >
> > On Wed, Mar 11, 2020 at 2:36 PM Amit Kapila wrote:
> > >
> > >
> > > If we have no other choice, then I see a few downsides of ad
the recent version of the patch, instead of a counter, we have done
with a flag. So I think now we can just keep a single variable and we
can just reset the bit in a single instruction.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Mar 13, 2020 at 11:16 AM Dilip Kumar wrote:
>
> On Fri, Mar 13, 2020 at 11:08 AM Amit Kapila wrote:
> >
> > On Thu, Mar 12, 2020 at 3:04 PM Dilip Kumar wrote:
> > >
> > > On Wed, Mar 11, 2020 at 2:36 PM Amit Kapila
> > > wrote:
> > &
On Fri, Mar 13, 2020 at 3:39 PM Amit Kapila wrote:
>
> On Fri, Mar 13, 2020 at 8:37 AM Dilip Kumar wrote:
> >
> > On Thu, Mar 12, 2020 at 5:28 PM Amit Kapila wrote:
> > >
> > > On Thu, Mar 12, 2020 at 11:15 AM Dilip Kumar
> > > wrote:
> >
On Sat, Mar 14, 2020 at 7:39 PM Amit Kapila wrote:
>
> On Fri, Mar 13, 2020 at 7:02 PM Dilip Kumar wrote:
> >
> > Apart from that, I have also extended the solution for the page lock.
> > And, I have also broken down the 3rd patch in two parts for relation
> > e
On Sun, Mar 15, 2020 at 1:15 PM Dilip Kumar wrote:
>
> On Sat, Mar 14, 2020 at 7:39 PM Amit Kapila wrote:
> >
> > On Fri, Mar 13, 2020 at 7:02 PM Dilip Kumar wrote:
> > >
> > > Apart from that, I have also extended the solution for the page lock.
> > &g
On Sun, Mar 15, 2020 at 5:58 PM Amit Kapila wrote:
>
> On Sun, Mar 15, 2020 at 1:15 PM Dilip Kumar wrote:
> >
> > On Sat, Mar 14, 2020 at 7:39 PM Amit Kapila wrote:
> > >
> > > On Fri, Mar 13, 2020 at 7:02 PM Dilip Kumar wrote:
> > > >
> >
On Sun, Mar 15, 2020 at 6:20 PM Amit Kapila wrote:
>
> On Sun, Mar 15, 2020 at 4:34 PM Dilip Kumar wrote:
> >
> > I have modified 0001 and 0002 slightly, Basically, instead of two
> > function CheckAndSetLockHeld and CheckAndReSetLockHeld, I have cr
On Mon, Mar 16, 2020 at 8:57 AM Masahiko Sawada
wrote:
>
> On Mon, 16 Mar 2020 at 00:54, Dilip Kumar wrote:
> >
> > On Sun, Mar 15, 2020 at 6:20 PM Amit Kapila wrote:
> > >
> > > On Sun, Mar 15, 2020 at 4:34 PM Dilip Kumar wrote:
> > > >
On Mon, Mar 16, 2020 at 8:15 AM Amit Kapila wrote:
>
> On Sun, Mar 15, 2020 at 9:17 PM Dilip Kumar wrote:
> >
> > On Sun, Mar 15, 2020 at 5:58 PM Amit Kapila wrote:
> > >
> > >
> > > 1. Group members wait for page locks. If you test that the leader
On Mon, Mar 16, 2020 at 11:56 AM Kuntal Ghosh
wrote:
>
> On Mon, Mar 16, 2020 at 9:43 AM Dilip Kumar wrote:
> > On Mon, Mar 16, 2020 at 8:57 AM Masahiko Sawada
> > wrote:
> > > IsRelationExtensionLockHeld and IsPageLockHeld are used only when
> > > asser
On Tue, Mar 17, 2020 at 5:14 PM Amit Kapila wrote:
>
> On Mon, Mar 16, 2020 at 3:24 PM Dilip Kumar wrote:
> >
>
> +
> + /*
> + * Indicate that the lock is released for certain types of locks
> + */
> +#ifdef USE_ASSERT_CHECKING
> + CheckAndSetLock
On Tue, Mar 24, 2020 at 6:16 PM Amit Kapila wrote:
>
> On Mon, Mar 9, 2020 at 11:07 PM Andres Freund wrote:
> >
> > On 2020-03-07 11:15:27 +0530, Dilip Kumar wrote:
> > > IMHO, if we conclude that because there is no performance gain so we
> > > don't wa
On Wed, Mar 25, 2020 at 9:23 AM Amit Kapila wrote:
>
> On Wed, Mar 25, 2020 at 12:46 AM Andres Freund wrote:
> >
> > On 2020-03-24 18:36:03 +0530, Dilip Kumar wrote:
> > > IMHO, I have tried the best case but did not see any performance gain
> > > so I am n
ckend/optimizer/util/pathnode.c | 46 +
src/include/nodes/nodes.h | 1 +
src/include/nodes/pathnodes.h | 19 +++
src/include/nodes/print.h | 1 +
src/include/optimizer/pathnode.h | 2 +
src/include/optimizer/paths.h | 11 +
15 files chan
On Sat, Mar 28, 2020 at 11:56 AM Amit Kapila wrote:
>
> On Wed, Mar 4, 2020 at 9:14 AM Dilip Kumar wrote:
> >
> > On Wed, Mar 4, 2020 at 3:16 AM Tomas Vondra
> > wrote:
> > >
> > >
> > > The first thing I realized that WAL-logging of assignme
> avoid
> > declaring i outside the for scope?
>
> We can do that but I was not sure if it's good since other codes
> around there don't use that. So I'd like to leave it for committers.
> It's a trivial change.
I have reviewed the patch and the patch looks fine to me.
One minor comment
/+ /* Points to buffer usage are in DSM */
+ BufferUsage *buffer_usage;
+
/buffer usage are in DSM / buffer usage area in DSM
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
or wal_num_fpw or
wal_fpw_count?
4. Currently, we are combining all full-page write
force/normal/consistency checks in one category. I am not sure
whether it will be good information to know how many are force_fpw and
how many are normal_fpw?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Mar 31, 2020 at 12:20 PM Dilip Kumar wrote:
>
> On Tue, Mar 31, 2020 at 10:44 AM Masahiko Sawada
> wrote:
> >
> > On Tue, 31 Mar 2020 at 12:58, Amit Kapila wrote:
> > >
> > > On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada
> > > wrote
On Wed, Apr 1, 2020 at 8:16 AM Amit Kapila wrote:
>
> On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote:
> >
> > While testing I have found one issue. Basically, during a parallel
> > vacuum, it was showing more number of
> > shared_blk_hits+shared_blks_read. Afte
On Wed, Apr 1, 2020 at 8:26 AM Masahiko Sawada
wrote:
>
> On Wed, 1 Apr 2020 at 11:46, Amit Kapila wrote:
> >
> > On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote:
> > >
> > > While testing I have found one issue. Basically, during a parallel
> &g
On Wed, Apr 1, 2020 at 8:51 AM Dilip Kumar wrote:
>
> On Wed, Apr 1, 2020 at 8:26 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 1 Apr 2020 at 11:46, Amit Kapila wrote:
> > >
> > > On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote:
> > > >
>
On Wed, Apr 1, 2020 at 12:01 PM Amit Kapila wrote:
>
> On Wed, Apr 1, 2020 at 8:51 AM Dilip Kumar wrote:
> >
> > > Agreed. I've attached the updated patch.
> > >
> > > Thank you for testing, Dilip!
> >
> > Thanks! One hunk is failing on th
1 on test(a);
CREATE INDEX
postgres[106479]=# VACUUM (PARALLEL 0) test;
VACUUM
postgres[106479]=# select query , wal_bytes, wal_records, wal_num_fpw
from pg_stat_statements where query like 'VACUUM%';
query | wal_bytes | wal_records | wal_num_fpw
---
> are rather small differences, overall.
> Can Dilip demonstrate the the "extra" buffer accesses are
> proportionate to the number of workers launched in some constant,
> predictable way?
Okay, I will test this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Apr 2, 2020 at 9:13 AM Dilip Kumar wrote:
>
> On Thu, Apr 2, 2020 at 8:34 AM Peter Geoghegan wrote:
> >
> > On Wed, Apr 1, 2020 at 7:52 PM Amit Kapila wrote:
> > > Peter, Is this behavior expected?
> > >
> > > Let me summarize the situ
t; > 7.
> > + values[i++] = Int64GetDatumFast(tmp.wal_records);
> > + values[i++] = UInt64GetDatum(tmp.wal_num_fpw);
> >
> > Why are they different? I think we should use the same *GetDatum API
> > (probably Int64GetDatumFast) for these.
>
>
> Oops, that'
msec */
> double usage; /* usage factor */
>
> It is better to keep wal_bytes should be after wal_num_fpw as it is in
> the main patch. Also, consider changing at other places in this
> patch. I think we should add these new fields after blk_write_time or
> at the end after usage.
>
> 4.
> /* # of WAL full page image generated */
> Can we change it to "/* # of WAL full page image records generated */"?
IMHO, "# of WAL full-page image records" seems like the number of wal
record which contains the full-page image. But, actually, this is the
total number of the full-page images, not the number of records that
have a full-page image.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
other WALs
are of the same size.
t1_idx_parallel_0:
rmgr: Heaplen (rec/tot): 54/ 7498, tx:489, lsn:
0/0167B9B0, prev 0/0167B970, desc: INSERT off 30 flags 0x01, blkref
#0: rel 1663/13580/1249
t1_idx_parallel_1:
rmgr: Heaplen (rec/tot): 54/ 8218, tx:494,
On Fri, Apr 3, 2020 at 8:14 AM Amit Kapila wrote:
>
> On Fri, Apr 3, 2020 at 6:37 AM Amit Kapila wrote:
> >
> > On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar wrote:
> > >
> > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila
> > > wrote:
> >
On Thu, Apr 2, 2020 at 9:28 PM Dilip Kumar wrote:
>
> On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote:
> >
> > On Thu, Apr 2, 2020 at 6:18 PM Julien Rouhaud wrote:
> > >
> > > =# select query, calls, wal_bytes, wal_records, wal_num_fpw from
> > >
On Fri, Apr 3, 2020 at 9:02 AM Amit Kapila wrote:
>
> On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote:
> >
> > I think now I got the reason. Basically, both of these records are
> > storing the FPW, and FPW size can vary based on the hole size on the
> > page
On Fri, Apr 3, 2020 at 9:17 AM Dilip Kumar wrote:
>
> On Fri, Apr 3, 2020 at 9:02 AM Amit Kapila wrote:
> >
> > On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote:
> > >
> > > I think now I got the reason. Basically, both of these records are
> > > st
t; > >
> >
> > I think this is more close to the case of Buffers where all fields are
> > directly related to buffers/blocks. Here all the fields we want to
> > display are related to WAL, so we should try to make it display
> > similar to Buffers.
> >
>
> Dilip, Julien, others, do you have any suggestions here? I think we
> need to decide something now. We can change a few things like from
> 'two spaces' to 'one space' between fields later as well.
I also think it is more close to the BufferUsage so better to keep
similar to that. If we think the parsing is the problem we can keep
'_' in the multi-word name as shown below.
WAL: records=n full_page_writes=n bytes=n
And, all three fields are related to WAL so we can use WAL: followed
by other fields as we are doing now in the current patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Mar 25, 2020 at 2:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Mar 25, 2020 at 11:31:56AM +0530, Dilip Kumar wrote:
> >
> > Seems like you forgot to add the uniquekey.c file in the
> > v33-0001-Unique-key.patch.
>
> Oh, you'r
On Sun, Apr 5, 2020 at 9:39 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote:
> >
> > I was just wondering how the distinct will work with the "skip scan"
> > if we have some filter?
On Mon, Apr 6, 2020 at 1:14 PM Floris Van Nee wrote:
>
> > > > On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote:
> > > >
> > > > I was just wondering how the distinct will work with the "skip scan"
> > > > if we have some fil
rty we can't guarantee anyway.
>
Make sense, I have started working on this idea, I will try to post the
first version by early next week.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e have the complete toast tuple as part of
the WAL and we recreate the tuple in memory in reorder buffer, so even if
it can by ON DISK format inside INDIRECT format but we have complete tuple.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
reating multiple work queues based on more factors which
can dynamically change.
>
> I know that this email is kind of a giant wall of text, so my thanks
> if you've read this far, and even more if you feel inspired to write
> back with your own thoughts.
Yeah it is a long email but quite interesting.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Patches can be applied on the latest conveyor belt patches[1]
[1]
https://www.postgresql.org/message-id/CAFiTN-sQUddO9JPiH3tz%2BvbNqRqi_pgndecy8k2yXAnO3ymqZA%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 7fb07fcb8aca82e3629dcf90113c1bbaf511c343 Mon Sep
eModifiedColumns and moving part of heap_tuple_attr_equals
code into the caller. Here is the patch set for the same. I have
divided it into two patches which can eventually be merged, 0001- for
refactoring 0002- does the actual work.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jan 19, 2022 at 10:37 AM Dilip Kumar wrote:
>
> On Thu, Jan 6, 2022 at 7:22 PM Robert Haas wrote:
>>
>> On Thu, Jan 6, 2022 at 3:47 AM Thomas Munro wrote:
>> > Another problem is that relfilenodes are normally allocated with
>> > GetNewOidWithIndex
On Sat, Jan 29, 2022 at 3:57 PM Amit Kapila wrote:
>
> On Fri, Jan 28, 2022 at 12:16 PM Dilip Kumar wrote:
> >
> + /*
> + * If it's a whole-tuple reference, say "not equal". It's not really
> + * worth supporting this case, since it could only succeed af
snapshot by
> using xip instead of subxip. It is cleaner but it has far larger
> chance of needing to retry.
>
> (renamed the patch since it represented a part of the patch)
>
Thanks for the updated version. I will look into it this week.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jan 31, 2022 at 7:36 PM Robert Haas wrote:
>
> On Mon, Jan 31, 2022 at 9:04 AM Robert Haas wrote:
> > On Mon, Jan 31, 2022 at 12:29 AM Dilip Kumar wrote:
> > > the main one currently we do not have uint8 data
> > > type only int8 is there so I have use
On Wed, Feb 2, 2022 at 6:57 PM Robert Haas wrote:
>
> On Mon, Jan 31, 2022 at 9:37 AM Dilip Kumar wrote:
> > I agree that we are using 8 bytes unsigned int multiple places in code
> > as uint64. But I don't see it as an exposed data type and not used as
> > part of
On Fri, Feb 4, 2022 at 11:45 PM Robert Haas wrote:
>
> On Wed, Jan 26, 2022 at 8:58 AM Dilip Kumar wrote:
> > TODO:
> > - This is just a POC patch to discuss the design idea and needs a lot
> > of improvement and testing.
> > - We are using a slightly different fo
ents and docs though.
> > >
> >
> > Thanks, your suggestions look good to me. I'll take care of these in
> > the next version.
> >
>
> Attached please find the modified patches.
I have looked into the latest modification and back branch patches and
they look fine to me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jan 31, 2022 at 11:50 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 17 Jan 2022 09:27:14 +0530, Dilip Kumar wrote
> in
>
> me> Mmm. The size of the array cannot be larger than the numbers the
> me> *Connt() functions return. Thus we cannot attach the oversized arra
On Mon, Feb 7, 2022 at 9:42 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 12:26 AM Dilip Kumar wrote:
> > I have splitted the patch into multiple patches which can be
> > independently committable and easy to review. I have explained the
> > purpose and scope of each
lar case using regexp_replace as you explained
would be a good option as we will be verifying complete data instead
of just the first 200 characters.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
trying to make for removing the tombstone
files.
[1]https://www.postgresql.org/message-id/CAE9k0Pkg20tHq8oiJ%2BxXa9%3Daf3QZCSYTw99aBaPthA1UMKhnTg%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CA%2BTgmobM5FN5x0u3tSpoNvk_TZPFCdbcHxsXCoY1ytn1dXROvg%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Feb 8, 2022 at 10:42 PM Peter Geoghegan wrote:
>
> On Sun, Feb 6, 2022 at 11:25 PM Dilip Kumar wrote:
> > > One thing we could try doing in order to make that easier would be:
> > > tweak things so that when autovacuum vacuums the table, it only
> > >
a combination of index size
bloat and % dead tuples. Maybe we can add more weight to the size
bloat and less weight to % dead tuple but we should not completely
ignore it.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Feb 7, 2022 at 10:13 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 11:31 AM Dilip Kumar wrote:
> > For RelFileNode also we need to use 2, 32-bit integers so that we do
> > not add extra alignment padding because there are a few more
> > structures that
27;t seem to be much we can do about that except document
* it as a limitation.
*
* Perhaps if we ever implement CREATE DATABASE in a less cheesy way,
* we can avoid this.
*/
RequestCheckpoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_FORCE | CHECKPOINT_WAIT);
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Feb 9, 2022 at 9:25 PM Andrew Dunstan wrote:
>
>
> On 6/16/21 03:52, Dilip Kumar wrote:
> > On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan wrote:
> >> Rather than use size, I'd be inclined to say use this if the source
> >> database is marked as a
On Wed, Feb 9, 2022 at 7:43 PM Robert Haas wrote:
>
> On Wed, Feb 9, 2022 at 1:18 AM Dilip Kumar wrote:
> I think that dead index tuples really don't matter if they're going to
> get removed anyway before a page split happens. In particular, if
> we're going to
On Wed, Feb 9, 2022 at 9:31 PM Robert Haas wrote:
>
> On Wed, Feb 9, 2022 at 10:59 AM Dilip Kumar wrote:
> > On Wed, Feb 9, 2022 at 9:25 PM Andrew Dunstan wrote:
> > > On 6/16/21 03:52, Dilip Kumar wrote:
> > > > On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan
ckAcquire(ControlFileLock, LW_EXCLUSIVE);
+
XLogCtl->InstallXLogFileSegmentActive = false;
+ LWLockRelease(ControlFileLock);
+ }
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Feb 11, 2022 at 6:22 PM Bharath Rupireddy
wrote:
>
> On Fri, Feb 11, 2022 at 3:33 PM Dilip Kumar wrote:
> >
> IIUC, the issue can happen while the walreceiver failed to get WAL
> from primary for whatever reasons and its status is not
> WALRCV_STOPPING or WALRCV_STO
choose not
to WAL log then we will have to do a checkpoint internally. So I
think giving LOG vs CHECKPOINT as an explicit option looks better to
me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar wrote:
>
I have done performance testing with different template DB sizes and
different amounts of dirty shared buffers and I think as expected the
bigger the dirty shared buffer the checkpoint approach becomes costly
and OTOH the larger the templ
On Sun, Feb 13, 2022 at 9:56 PM Robert Haas wrote:
>
> On Sun, Feb 13, 2022 at 1:34 AM Dilip Kumar wrot>
> > test4:
> > 32 GB shared buffers, template DB size = 10GB, dirty shared buffer=70%
> > Head: 47656 ms
> > Patch: 79767 ms
>
> This seems like the mo
On Sun, Feb 13, 2022 at 12:04 PM Dilip Kumar wrote:
>
> On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar wrote:
> Next, I am planning to do some more tests, where we are having pgbench
> running and concurrently we do CREATEDB maybe every 1 minute and see
> what is the CREATEDB time
(Monday) unless there are any more suggestions or comments.
> >
>
> Pushed!
>
Thanks!!
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Feb 14, 2022 at 10:31 AM Dilip Kumar wrote:
>
> On Sun, Feb 13, 2022 at 9:56 PM Robert Haas wrote:
> >
> > On Sun, Feb 13, 2022 at 1:34 AM Dilip Kumar wrot>
> > > test4:
> > > 32 GB shared buffers, template DB size = 10GB, dirty shared buffer=70%
dating 70% of the database could have some
impact but for verification purposes I tested without the update and
still the create db with WAL log is taking almost the same time. But
anyway when I test next time I will verify again that no force
checkpoint is triggered.
--
Regards,
Dili
On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar wrote:
>
> On Sat, Feb 12, 2022 at 2:38 AM Alvaro Herrera
> wrote:
> > It seems you're thinking deciding what to do based on an option that
> > gets a boolean argument. But what about making the argument be an enum?
>
ASE ... WITH (STRATEGY = FILE_COPY);
I have updated the document but I was not sure how much internal
information to be exposed to the user so I will work on that based on
feedback from others.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
F
e to be able to add
> the "compression=lots" option at the same time I make the switch.
> There needs to be some syntax for that.
>
> One way to solve the first of these problem is to silently drop
> unsupported options. Maybe a better way is to have syntax that allows
> you to specify options to be added and removed at the time you switch
> AMs e.g.:
>
+1
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
.org/message-id/CAFiTN-v1KYsVAhq_fOWFa27LZiw9uK4n4cz5XmQJxJpsVcfq1w%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAFiTN-v%3DU58by_BeiZruNhykxk1q9XUxF%2BqLzD2LZAsEn2EBkg%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
database? Yeah that is
correct but what is the problem in that, other backends can not
connect to the source database so what problem can they create to the
backend which is copying the database.
> Or what if somebody optimized snapshots to disregard readonly transactions in
> other databases?
Can you elaborate on this point?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Actually, we will see the problem as soon as it has crossed 64 because
after that for any visibility checking we need to check the SLRU. So
I feel both count and overflow are important. Count to know that we
are heading towards overflow and overflow to know that it has already
happened.
ly one column then this could be the
best way to show.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
shot->subxip, and only if it is not found in that we will look
into the SLRU. So now because of 1) we will always find any
concurrent subtransaction in "snapshot->subxip".
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
nce of the problem is already obvious from the SLRU-related
> wait events.
>
Even I feel per backend-wise information would be more useful and easy
to use instead of a single summary row. I think It's fine to create a
new view if we do not want to add more members to the existing view.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
int was to make sure
> certain existing notifications will be preserved - sure, why not.
IMHO, after having 64-bit XID this WARNING doesn't really make sense.
Those warnings exist because those limits were problematic for 32-bit
xid but now it is not so I think we should not have such warnings.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
the index vacuum when we think there are enough dead items so that
the index vacuum makes sense[1].
[1]
https://www.postgresql.org/message-id/CA%2BTgmoZgapzekbTqdBrcH8O8Yifi10_nB7uWLB8ajAhGL21M6A%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Nov 24, 2022 at 9:39 PM Justin Pryzby wrote:
> On Thu, Nov 24, 2022 at 08:52:16PM +0530, Dilip Kumar wrote:
> > but now you will have one gigantic index and which will be vacuumed
> > every time we vacuum any of the partitions.
>
> This patch isn't implemen
On Fri, Nov 25, 2022 at 8:49 AM Dilip Kumar wrote:
>
> On Thu, Nov 24, 2022 at 9:39 PM Justin Pryzby wrote:
> > On Thu, Nov 24, 2022 at 08:52:16PM +0530, Dilip Kumar wrote:
> > > but now you will have one gigantic index and which will be vacuumed
> > > every time w
k into the pg_subtrans SLRU and
fetch the top xid and relook again into the xip array. It will be
more costly in cases where we do not find xid in the xip array because
then we will have to search this array twice but I think looking into
this array is much cheaper than directly accessing SLRU.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ransaction should have never been streamed.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 20cc1084c4943bdaf23753f2a7d9add22097ed95 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Fri, 25 Nov 2022 13:11:44 +0530
Subject: [PATCH v1] Fix thinko in when to stream a transaction
on that will be used by streaming as well as by DecodeCommit to
decide on whether to skip or not.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sat, Nov 26, 2022 at 12:15 PM Amit Kapila wrote:
>
> On Fri, Nov 25, 2022 at 5:38 PM Amit Kapila wrote:
> >
> > On Fri, Nov 25, 2022 at 1:35 PM Dilip Kumar wrote:
> > >
> > > During DecodeCommit() for skipping a transaction we use ReadRecPtr to
> > &
801 - 900 of 1730 matches
Mail list logo
