ieve the same then we can consider the current approach as well.
> > >
> >
> > Next patch, I'll work on addressing this comment. I'll need to
> > restructure the code to make this happen.
> >
>
> Okay, thanks Ajin. I will resume review after this comment is
> addressed as I am assuming that the new logic will get rid of most of
> the current wait logic and thus it makes sense to review it after it
> is addressed.
There's also a minor merge conflict because func.sgml is not split
into multiple files.
--
Best Wishes,
Ashutosh Bapat
On Tue, Aug 5, 2025 at 9:50 AM Amit Kapila wrote:
>
> On Fri, Aug 1, 2025 at 5:06 PM Ashutosh Bapat
> wrote:
> >
> > On Fri, Aug 1, 2025 at 4:03 PM Amit Kapila wrote:
> > >
> > > Now, seeing this report, it seems the customer(s) are probably okay to
&
ement recently when working for a customer
case. The previous discussion isn't thorough and doesn't show that we
didn't want this feature that time. +1 for the feature.
I haven't reviewed the patches though.
--
Best Wishes,
Ashutosh Bapat
itoring but users may find other usages.
+
+step commit1: COMMIT;
+step commit2: COMMIT;
+step check:
+ SELECT
+ multixacts,
+ members,
+ oldest_multixact
+ FROM pg_get_multixact_stats();
+
+multixacts|members|oldest_multixact
+--+---+
+ 1| 3| 1
+(1 row)
Vacuum may clean the multixact between commit2 and check, in which
case the result won't be stable.
--
Best Wishes,
Ashutosh Bapat
> +1 here too.
>
> Cool, thanks, done. Now we need a volunteer to set up a buildfarm
> animal with this flag ...
Your patch didn't contain doc changes. But the commit has it. Thanks.
--
Best Wishes,
Ashutosh Bapat
Probably not since that code is old
enough to have less chances of bugs. So +1.
--
Best Wishes,
Ashutosh Bapat
On Mon, Aug 4, 2025 at 4:08 PM vignesh C wrote:
>
> On Mon, 4 Aug 2025 at 09:47, Ashutosh Bapat
> wrote:
> >
> > Hi Vignesh,
> > Thanks for the patches.
> >
> > On Sat, Aug 2, 2025 at 7:10 PM vignesh C wrote:
> >
> > > >
> > >
l. Instead capturing
offset before dropping publication may be safer - the publication
exists till it dropped, so the log file cannot have WARNING in there
when offset is captured.
--
Best Wishes,
Ashutosh Bapat
On Fri, Aug 1, 2025 at 4:03 PM Amit Kapila wrote:
>
> On Fri, Aug 1, 2025 at 10:54 AM Ashutosh Bapat
> wrote:
> >
> > Hi Vignesh, Amit,
> > We encountered a situation where a customer dropped a publication
> > accidentally and that broke logical replication in
s approach is that it doesn't report the space
consumed on the disk, which is more important than the member count.
If you approach allows to do that easily, that will be an added
advantage.
--
Best Wishes,
Ashutosh Bapat
On Fri, Aug 1, 2025 at 11:14 AM Dilip Kumar wrote:
>
> On Fri, Aug 1, 2025 at 10:55 AM Ashutosh Bapat
> wrote:
> >
> > Hi Vignesh, Amit,
> > We encountered a situation where a customer dropped a publication
> > accidentally and that broke logical replication in
tion.
The backport seems to be straight forward. Please let me know if you
need my help in doing so, if we decide to backport the fix.
--
Best Wishes,
Ashutosh Bapat
On Tue, Jul 29, 2025 at 6:36 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > I am seeing following error only with buildtype = release
>
> Interesting. I noticed skink showing the same thing as a warning,
> but no other BF animals have shown it (yet anyway).
>
>
o, but it
might provide a hint.
--
Best Wishes,
Ashutosh Bapat
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 25b287be069..b51ff108741 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@
I have not included this patch in the latest patchset. Given that
Peter E has written the grammar, it best be handled by him. Please
feel free to post it again as an additional patch in the latest
patchset. A standalone patch like this confused CI Bot.
--
Best Wishes,
Ashutosh Bapat
ldestmultixact::text::xid) from
pg_get_multixact_count();
oldestmultixact | pg_get_multixact_members
--+--
1 | (757,sh)
1 | (768,sh)
(2 rows)
Here's a quick patch implementing the same. Please feel free to
incorporate and refine it in your
On Sat, Jul 26, 2025 at 4:59 PM Etsuro Fujita wrote:
>
> On Fri, Jul 25, 2025 at 7:59 PM Ashutosh Bapat
> wrote:
> > On Fri, Jul 25, 2025 at 3:22 PM Etsuro Fujita
> > wrote:
> > > On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
> > > wrote:
> &g
On Tue, Jul 22, 2025 at 7:31 PM Andrei Lepikhov wrote:
>
> On 18/7/2025 13:48, Ashutosh Bapat wrote:
> > On Mon, Jul 7, 2025 at 8:43 PM Andrei Lepikhov wrote:
> > if (!IsA(new_path, IndexPath))
> > - pfree(new_path);
> > + free_path(new_path, 0, false);
> >
&
On Fri, Jul 25, 2025 at 3:22 PM Etsuro Fujita wrote:
>
> Hi Ashutosh,
>
> On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
> wrote:
> > On Wed, Jul 23, 2025 at 4:16 PM Etsuro Fujita
> > wrote:
> > > On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita
> >
this function: to know when the autovacuum is going to be more
aggressive.
+
+ values[0] = UInt32GetDatum(multixacts);
+ values[1] = UInt32GetDatum(members);
+
+ tuple = heap_form_tuple(tupdesc, values, nulls);
+ PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
+}
In PG14+, the transaction wraparound is triggered if the size of the
directory exceeds 10GB. This function does not help monitoring that
condition. So a user will need to use du or pg_ls_multixactdir()
anyway, which defeats the purpose of this function being more
efficient than those methods. Am I correct? Can we also report the
size of the directory in this function?
The patch needs tests.
[1] https://www.postgresql.org/message-id/aF8b_fp_9Va58vB9%40nathan
--
Best Wishes,
Ashutosh Bapat
objects like columns which do not have an independent DDL. Or maybe we
could re-imagine DDL for such objects as ALTER ADD variant for
that object. For example, in case of a column it would be ALTER TABLE
... ADD COLUMN
[1]
https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-INFO-OBJECT-TABLE
--
Best Wishes,
Ashutosh Bapat
Hi Amit,
On Mon, Jul 14, 2025 at 3:31 PM Amit Kapila wrote:
>
> On Mon, Jul 14, 2025 at 10:55 AM Ashutosh Bapat
> wrote:
> >
> > On Sun, Jul 13, 2025 at 4:34 PM Amit Kapila wrote:
> > >
> > >
> > > I think we don't want to make it man
ntioning restriction like below?
"This option is only allowed for an AFTER trigger on tables other than
views or foreign tables. The trigger should not be a constraint
trigger. If the trigger is an UPDATE trigger, it must not specify a
column_name list when using this option."
--
Best Wishes,
Ashutosh Bapat
additional computation time each
> night. Apparently I have to scale down on the amount of work that can be done
> in one night.
Can you please provide "explain analyze" output of both the queries
across both releases for investigation.
--
Best Wishes,
Ashutosh Bapat
On Mon, Jul 7, 2025 at 8:43 PM Andrei Lepikhov wrote:
>
> On 27/6/2025 12:01, Andrei Lepikhov wrote:
> > On 6/2/2024 13:51, Ashutosh Bapat wrote:
> >> On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
> >> wrote:
> >> First patch is no longer required. Here&
Hi All,
On Mon, Jan 27, 2025 at 11:22 AM Ashutosh Bapat
wrote:
>
> On Mon, Nov 25, 2024 at 7:06 PM Nazir Bilal Yavuz wrote:
> >
> > It is added and marked as ready for the committer [1]. There are
> > multiple 'Jian He' users in the commitfest app, so I
ure releases.
>
Please check if the proposal at [1] suits your needs.
[1]
https://www.postgresql.org/message-id/149ff9264db27cdf724b65709fbbaee4bf316835.camel%40j-davis.com
--
Best Wishes,
Ashutosh Bapat
On Mon, Jul 14, 2025 at 1:40 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Jul 14, 2025 at 10:25:51AM +0530, Ashutosh Bapat wrote:
> > > Currently it's being addressed via every backend waiting for each other,
> > > but I guess it could be as
On Sun, Jul 13, 2025 at 4:34 PM Amit Kapila wrote:
>
> On Tue, Jul 1, 2025 at 7:35 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
> > >
> > > On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> > > wrote:
>
ckends not waiting for
> each other and buffers first allocated and then marked as "available to
> use".
Should all the backends wait between buffer allocation and them being
marked as "available"? I assume that marking them as available means
"declaring the new NBuffers". What about when shrinking the buffers?
Do you plan to make all the backends wait while the coordinator is
evicting buffers?
--
Best Wishes,
Ashutosh Bapat
On Thu, Jul 10, 2025 at 8:49 AM Amit Kapila wrote:
>
> On Wed, Jul 9, 2025 at 6:50 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jul 9, 2025 at 8:30 AM shveta malik wrote:
> > > >
> > > > I have split your top up patch into 2 - one related to the docu
on also needs a bit of clarification. Here's patch with that
change. Please feel free to reject it or apply it.
--
Best Wishes,
Ashutosh Bapat
From 6e415d5c83d6f2cddfd7e81824997c99b2529c24 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Wed, 9 Jul 2025 18:41:40 +0530
Subject: [P
On Tue, Jul 8, 2025 at 4:03 PM shveta malik wrote:
>
> On Mon, Jul 7, 2025 at 7:00 PM Ashutosh Bapat
> wrote:
> >
> > On Mon, Jul 7, 2025 at 9:53 AM shveta malik wrote:
> > >
> > > Thanks for the patch.
> > >
> > > > I could
, would
the translation system be able to make use of this information. I am
not familiar with the translation system and I might be wrong in
making such an assumption.
--
Best Wishes,
Ashutosh Bapat
ion process. E.g. for example it could tell whether to
wait for a backend to unpin a buffer or cancel that query or kill the
backend or abort the application itself. If the operation takes too
long, a user may want to cancel the function execution just like
cancelling a query. Running two concurrent instances of the function,
both applying the same GUC won't be allowed.
Does that look good?
--
Best Wishes,
Ashutosh Bapat
ew more
> trivial changes. Please include it if you find it okay.
Thanks. Included. I have made a few edits and included them in the
attached patch.
--
Best Wishes,
Ashutosh Bapat
From 09a37694180af7adcd56b4201bbd9a6fc945e586 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Fri, 4 Jul 2025
he table
is partitioned and what replica identity settings its partitions have.
And document.
Since the targeted use of this column is to know the replica
identities of the tables published by a given publication so that they
can guess what might be WAL logged, these options seem ok along with
the clarifying documentation.
What do you think?
--
Best Wishes,
Ashutosh Bapat
; release notes correction?
>
This is the right place to discuss this. Please add your patch to the
commitfest App. https://commitfest.postgresql.org/. The landing page
has a useful link for first timers.
> Best regards,
> Steve Chavez
>
Please do not top-post, reply inline as I have done.
--
Best Wishes,
Ashutosh Bapat
be synchronized should filter based on invalidation_reason
and conflicting or not. According to synchronize_slots(), it seems
that we retain invalidated slots on standby when failover = true and
they would remain with synced = true on standby. Is that right?
--
Best Wishes,
Ashutosh Bapat
From 16
has the code for the same.
[1]
https://www.postgresql.org/message-id/my4hukmejato53ef465ev7lk3sqiqvneh7436rz64wmtc7rbfj%40hmuxsf2ngov2
--
Best Wishes,
Ashutosh Bapat
On Thu, Jul 3, 2025 at 9:32 AM Amit Kapila wrote:
>
> On Wed, Jul 2, 2025 at 5:50 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jul 2, 2025 at 12:36 PM shveta malik wrote:
> > >
> > > On Wed, Jul 2, 2025 at 10:50 AM Ashutosh Bapat
> > > wrote:
>
tion allows that).
Yes. I think, we have to find a better way to choose a backend which
does the actual work. Eviction can be done in that backend itself.
Compiler gives warning about an uninitialized variable, which seems to
be a real bug. Fix attached.
--
Best Wishes,
Ashutosh Bapat
commit 5c54d36d2
On Wed, Jul 2, 2025 at 12:36 PM shveta malik wrote:
>
> On Wed, Jul 2, 2025 at 10:50 AM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> >
> > The failover slots documentation [1] is good for PG - PG logical
> > replication, but the first two queries require pg_su
'd
> require a bit of code invoked sometime after the resize. It'd already
> need to rebuild the freelists in some way, I guess.
Yes, there's code to build the free list. I think we will need code to
remap the buffers and buffer descriptor.
--
Best Wishes,
Ashutosh Bapat
that the
3rd query should also include the slots mentioned in
sync_replication_slots for PG-non_PG logical replication setup.
[1] https://www.postgresql.org/docs/current/logical-replication-failover.html
--
Best Wishes,
Ashutosh Bapat
On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> > In a recent logical replication issue, there were multiple replication
> > slots involved, each using a different publication. Thu
On Mon, Jun 30, 2025 at 5:17 PM Amit Kapila wrote:
>
> On Mon, Jun 30, 2025 at 3:44 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> >
> > The commit message in the patch says it all, but let me repeat it here.
> >
>
> You forgot to attach the patch.
eplica_identity
--++-+--+---+--
testpub6 | public | rf_tbl_abcd_part_pk | {a,b}| (b > 99) | default
(1 row)
This line gives all the information related to logical replication of
table rf_tbl_abcd_part_pk together.
--
Best Wishes,
Ashutosh Bapat
do not contain that change. If others feel the same way, I will
provide a patch with that change.
--
Best Wishes,
Ashutosh Bapat
From 1a385b30d6cb4ca111cbcc16ea14017c08f9a579 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Fri, 27 Jun 2025 09:16:23 +0530
Subject: [PATCH]
I ended up moving it to the
> "Transaction ID and Snapshot Information Functions" table, which is what I
> think you had originally proposed. Creating a new section for this seemed
> unnecessary, and this table already has one multixact-related function.
WFM.
--
Best Wishes,
Ashutosh Bapat
onal. Otherwise Coverity
> is likely to complain about how we're ignoring the result in
> one place and not the other.
+1.
On Tue, Jun 24, 2025 at 10:03 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > On Tue, Jun 24, 2025 at 5:26 AM Tom Lane wrote:
> >&g
ch it records the time when worker launch for that
table was attempted so that next attempt could be well-spaced in time.
I am not able your last statement, what is the entry's relevance to
the worker.
But your change makes this code similar to ApplyLauncherMain(), which
deals with subscriptions. +1 for the consistency.
--
Best Wishes,
Ashutosh Bapat
hes in the current commitfest
All patches in the open commitfest
Are those two needed anymore since the CF links are already available?
Create a new commitfest entry - if we are creating the CFs
automatically, is this link that useful? And it could be a button/link
in the Commitfest section itself just before or after the table of
relevant commitfests.
--
Best Wishes,
Ashutosh Bapat
what's on the other
> end do we need a corresponding option to --include-foreign-data to be able to
> be selective with statistics?
We include only statistics and no data for regular tables. Shouldn't
we do the same to the foreign tables?
--
Best Wishes,
Ashutosh Bapat
; instead of adding it at
> the end?
>
> makes sense.
>
>
Attached patch removing extra comma. Otherwise LGTM.
Please add the patch to CF, if not already done and mark it as "ready for
committer".
--
Best Wishes,
Ashutosh Bapat
From dd240a151a5a17f2872d4df0a353e03c73f2daf2 Mo
(relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP there. Your
patch has covered all the existing ones.
--
Best Wishes,
Ashutosh Bapat
ll.
And the risk is minimal.
Do we want to add the section "Multixact Information Functions" after other
transaction related sections like "Transaction ID and Snapshot Information
Function" and " Committed Transaction Information Functions" instead of
adding it at the end?
--
Best Wishes,
Ashutosh Bapat
e or a PostgreSQL cluster from an
archive created by
pg_dump or pg_dumpall respectively.
[1] https://www.postgresql.org/docs/18/app-pgrestore.html
--
Best Wishes,
Ashutosh Bapat
resolving those misestimates would ideally improve the root issue,
> I'd like to keep the focus of this thread on adding the GUC parameter.
> Then, I plan to report or address the estimation problem in a separate
> thread.
>
>
+1.
--
Best Wishes,
Ashutosh Bapat
s involved in multixacts.
>
+1. Multixacts are highly under documented in user facing as well as
internal documentations. Thanks for the patch.
[1]
https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES
--
Best Wishes,
Ashutosh Bapat
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/f
ts will
> still run, but people would get a failing CI job which tells them that
> something is wrong. We could also include a pgindent in that CI job.
>
>
> +1. Knowing whether to use git am or patch to apply the patch itself will
save reviewers' time.
--
Best Wishes,
Ashutosh Bapat
d right after the resize ftruncate.
>
> I thought I had shared a test program upthread, but I don't find it now.
Attached here. Can you please share your test program?
There are concerns around portability of this approach, though.
--
Best Wishes,
Ashutosh Bapat
#define _GNU_SOURC
to document
how pg_multixact/members and pg_multixact/offset are used and what is their
layout. It's not the responsibility of this patchset to document it, but it
will be good if we add a section about multixacts in transam/README. It
will make reviews easier.
--
Best Wishes,
Ashutosh Bapat
On Thu, Apr 24, 2025 at 11:10 PM Tom Lane wrote:
>
> I think it's up to the user to rename subsidiary objects if
> they wish to do so.
>
I absolutely agree.
--
Best Wishes,
Ashutosh Bapat
R TABLE ... RENAME ... should rename the
sequence too since the identity sequences are created implicitly when the
table is created, so they should be renamed implicitly. We should not
require WITH SEQUENCE clause.
--
Best Wishes,
Ashutosh Bapat
mething to
the effect "partition key expression contains a whole-row reference which
in turn contains a generated column." But that might be too verbose.
--
Best Wishes,
Ashutosh Bapat
Thanks Jian for your review.
On Tue, Apr 22, 2025 at 12:32 PM jian he
wrote:
> On Tue, Apr 22, 2025 at 11:45 AM Ashutosh Bapat
> wrote:
> >
> > I have included your original tests, but ended up rewriting code. Please
> let me know what do you think.
> >
>
> +
On Tue, Apr 22, 2025 at 11:19 AM jian he
wrote:
> On Tue, Apr 22, 2025 at 11:45 AM Ashutosh Bapat
> wrote:
> >
> >
> > While looking at this I realised that a generated column may end up
> being part of the partition key if the partition key expression contains a
>
sions.
I have included your original tests, but ended up rewriting code. Please
let me know what do you think.
--
Best Wishes,
Ashutosh Bapat
From 2adb796b1fdfa5e72c7302e4ecaf7d69b105d0f3 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Mon, 21 Apr 2025 18:06:58 +0530
Subject: [PATCH] Tighten
Hi Dmitry,
On Mon, Apr 14, 2025 at 12:50 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Apr 14, 2025 at 10:40:28AM GMT, Ashutosh Bapat wrote:
> >
> > However, when we put back the patches to shrink buffers, we will evict
> > the extra buffers,
ssionState::end() EndCompressorGzip()
calls DeflateCompressorEnd() which also sets cs->private_data
explicitly. So should EndCompressorZstd().
--
Best Wishes,
Ashutosh Bapat
On Wed, Apr 16, 2025 at 12:19 AM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
> >> This is disastrous for assorted reasons. The ALTER ADD CONSTRAINT
> >> command might fail outright if we've loaded data for
On Wed, Apr 16, 2025 at 11:57 AM Andrey Borodin wrote:
>
>
>
> > On 16 Apr 2025, at 11:18, Ashutosh Bapat
> > wrote:
> >
> > Having only some of the nodes act as DCS
> > and others purely PostgreSQL nodes will reduce waste of resources.
>
> But typi
that had no real PGDATA, only participates in voting. But this is a
> solution to problem induced by built-in autofailover.
Users find it a waste of resources to deploy 3 big PostgreSQL
instances just for HA where 2 suffice even if they deploy 3
lightweight DCS instances. Having only some of the nodes act as DCS
and others purely PostgreSQL nodes will reduce waste of resources.
--
Best Wishes,
Ashutosh Bapat
n logical replication or FDW or both will
use this ensemble to manage its shared state. The same ensemble can be
shared across multiple distributed clusters if it has scaling
capabilities.
--
Best Wishes,
Ashutosh Bapat
ef_fkey
... snip
pg_restore: finished item 2625 TABLE DATA c21
I tried applying your patch on v17 to see whether it causes the FK
creation to wait, but the patch doesn't apply cleanly.
--
Best Wishes,
Ashutosh Bapat
On Mon, Apr 14, 2025 at 12:50 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Apr 14, 2025 at 10:40:28AM GMT, Ashutosh Bapat wrote:
> >
> > However, when we put back the patches to shrink buffers, we will evict
> > the extra buffers, and shri
his work for shrinking buffers? What
> > scheme do you have in mind?
>
> I didn't like this part originally, and after changes to support hugetlb
> I think it's worth it just to replace mremap with munmap/mmap. That way
> there will be no such question, e.g. if a segment is getting shrinked
> the unmapped area will again become a part of the reserved space.
>
I might have not noticed it, but are we putting two mappings one
reserved and one allocated in the same address space, so that when the
allocated mapping shrinks or expands, the reserved mapping continues
to prohibit any other mapping from appearing there? I looked at some
of the previous emails, but didn't find anything that describes how
the reserved mapped space is managed.
--
Best Wishes,
Ashutosh Bapat
d, whether MERGE should be considered a separate
operation as far as publication is concerned. This topic may have been
discussed either when MERGE was implemented or when operation filters
were implemented. Sorry for the noise in that case.
This isn't a detailed review.
--
Best Wishes,
Ashutosh Bapat
newest PostgreSQL
> > committer.
> >
> > Please join us in wishing Jacob much success and few reverts!
>
> Congratulations Jacob! Well deserved!
>
> Thanks
> Richard
>
>
--
Best Wishes,
Ashutosh Bapat
/* Resize the backing anon file. */
if(ftruncate(m->segment_fd, new_size) == -1)
...
/* Reclaim the space */
ptr = mmap(m->shmem, new_size, PROT_READ | PROT_WRITE,
mmap_flags | MAP_FIXED, m->segment_fd, 0);
How are we preventing something get mapped into the space after
m->shmem + newsize? We will need to add an unallocated but reserved
addressed space map after m->shmem+newsize right?
--
Best Wishes,
Ashutosh Bapat
On Wed, Apr 9, 2025 at 1:15 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Apr 09, 2025 at 11:12:18AM GMT, Ashutosh Bapat wrote:
> > On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > >
> > > In the new v4 v
| ^~~
In file included from ../../coderoot/pg/src/port/pg_numa.c:26:
../../coderoot/pg/src/include/storage/pg_shmem.h:127:13: note: declared here
127 | extern void GetHugePageSize(Size *hugepagesize, int *mmap_flags,
| ^~~
--
Best Wishes,
Ashutosh Bapat
relevant structures seems good enough, not a change that should bubble
up to the README. The only change in the EC interface is the addition
of a new iterator method - maybe we could document that in README but
that too seems more detail than what README is about.
--
Best Wishes,
Ashutosh Bapat
time of day, it doesn't make
> intuitive sense.
+1. I think the idea is too simple to be acceptable.
Any timezone based deadline might be seen as unfair to those for whom
that time falls in their respective nights. AoE removes that
unfairness.
--
Best Wishes,
Ashutosh Bapat
On Tue, Apr 8, 2025 at 10:49 AM Michael Paquier wrote:
>
> On Tue, Apr 08, 2025 at 08:47:53AM +0530, Ashutosh Bapat wrote:
> > Thanks for addressing the comment.
> >
> > In PG code, we start a multiline comment with just /* on the first
> > line and end with jus
eparate lines.
--
Best Wishes,
Ashutosh Bapat
On Tue, Apr 8, 2025 at 8:30 AM David Rowley wrote:
>
> On Tue, 8 Apr 2025 at 04:54, Ashutosh Bapat
> wrote:
> > - foreach(lc2, cur_ec->ec_members)
> > + setup_eclass_member_iterator(&it, cur_ec, rel);
> > + while ((cur_em = eclass_member_iterator_next(&it))
asses(EquivalenceClass *ec, int from, int to)
List *new_members = NIL;
List *new_sources = NIL;
+ /*
+ * We don't expect any EC child members to exist at this point. Ensure
+ * that's the case, otherwise we might be getting asked to do something
+ * this function hasn't been coded for.
+ */
+ Assert(ec->ec_childmembers == NULL);
+
Similar to above.
--
Best Wishes,
Ashutosh Bapat
tes, in case every character is a quote, b. two
bytes for two outer quotes c. extra byte for E' d. one byte for null
terminator. */
--
Best Wishes,
Ashutosh Bapat
On Fri, Feb 28, 2025 at 5:31 PM Ashutosh Bapat
wrote:
>
> I think we should add a way to monitor the progress of resizing; at
> least whether resizing is complete and whether the new GUC value is in
> effect.
>
I further tested this approach by tracing the barrier synchroniz
; the variable length edge?
>
> 3. What if the query doesn't specify the Label of edge, and there can
> be different edge labels of r, can we easily do the rewrite?
>
> I did some study of the apache age, they have fixed columns for node
> labels(id, agtype)
> and edge labels(id, source_id, end_id, agtype), agtype is kind of
> json. So they can
> resolve the above question easily.
>
> Above are just my random thoughts of the quantifier feature, I don't have a
> copy
> of the PGQ standard, so I'd like to hear your opinion about this.
>
I think the questions you have raised are valid. If we decide to
discuss this in a separate thread, I will start that thread just by
responding to these questions and design I have in mind.
--
Best Wishes,
Ashutosh Bapat
On Fri, Mar 28, 2025 at 12:01 PM Ashutosh Bapat
wrote:
>
> Comparing root->join_rel_hash with EC->ec_derives_hash in the context
> of initial hash table size is a thinko on my part. It's less likely
> that there will be 1000 subqueries (requiring 1000 PlannerInfos) each
&
he size of
ec_derives_list when creating the hash table and we are using
simplehash which uses its own fillfactor and its own logic to expand
the hash table, I think we should just use the length of
ec_derives_list as the initial size. What do you think?
--
Best Wishes,
Ashutosh Bapat
nt in the same block.
--
Best Wishes,
Ashutosh Bapat
From c0305c8572c9c416da45b9a14146be049cf91102 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Thu, 3 Apr 2025 17:29:49 +0530
Subject: [PATCH 1/2] Test detaching a partition with foreign key constraint
A partition of a partitioned table with a fo
On Mon, Mar 24, 2025 at 5:44 PM Alvaro Herrera wrote:
>
> On 2025-Mar-24, Ashutosh Bapat wrote:
>
> > One concern I have with directory format is the dumped database is not
> > readable. This might make investigating a but identified the test a
> > bit more complex
e generation
is not accurate, since we lookup EM = constant clauses as well which
are not join clauses.
2. In the second paragraph em1 and em2 are mentioned without
mentioning what are they. I have rephrased it so as to avoid
mentioning names of structure member.
--
Best Wishes,
ing all formats when running test as opt-in. Alvaro and Vignesh
are for just one format. We need a tie-breaker or someone amongst us
needs to change their vote :D.
--
Best Wishes,
Ashutosh Bapat
m_bounds',
'{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100}'::text,
+ 'correlation', '1'::real
+);
First 3 and 5th differences are new differences but we have seen
something similar to the 4th one previously.
I am not able to reproduce the failure even after running it 30 times
on my linux laptop.
[1]
https://www.postgresql.org/message-id/caexhw5vvftcejh+uyznxmgsxofj_1xwi5aqhqfemqjgfmky...@mail.gmail.com
[2] https://cirrus-ci.com/task/5164175841820672
--
Best Wishes,
Ashutosh Bapat
On Fri, Apr 4, 2025 at 5:23 PM Álvaro Herrera wrote:
>
> On 2025-Apr-04, Ashutosh Bapat wrote:
>
> > connection error: 'psql: error: connection to server on socket
> > "/tmp/LiPa_UJpSb/.s.PGSQL.13779" failed: FATAL: database "regression"
> > do
1 - 100 of 1308 matches
Mail list logo
