On Mon, May 6, 2024 at 6:28 PM Ashutosh Bapat
wrote:
>
>
> On Mon, May 6, 2024 at 4:26 PM Jakub Wartak
> wrote:
>
>> Hi Ashutosh & hackers,
>>
>> On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
>> wrote:
>> >
>> > Here's patch wi
Thanks a lot Peter.
On Wed, May 8, 2024 at 2:34 AM Peter Eisentraut
wrote:
> On 30.04.24 12:59, Ashutosh Bapat wrote:
> > PFA patch which fixes all the three problems.
>
> I have committed this patch. Thanks all.
>
--
Best Wishes,
Ashutosh Bapat
On Tue, May 7, 2024 at 12:00 AM Christophe Pettus wrote:
> Thank you for the reply!
>
> > On May 1, 2024, at 02:18, Ashutosh Bapat
> wrote:
> > Is there a large transaction which is failing to be replicated
> repeatedly - timeouts, crashes on upstream or downstream?
>
On Sun, May 5, 2024 at 1:43 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Apr 30, 2024 at 04:29:11PM +0530, Ashutosh Bapat wrote:
> > On Sun, Apr 28, 2024 at 12:29 PM Alexander Lakhin
> > wrote:
> >
> > > 27.04.2024 18:00, Alexander Lakhin
On Mon, May 6, 2024 at 4:26 PM Jakub Wartak
wrote:
> Hi Ashutosh & hackers,
>
> On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
> wrote:
> >
> > Here's patch with
> >
> [..]
> > Adding to the next commitfest but better to consider this for the next
>
e, but I can't do it now because I
> > won't be around for the next few hours in case the buildfarm blows up.
> > I can do it tomorrow, or perhaps Peter would like to handle it since
> > it seems to have been his commit that introduced the issue.
>
> I have committed it now.
>
>
Thanks Peter.
--
Best Wishes,
Ashutosh Bapat
greSQL (v11), so an
> upgrade may fix it, but at the moment, I'm trying to find a cause and a
> mitigation.
>
>
Is there a large transaction which is failing to be replicated repeatedly -
timeouts, crashes on upstream or downstream?
--
Best Wishes,
Ashutosh Bapat
I have examined all the callers of getIdentitySequence() and they seem to
be fine. The code related to SetIdentity, DropIdentity is not called for
partitions, errors for which are thrown elsewhere earlier.
--
Best Wishes,
Ashutosh Bapat
From bce2e8d573040901b18c0c9f6884f0fd44f50724 Mon Sep 17 00:00:00 2
On Mon, Apr 29, 2024 at 6:46 PM Robert Haas wrote:
> On Sat, Apr 20, 2024 at 12:17 AM Ashutosh Bapat
> wrote:
> > Yes please. Probably this issue surfaced again after we reverted
> compression and storage fix? Please If that's the case, please add it to
> the open items.
from core dump is useful. if you can
reproduce the crash, running reproduction with gdb attached to a process
intended to crash is more useful.
--
Best Wishes,
Ashutosh Bapat
Please join us in wishing them much success and few reverts!
>
> Thanks,
>
> Jonathan
>
--
Best Wishes,
Ashutosh Bapat
On Fri, Feb 23, 2024 at 10:46 AM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
> On Thu, Feb 22, 2024 at 8:35 PM Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> > > The problem is, we don't really have any end-to-end coverage of
> >
>
Thanks Alexander for the report.
On Fri, Apr 26, 2024 at 5:30 PM Alexander Lakhin
wrote:
> Hello Ashutosh and Peter,
>
> 16.01.2024 21:59, Peter Eisentraut wrote:
> > On 09.01.24 15:10, Ashutosh Bapat wrote:
> >> Here's complete patch-set.
> >
> > Looks g
the function is a noop when mergeclause_list is empty. I haven't looked
closely to see if creating unique path nonetheless is useful somewhere
else. Please add to the next commitfest. If the patch shows some measurable
performance improvement, it would become more attractive.
--
Best Wishes,
Ashutosh Bapat
On Sat, Apr 20, 2024 at 9:30 AM Alexander Lakhin
wrote:
> Hello,
>
> 30.01.2024 09:22, Ashutosh Bapat wrote:
> >
> >> Please look at the segmentation fault triggered by the following query
> since
> >> 4d969b2f8:
> >> CREATE TABLE t1(a text C
ate hash table in TopMemoryContext?
--
Best Wishes,
Ashutosh Bapat
Here's patch with
On Thu, Apr 11, 2024 at 12:24 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
>
>
> On Thu, Apr 11, 2024 at 12:07 PM Ashutosh Bapat <
> ashutosh.bapat@gmail.com> wrote:
>
>> Hi All,
>> Per below code and comment in apply_scan
On Thu, Apr 11, 2024 at 12:07 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
> Hi All,
> Per below code and comment in apply_scanjoin_target_to_paths(), the
> function zaps all the paths of a partitioned relation.
> /*
> * If the rel is partitioned, we want to dr
ied a few variations but without success. Suggestions welcome.
The problem is reproducible on PG 15. The patch is based on 15_STABLE
branch. But the problem exists in recent branches as well.
--
Best Wishes,
Ashutosh Bapat
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/p
On Fri, Apr 5, 2024 at 10:07 AM Tom Lane wrote:
> Ashutosh Bapat writes:
> > I read that discussion, and it may be ok for pg_upgrade/pg_dump usecase
> and
> > maybe also for IMPORT foreign schema where the SQL is generated by
> > PostgreSQL itself. But not f
s that are generated
subsequently. Thus negating the very purpose of simulating statistics. Once
the feature is out there, we won't be able to restrict its usage unless we
document the possible anomalies.
--
Best Wishes,
Ashutosh Bapat
as well. Please incorporate
it in your next patchset.
--
Best Wishes,
Ashutosh Bapat
commit 353a4077d07cf097c5cb90c732b7dde2f16f04a6
Author: Ashutosh Bapat
Date: Mon Apr 1 13:04:40 2024 +0530
Review changes
Ashutosh Bapat
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml
Hi Corey,
On Mon, Mar 25, 2024 at 3:38 PM Ashutosh Bapat
wrote:
> Hi Corey,
>
>
> On Sat, Mar 23, 2024 at 7:21 AM Corey Huinker
> wrote:
>
>> v12 attached.
>>
>> 0001 -
>>
>>
> Some random comments
>
> +SELEC
On Thu, Mar 28, 2024 at 11:22 PM Alvaro Herrera
wrote:
> On 2024-Mar-28, Ashutosh Bapat wrote:
>
> > LGTM.
> >
> > The commitfest entry is marked as RFC already.
> >
> > Thanks for taking care of the comments.
>
> Thanks for reviewing. I notic
LGTM.
The commitfest entry is marked as RFC already.
Thanks for taking care of the comments.
--
Best Wishes,
Ashutosh Bapat
On Thu, Mar 28, 2024 at 5:54 AM Robert Treat wrote:
> On Mon, Mar 25, 2024 at 6:43 AM Ashutosh Bapat
> wrote:
> > On Fri, Mar 22, 2024 at 10:58 PM Robert
ses with
partition keys (always), we need to teach EC to contain partition keys in
case of outer joins. Tom alluded to this but I haven't seen any proposal.
The potential danger with the current patch is that it will continue to
have two loops even if we fix one of the above cases in future.
--
Best Wishes,
Ashutosh Bapat
omment of init_dummy_sjinfo() mentions the non-existing 'rel1' and
> > 'rel2', which should be addressed.
>
> Thanks for catching that. Oops.
>
Good catch.
>
> > Also, I think we can make function
> > consider_new_or_clause() call init_dummy_sjinfo() to simplify the code a
> > bit.
>
> Indeed.
>
Thanks for fixing it.
--
Best Wishes,
Ashutosh Bapat
ther replacing "will" by "must" is correct. Usually I have
seen "will" being used in such sentences, "must" seems appropriate given
the necessity.
--
Best Wishes,
Ashutosh Bapat
at.
>
>
Ok. Thanks for separating the changes.
--
Best Wishes,
Ashutosh Bapat
ignSchema() will need to add SELECT commands invoking
pg_set_relation_stats() on each imported table and pg_set_attribute_stats()
on each of its attribute. Am I right? Do we want to make that happen in the
first cut of the feature? How do you expect these functions to be used to
update statistics of foreign tables?
--
Best Wishes,
Ashutosh Bapat
for updating the comment. I wish we would have
freeObject(). Nothing that can be done for this patch.
Attached patches
Squashed your 0001 and 0002 into 0001. I have also reworded the commit
message to reflect the latest code changes.
0002 has some minor edits. Please feel free to include or reject w
On Wed, Mar 20, 2024 at 5:22 PM Ashutosh Bapat
wrote:
>
>
> On Tue, Mar 19, 2024 at 6:38 PM Robert Treat wrote:
>
>>
>> I've put it in the next commitfest with target version of 17, and I've
>> added you as a reviewer :-)
>>
>>
> Thanks.
>
&
On Thu, Mar 21, 2024 at 3:19 PM Peter Eisentraut
wrote:
> On 07.03.24 17:54, Ashutosh Bapat wrote:
> > The pg_dump problems arise because we throw an error when parents have
> > conflicting compression and storage properties. The patch that got
> > reverted, changed this
ably
it is better to leave original sentence as is.
But I think it's time for a committer to take a look at this. Please feel
free to address the above comments if you agree with them. Marking this as
ready for committer.
--
Best Wishes,
Ashutosh Bapat
On Tue, Mar 19, 2024 at 8:18 AM Richard Guo wrote:
> (Sorry it takes me some time to get back to this thread.)
>
> On Thu, Mar 7, 2024 at 7:13 PM Ashutosh Bapat <
> ashutosh.bapat@gmail.com> wrote:
>
>> I did a deeper review of the patch. Here are som
Hi Robert,
On Mon, Mar 18, 2024 at 10:52 PM Robert Treat wrote:
> On Thu, Mar 14, 2024 at 12:15 PM Ashutosh Bapat
> wrote:
> >
> > Hi Robert,
> >
> > On Thu, Mar 7, 2024 at 10:49 PM Robert Treat wrote:
> >>
> >> This patch adds a link to the
the same value because of rounding. The actual values
there are 27740432 and 26854704 resp.
Please let me know if you need anything.
--
Best Wishes,
Ashutosh Bapat
On Mon, Mar 18, 2024 at 5:05 PM Amit Langote
wrote:
> On Mon, Mar 18, 2024 at 20:11 Ashutosh Bapat
> wrote:
>
>> Hi Amit,
>>
>>
>> On Fri, Mar 15, 2024 at 11:45 AM Amit Langote
>> wrote:
>>
>>> > >
>>> > > That bein
3 MB
4 | 307 MB | 263 MB
5 | 1076 MB | 843 MB
The numbers look slightly different from my earlier numbers. But they were
quite old. The patch used to measure memory that time is different from the
one that we committed. So there's a slight difference in the way we measure
memory as we
On Thu, Mar 14, 2024 at 3:45 PM David Rowley wrote:
> On Thu, 14 Mar 2024 at 18:23, Ashutosh Bapat
> wrote:
> > I don't understand why root->query_pathkeys has both a and b. "a" is
> there because of GROUP BY and ORDER BY clause. But why "b"?
>
>
uot;indexes on partition" is clearer than "partition index". Fixed in the
attached patch.
Please review.
--
Best Wishes,
Ashutosh Bapat
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 8616a8e9cc..043717136c 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@
ike root->query_pathkeys
containing "b" may be a problem.
When it's called for upper relation, the reltarget has "a" and Aggref() and
it includes only "a" in the useful pathkeys which is as per your
expectation.
--
Best Wishes,
Ashutosh Bapat
On Fri, Mar 8, 2024 at 7:43 AM David Rowley wrote:
> On Fri, 8 Mar 2024 at 00:54, Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 7, 2024 at 4:39 PM David Rowley
> wrote:
> >> I think the fix should go in appendOrderByClause(). It's at that
> >>
. This will solve all the pg_dump
bugs we saw with the reverted patch and also existing bug I reported
earlier.
This change would break backward compatibility but I don't think anybody
would rely on error being thrown when parent properties conflict.
What do you think?
--
Best Wishes,
Ashutosh Bapat
in the ORDER BY clause.
>
deparseSortGroupClause() calls deparseConst() with showtype = 1.
appendOrderByClause() may want to do something similar for consistency. Or
remove it from deparseSortGroupClause() as well?
>
> Something like the attached patch I think should work.
>
> I wonder if we need a test...
>
Yes.
--
Best Wishes,
Ashutosh Bapat
On Thu, Feb 22, 2024 at 2:56 PM Ashutosh Bapat
wrote:
> On Wed, Feb 21, 2024 at 4:55 PM Richard Guo
> wrote:
> >
> >
> > On Tue, Aug 2, 2022 at 4:24 AM Jacob Champion
> wrote:
> >>
> >> Once you think you've built up some community support and the p
%2BLpN%3DyhU%2BP33D%2B%3D7x6fhzwDwNRM971UJunRTkQ%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
son
> * Dean Rasheed
> * John Naylor
> * Melanie Plageman
> * Nathan Bossart
>
Hearty congratulations. Well deserved.
--
Best Wishes,
Ashutosh Bapat
On Fri, Feb 23, 2024 at 6:05 PM Ashutosh Bapat
wrote:
>
> On Tue, Feb 20, 2024 at 3:51 PM Peter Eisentraut wrote:
> >
> > I have reverted the patch for now (and re-opened the commitfest entry).
> > We should continue to work on this and see if we can at least try to
ht be better to just create two marcos (with names like
CHECK_FOR_INTERRUPTS() and CHECK_FOR_INTERRUPTS_SAFE()) to call
ProcessInterrupt() directly and modify ProcessInterrupts() to accept
the flag (and if required call CFIFlagHandler() additionally). Last
macro is hard to understand.
--
Best Wishes,
Ashutosh Bapat
; )
>
> We would have to duplicate the current CFI body, but it should never really
> change, and we shouldn't end up with more than 2 overloads anyway so I don't
> see it being much of a problem.
Why do we need this complex macro?
--
Best Wishes,
Ashutosh Bapat
on takes place there, it makes
sense to align with that. For example, all the view security stuff
(privileges, security barriers, etc.) will eventually need to be
considered, and it would make sense to do that in a consistent way.
--- unquote
--
Best Wishes,
Ashutosh Bapat
uot;
and store that instead of NULL in attcompression column. That looks
ugly.
Similar is the case with storage.
[1]
https://www.postgresql.org/message-id/CAExHW5uF5V=Cjecx3_Z=7xfh4rg2wf61pt+hfquzjbqourz...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
with a few other bugs in that area which I will
report soon on that thread. I think, that shows that we need such a
test.
--
Best Wishes,
Ashutosh Bapat
On Thu, Feb 22, 2024 at 3:50 PM Peter Eisentraut wrote:
>
> On 22.02.24 11:00, Daniel Gustafsson wrote:
> >> On 22 Feb 2024, at 10:55, Ashutosh Bapat
> >> wrote:
> >> On Thu, Feb 22, 2024 at 3:03 PM Daniel Gustafsson wrote:
> >
> >> Somebod
ion, we could perhaps also use this to test a
> scenario like: Dump A, restore into B, upgrade B into C, dump C and compare C
> to A.
If comparison of C to A fails, we wouldn't know which step fails. I
would rather compare outputs of each step separately.
--
Best Wishes,
Ashutosh Bapat
r table - when would somebody do
that?). Is there some real life example of this?
The patch uses restrictclauses as well as EC's. Tom has proposed to
make EC work with outer joins sensibly. Has that happened? Can this
patch leverage it rather than having two loops?
--
Best Wishes,
Ashutosh Bapat
On Thu, Feb 22, 2024 at 6:32 AM Michael Paquier wrote:
>
> On Wed, Feb 21, 2024 at 12:18:45PM +0530, Ashutosh Bapat wrote:
> > Even with 1 and 2 the test is useful to detect dump/restore anomalies.
> > I think we should improve 3, but I don't have a good and simpler
> >
ating EXPLAIN
output may not be noticeable in a long running query. The EXPLAIN
output could be saved in pg_stat_activity or similar place. This will
avoid signaling the backend.
--
Best Wishes,
Ashutosh Bapat
it will be a lot of work. Not sure if
it's worth it.
Suggestions welcome.
[1]
https://www.postgresql.org/message-id/CAExHW5vyqv%3DXLTcNMzCNccOrHiun_XhYPjcRqeV6dLvZSamriQ%40mail.gmail.com
[2] https://www.postgresql.org/message-id/3462358.1708107856%40sss.pgh.pa.us
--
Best Wishes,
Ashutosh Bapat
From
On Tue, Feb 20, 2024 at 8:19 AM Andrei Lepikhov
wrote:
>
> On 19/2/2024 19:25, Ashutosh Bapat wrote:
> > On Fri, Feb 16, 2024 at 8:42 AM Andrei Lepikhov
> > wrote:
> >> Live example: right now, I am working on the code like MSSQL has - a
> >> combin
On Mon, Feb 19, 2024 at 8:30 PM Alexander Lakhin wrote:
>
> Hello Ashutosh,
>
> 19.02.2024 15:17, Ashutosh Bapat wrote:
> >
> >> Functions ATExecAddIdentity() and ATExecDropIdentity() are recursive too,
> >> so I think they can be exploited as well.
>
riation in planning
time was with the usual planning time variations.
[1]
https://www.postgresql.org/message-id/flat/CAExHW5uVZ3E5RT9cXHaxQ_DEK7tasaMN%3DD6rPHcao5gcXanY5w%40mail.gmail.com#112b3e104e0f9e39eb007abe075aae20
--
Best Wishes,
Ashutosh Bapat
riteTable stage.
>
I am surprised that this requires changes in ReWrite. I thought adding
NOT NULL constraint and default value commands would be done by
transformColumnDefinition(). But I haven't looked at the patch close
enough.
--
Best Wishes,
Ashutosh Bapat
explains why we see some modest speedups because of my
memory saving patches. Thanks for sharing it.
[1]
https://www.postgresql.org/message-id/caexhw5stmouobe55pmt83r8uxvfcph+pvo5dnpdrvcsbgxe...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAExHW5t0cPNjJRPRtt%3D%2Bc5SiTeBPHvx%3DSd2n8EO%2B7XdVuE8_YQ%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
uristic but it won't work if partition properties - statistics,
indexes etc. differ between groups of partitions.
--
Best Wishes,
Ashutosh Bapat
On Thu, Feb 15, 2024 at 11:30 PM Alexander Lakhin wrote:
>
> Hello Ashutosh,
>
> 24.01.2024 09:34, Ashutosh Bapat wrote:
> >
> >>> There's another thing I found. The file isn't using
> >>> check_stack_depth() in the function which traverse inheritance
&g
te query: ERROR: relation
"public.chld" does not exist
Command was: COPY public.chld (a) FROM stdin;
pg_restore: warning: errors ignored on restore: 3
Fixing this requires that we dump ALTER TABLE ... ALTER COLUMN SET
STORAGE and COMPRESSION commands after all the tables (at least
children) have been created. That seems to break the way we dump the
whole table together right now. OR dump inherited tables like binary
upgrade mode.
--
Best Wishes,
Ashutosh Bapat
On Thu, Feb 15, 2024 at 9:41 AM Andrei Lepikhov
wrote:
>
> On 6/2/2024 19:51, Ashutosh Bapat wrote:
> > On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
> > The patches are raw. make check has some crashes that I need to fix. I
> > am waiting to hear whether this is usefu
On Wed, Feb 14, 2024 at 9:50 AM Andrei Lepikhov
wrote:
>
> On 30/1/2024 12:44, Ashutosh Bapat wrote:
> > Thanks Vignesh. PFA patches rebased on the latest HEAD. The patch
> > addressing Amit's comments is still a separate patch for him to
> > review.
> Thanks fo
On Mon, Feb 12, 2024 at 6:52 AM Ashutosh Bapat
wrote:
>
> >
> > > We defer actual action triggered by a signal till CHECK_FOR_INTERRUPTS
> > > is called. I understand that we can't do that here since we want to
> > > capture the backtrace at that
On Mon, Feb 12, 2024 at 8:48 PM Peter Eisentraut wrote:
>
> On 08.02.24 08:20, Ashutosh Bapat wrote:
> > On Wed, Feb 7, 2024 at 12:47 PM Ashutosh Bapat
> > wrote:
> >
> >> 0001 fixes compression inheritance
> >> 0002 fixes storage inheritance
&g
/sql-altertable.html
[2] https://www.postgresql.org/docs/16/sql-createtable.html
[3] https://www.postgresql.org/docs/16/datatype.html
--
Best Wishes,
Ashutosh Bapat
On Mon, Feb 12, 2024 at 5:31 AM jian he wrote:
>
> On Wed, Feb 7, 2024 at 12:58 PM Ashutosh Bapat
> wrote:
> >
> > >
> > > > */
> > > > How bad this performance could be. Let's assume that a query is taking
> > > >
other session (PID) executes `SELECT pg_log_query_plan(48602);` in
> the meantime.
> pg_log_query_plan returns true successfully, but PID 48602 was stuck.
What do you mean by PID 48602 was stuck?
--
Best Wishes,
Ashutosh Bapat
On Sat, Feb 10, 2024 at 5:36 AM Michael Paquier wrote:
>
> On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote:
> > On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera
> > wrote:
> >> Hmm, but the backtrace() manpage says
> >>
> >>•
efer actual action triggered by a signal till CHECK_FOR_INTERRUPTS
is called. I understand that we can't do that here since we want to
capture the backtrace at that moment and can't wait till next CFI. But
printing the backend can surely wait till next CFI right?
--
Best Wishes,
Ashutosh Bapat
e row.
NOTHING
Records no information about the old row. This is equivalent to having
no replica identity. This is the default for system tables.
--
Best Wishes,
Ashutosh Bapat
On Wed, Feb 7, 2024 at 12:47 PM Ashutosh Bapat
wrote:
> 0001 fixes compression inheritance
> 0002 fixes storage inheritance
>
The first patch does not update compression_1.out which makes CI
unhappy. Here's patchset fixing that.
--
Best Wishes,
Ashutosh B
hem while committing.
0001 - same as your patch
0002 - additional tests
--
Best Wishes,
Ashutosh Bapat
From c142bfc5ec8b3c9c5a01f48693118d132145b45b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 5 Feb 2024 11:22:01 +0100
Subject: [PATCH 1/2] Fix propagation of persistenc
On Wed, Feb 7, 2024 at 3:43 PM Alvaro Herrera wrote:
>
> Many thanks, Justin, for the post-commit review.
>
> On 2024-Feb-06, Ashutosh Bapat wrote:
>
> > On Tue, Feb 6, 2024 at 3:51 AM Justin Pryzby wrote:
> > >
> > > Up to now, the expla
On Wed, Jan 31, 2024 at 1:29 PM Ashutosh Bapat
wrote:
>
> On Tue, Dec 5, 2023 at 6:28 PM Peter Eisentraut wrote:
> >
> > On 05.12.23 05:26, Ashutosh Bapat wrote:
> > >> - When inheriting from multiple parents with different settings, an
> > >>
On Wed, Feb 7, 2024 at 9:38 AM torikoshia wrote:
>
> Hi Ashutosh,
>
> On 2024-02-06 19:51, Ashutosh Bapat wrote:
>
> > Thanks for the summary. It is helpful. I think patch is also getting
> > better.
> >
> > I have a few questions and suggestions
>
>
On Mon, Nov 6, 2023 at 2:48 PM Ashutosh Bapat
wrote:
>
> explain.out in 0001 needed some adjustments. Without those CIbot shows
> failures. Fixed in the attached patchset. 0001 is just for diagnosis,
> not for actual commit. 0002 which is the actual patch has no changes
> wrt
On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
wrote:
> >
> > That looks pretty small considering the benefits. What do you think?
> >
> > [1]
> > https://www.postgresql.org/message-id/caexhw5stmouobe55pmt83r8uxvfcph+pvo5dnpdrvcsbgxe...@mail.gmail.com
>
> I
examine the server log file to see if the plan is indeed output to the
server log file.
Given that the feature will be used when the things have already gone
wrong, it should not make things more serious. So more testing and
especially automated would help.
--
Best Wishes,
Ashutosh Bapat
ort memory less
than 1kB in which case bytes is a better unit. Planner may consume as
less as few kBs of memory, reporting which in kBs would be lossy.
> (Also, I first thought that "peek" should be "peak", but eventually I
> realized that's it's as intended.)
>
Don't understand the context. But probably it doesn't matter.
--
Best Wishes,
Ashutosh Bapat
On Tue, Dec 5, 2023 at 6:28 PM Peter Eisentraut wrote:
>
> On 05.12.23 05:26, Ashutosh Bapat wrote:
> >> - When inheriting from multiple parents with different settings, an
> >> explicit setting in the child is required.
> > When no explicit setting for chi
ts with and without the patch are
close.
Just to be clear, the change is for good and should be committed to
the master. It's the backpatching I am worried about.
--
Best Wishes,
Ashutosh Bapat
(#define STD_FUZZ_FACTOR 1.01) but
slight variation in all the GUCs that affect cost, might bring the
difference closer to STD_FUZZ_FACTOR.
Given how close they are, maybe it's not such a good idea to
backpatch. If the plans change for better, users won't complain but
otherwise they will complain and will have no way to go back to their
good plans in production.
--
Best Wishes,
Ashutosh Bapat
On Wed, Jan 31, 2024 at 2:16 AM Jeff Davis wrote:
>
> On Tue, 2024-01-30 at 16:17 +0530, Ashutosh Bapat wrote:
> > Converting a server and user mapping to
> > conninfo should be delegated to the FDW being used since that FDW
> > knows best how to use those options.
On Wed, Jan 24, 2024 at 7:15 AM Jeff Davis wrote:
>
> On Tue, 2024-01-23 at 15:21 +0530, Ashutosh Bapat wrote:
> > I am with the prefix. The changes it causes make review difficult. If
> > you can separate those changes into a patch that will help.
>
> I ended up just remo
be good since this code is quite
old.
--
Best Wishes,
Ashutosh Bapat
s.ru/svace-website/en/
>
Can you please add a test case showcasing the bug? I see dttoasc()
uses strcpy(). So there's already a precedence.
--
Best Wishes,
Ashutosh Bapat
t; I also added a trivial test for EXPLAIN EXECUTE, which was uncovered,
> and some other minor stylistic changes.
>
Thanks. Looks fine to me.
> And with that I pushed it.
Thanks a lot.
--
Best Wishes,
Ashutosh Bapat
t;CREATE TABLE t3()
> INHERITS(t1, t2);") at tablecmds.c:885
This bug existed even before the refactoring.Happens because strcmp()
is called on NULL input (t2's compression is NULL). I already have a
fix for this and will be posting it in [1].
[1]
https://www.postgresql.org/message-id/flat/24656cec-d6ef-4d15-8b5b-e8dfc9c833a7%40eisentraut.org
--
Best Wishes,
Ashutosh Bapat
On Sat, Jan 27, 2024 at 8:26 AM vignesh C wrote:
>
> On Tue, 31 Oct 2023 at 10:48, Ashutosh Bapat
> wrote:
> >
> > On Thu, Sep 14, 2023 at 4:39 PM Ashutosh Bapat
> > wrote:
> > >
> > > The patch set is thus
> > > 0001 - patch used to measur
On Fri, Jan 26, 2024 at 8:42 PM vignesh C wrote:
>
> On Wed, 4 Oct 2023 at 04:02, Ashutosh Bapat
> wrote:
> >
> > On Fri, Sep 29, 2023 at 8:36 AM Amit Langote
> > wrote:
> > > IOW, something
> > > like the following would have sufficed:
On Wed, Jan 24, 2024 at 12:04 PM Ashutosh Bapat
wrote:
> >
> > Ok. Maybe just rephrase that comment somehow then?
>
> Please see refactoring patches attached to [1]. Refactoring that way
> makes it unnecessary to mention "regular inheritance" in each comment.
&
On Tue, Jan 23, 2024 at 12:29 AM Peter Eisentraut wrote:
>
> On 22.01.24 13:23, Ashutosh Bapat wrote:
> >> if (newdef->identity)
> >> {
> >> Assert(!is_partioning);
> >> /*
> >>*
1 - 100 of 926 matches
Mail list logo
