uld that introduce an inconsistency between r1 and r2?
--
Best Wishes,
Ashutosh Bapat
On Thu, Jun 6, 2024 at 9:22 AM Amit Kapila wrote:
> On Wed, Jun 5, 2024 at 6:01 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila
> wrote:
> >>
> >> How about periodically sending this information?
> >> >
> &g
On Wed, Jun 5, 2024 at 1:17 PM Ashutosh Bapat
wrote:
> Hi David,
> Thanks for looking into this.
>
> On Fri, May 31, 2024 at 2:19 AM David Christensen
> wrote:
>
>> Hello,
>>
>> I am looking through some outstanding CommitFest entries; I wonder if
>> th
On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
> On Tue, Jun 4, 2024 at 7:40 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jun 4, 2024 at 4:27 PM Amit Kapila
> wrote:
> >>
> >>
> >> 3. Replicate published sequences via walsender at the time
On Tue, Jun 4, 2024 at 4:28 AM Michael Paquier wrote:
> On Fri, Apr 26, 2024 at 06:38:22PM +0530, Ashutosh Bapat wrote:
> > Some points for discussion:
> > 1. The test still hardcodes the diffs between two dumps. Haven't found a
> > better way to do it. I did consider rem
On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin wrote:
> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote:
> > "Tristan Partin" writes:
> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote:
> > >> We talked this off-list at the conference.
tatistics and this bug I
am fixing. Can you please elaborate?
> 3. I dislike, that this patch makes much harder to debug, why no
> partitionwise join is chosen.
>
Can you please elaborate more? How does my change make debugging harder?
--
Best Wishes,
Ashutosh Bapat
sql.org/message-id/CAExHW5snUW7pD2RdtaBa1T_TqJYaY6W_YPVjWDrgSf33i-0uqA%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
setup.sql
Description: application/sql
queries.sql
Description: application/sql
From 4a37f580806a388e5d78e452426b99f738a583e5 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date
utdown of the node.
>
> Any other ideas?
>
>
In case of primary crash the sequence won't get replicated. That is true
even with the previous approach in case walsender is shut down because of a
crash, but it is more serious with this approach. How about periodically
sending this information?
--
Best Wishes,
Ashutosh Bapat
pg_regress --schedule argument and instead pass the list of
tests. Any idea how to do that?
--
Best Wishes,
Ashutosh Bapat
On Mon, Feb 19, 2024 at 5:17 AM Ashutosh Bapat
wrote:
> On Mon, Feb 19, 2024 at 4:35 AM Tomas Vondra
> wrote:
> >
> > Hi,
> >
> > After taking a look at the patch optimizing SpecialJoinInfo allocations,
> > I decided to take a quick look at this one too. I
I right?
Plans with lower costs being slower is not new for optimizer.
Partitionwise join just adds another case.
>
> Maybe we can discuss that in person next week?
>
Sure.
>
> On 2024-05-22 07:57, Ashutosh Bapat wrote:
> >
> > The test was added by 6b94e7a6da2f1c6df
tempted to introduce a missing_ok to this routine after looking at the
> callers in all the tree, as some of them want to fail still would not
> expect it, so that would reduce a bit the elog churn. That's a story
> for a different day, though.
> --
> Michael
>
--
Best Wishes,
Ashutosh Bapat
On Fri, May 24, 2024 at 12:16 PM Michael Paquier
wrote:
> On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> > If we are looking for avoiding a segfault and get a message which helps
> > debugging, using get_attname and get_attnum might be better options.
> &g
nction. There was some
discussion about setting a search path for a function at [1]. But the last
message there is non-conclusive. We may want to extend it to extensions
such that all the object references in a given extension are resolved using
extension specific search_path.
[1]
https://www.postgresql.org/message-id/2710f56add351a1ed553efb677408e51b060e67c.camel%40j-davis.com
--
Best Wishes,
Ashutosh Bapat
rns
InvalidAttnum which won't return any valid identity sequence, and thus
return a NIL sequence list which is handled in that function already. Using
these two functions will avoid the clutter as well as segfault. If that's
acceptable, I will provide a patch.
--
Best Wishes,
Ashutosh Bapat
se+OJ", but I cannot find the
> explanation of "OJ" or the "OJ" Acronyms.
>
>
> OJ is an outer join, AFAIU. OJ's have their own relids. If you are
wondering why not all joins - I think inner joins need not be tracked as
separated relations in parse tree, but OJ's need to be.
--
Best Wishes,
Ashutosh Bapat
relation_open() with new relid, in order to use rel in the
error message. I don't think all that is worth it, unless we find a
scenario when SearchSysCacheAttName() returns NULL.
--
Best Wishes,
Ashutosh Bapat
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
> > >>
1 - 100 of 944 matches
Mail list logo