pgrading to the same version, 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
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
I wrote reproduces the COMPRESSION/STORAGE
bug you reported along 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
"
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
long as the view expansion 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
S__) \
> )
>
> 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
proach.
It might 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
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
son
> * Dean Rasheed
> * John Naylor
> * Melanie Plageman
> * Nathan Bossart
>
Hearty congratulations. Well deserved.
--
Best Wishes,
Ashutosh Bapat
W5tEvzM%3D%2BLpN%3DyhU%2BP33D%2B%3D7x6fhzwDwNRM971UJunRTkQ%40mail.gmail.com
--
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
n position 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
plicitly would override always. 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
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
> >> poi
x27;s the problem of the relation used. It looks like 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
umented range.
The patch uses both months and days together to avoid this problem.
Please feel free to complete the patch, work on review comments etc. I
will help as and when I find time.
--
Best Wishes,
Ashutosh Bapat
From 09a8fef224a3682059fe1adf42957f693a41d242 Mon Sep 17 00:00:00 2001
From:
publisher cannot be stopped if large delay-time is
> specified.
I think the current behaviour is an artifact of using the same WAL
sender code for both logical and physical replication.
I agree with you that the logical WAL sender need not wait for all the
WAL to be replayed downstream.
I have not reviewed the patch though.
--
Best Wishes,
Ashutosh Bapat
Hi All,
A customer ran a script dropping a few dozens of users in a transaction.
Before dropping a user they change the ownership of the tables owned by
that user to another user and revoking all the accesses from that user in
the same transaction. There were a few thousand tables whose privileges
the timeout threashold to decode. But that's a
significant code. I
don't think PostgreSQL has a facility to induce a delay at a particular place
in the code.
--
Best Wishes,
Ashutosh Bapat
abeled as
ANYNULLTYPE if specific type information is not available. This
problem wouldn't arise then. Of course that's a lot of code to fix
seemingly rare problem so may not be worth it still.
--
Best Wishes,
Ashutosh Bapat
On Fri, Dec 23, 2022 at 2:45 PM Amit Kapila wrote:
> On Thu, Dec 22, 2022 at 6:58 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> > A customer ran a script dropping a few dozens of users in a transaction.
> Before dropping a user they change the ownership of the tab
On Fri, Jan 6, 2023 at 8:28 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > we cast a quoted value to UNKNOWN type, but this is a special value
> > null which can be casted to any SQL data type. Probably we could add a
> > ANYNULLTYPE or some such generic null type wh
On Mon, Jan 9, 2023 at 4:08 PM wangw.f...@fujitsu.com
wrote:
>
> On Fri, Jan 6, 2023 at 15:06 PM Ashutosh Bapat
> wrote:
>
> I'm not sure if we need to add global variables or member variables for a
> cumulative count that is only used here. How would you feel if I a
fact, I am wondering whether we could have a call in
ReorderBufferProcessTxn() at the end of transaction
(commit/prepare/commit prepared/abort prepared) instead of the
corresponding output plugin callbacks calling
OutputPluginUpdateProgress().
--
Best Wishes,
Ashutosh Bapat
er.
If we want to keep the wrapper at least we should use a different
variable name. update_progress is also there LogicalDecodingContext
and will be indirectly called from ReorderBuffer::update_progress.
Somebody might think that there's some recursion involved there.
That's a mighty confusion.
--
Best Wishes,
Ashutosh Bapat
On Wed, Jan 18, 2023 at 1:49 PM wangw.f...@fujitsu.com
wrote:
>
> On Wed, Jan 18, 2023 at 13:29 PM Amit Kapila wrote:
> > On Tue, Jan 17, 2023 at 6:41 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Tue, Jan 17, 2023 at 3:34 PM Amit Kapila
> > > wrote:
g with
similar names in the code base. But it's probably late to do that :).
How are update_txn_progress since the CB is supposed to be used only
within a transaction? or update_progress_txn?
update_progress_cb_wrapper needs a change of name as well.
--
Best Wishes,
Ashutosh Bapat
On Sat, Mar 25, 2023 at 9:13 PM Joseph Koshakow wrote:
>
> On Fri, Mar 24, 2023 at 9:43 AM Ashutosh Bapat
> wrote:
> >
> >You don't need to do this, but looks like we can add DAYS_PER_WEEK macro
> > and
> >use it here.
>
> I've attac
Bumping it to attract some attention.
On Tue, Mar 21, 2023 at 12:51 PM Ashutosh Bapat
wrote:
>
> Hi,
> Hash table scans (seq_scan_table/level) are cleaned up at the end of a
> transaction in AtEOXact_HashTables(). If a hash seq scan continues
> beyond transaction end it will
RROR,
> + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
> + errmsg("interval out of range")));
>
> I think this covers the same overflow check but is maybe a bit more
> obvious. Unless, there's something I'm missing?
Thanks. Your current version is closer to int4um().
Some more review comments in the following email.
--
Best Wishes,
Ashutosh Bapat
/ 5.0 = -inf
The changes in the patch are compliant with the observations above.
--
Best Wishes,
Ashutosh Bapat
#include
void
test_flag(int flag, char *flag_name);
int
main(void)
{
float inf = 1.0/0;
float n_inf = -1.0/0;
printf("inf = %f\n", inf);
printf("-inf = %f
interval
+ | timetz_pl_interval
- | timetz_mi_interval
+ | interval_pl_time
+ | timestamp_pl_interval
- | timestamp_mi
- | timestamp_mi_interval
+ | interval_pl_date
+ | interval_pl_timetz
+ | interval_pl_timestamp
+ | interval_pl_timestamptz
(30 rows)
--
Best Wishes,
Ashutosh Bapat
On Tue, Mar 28, 2023 at 7:17 PM Ashutosh Bapat
wrote:
> make sure that every
> operator that interval as one of its operands or the result has been
> covered in the code.
time_mi_time - do we want to add an Assert to make sure that this
function does not produce an Interval struct
nterval and factor and use a single block using some integer
arithmetic. But I think this is more readable. So I avoided doing
that. Let me know if this works for you.
Also added some test cases.
--
Best Wishes,
Ashutosh Bapat
On Fri, Mar 31, 2023 at 3:46 PM Ashutosh Bapat
wrote:
>
> On Tu
tch looks good, I've combined it with the existing patch.
>
> > Also added some test cases.
>
> I didn't see any tests in the patch, did you forget to include it?
Sorry I forgot to include those. Attached.
Please see my reply to your latest email as well.
--
Best Wis
7;-infinity';
+SELECT date '1995-08-06' - interval 'infinity';
+SELECT date '1995-08-06' - interval '-infinity';
... block truncated
With that I have reviewed the entire patch-set. Once you address these
comments, we can mark it as ready for committer. I already see Tom
looking at the patch. So that might be just a formality.
--
Best Wishes,
Ashutosh Bapat
ed_flush_lsn. While processing XLOG_RUNNING_XACTS record it may
update its restart_lsn and catalog_xmin with current_lsn = lsn fo
XLOG_RUNNING_XACTS record. In this situation current_lsn <=
confirmed_flush_lsn.
Does that make sense?
--
Best Wishes,
Ashutosh Bapat
same
signed for plus and opposite signed for minus. But I think we can
leave this to the committer's judgement. Which route to choose.
>
> >With that I have reviewed the entire patch-set. Once you address these
> >comments, we can mark it as ready for committer. I already see Tom
> >looking at the patch. So that might be just a formality.
>
> Thanks so much for taking the time to review this!
My pleasure. I am very much interested to see this being part of code.
Given that the last commit fest for v16 has ended, let's target this
for v17. I will mark this as ready for committer now.
--
Best Wishes,
Ashutosh Bapat
6525613b7ddb82669d2ba358b31e
--
Best Wishes,
Ashutosh Bapat
est Postgres committers.
>
> Please join me in wishing them much success and few reverts.
>
> regards, tom lane
>
>
--
Best Wishes,
Ashutosh Bapat
in fade. Sorry for the noise.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>
>
--
Best Wishes,
Ashutosh Bapat
On Fri, Mar 25, 2022 at 7:23 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > All these functions are too low level to be helpful to know. Knowing
> > the caller might actually give a hint as to where the unknown node
> > originated from. We may get that from t
time */
+boolonly_local; /* publish only locally generated data */
Are we using this anywhere. I couldn't spot any usage of this member. I might
be missing something though.
--
Best Wishes,
Ashutosh Bapat
>
> > > On Wed, Mar 30, 2022 at 7:40 PM Ashutosh Bapat
> > > wrote:
> > > > >
> > > > > The changes for the same are available int the v5 patch available at
> > > > > [1].
> > > > > [1] -
> >
originated on publisher". From
that angle origin = publisher/any looks attractive. It also leaves
open the possibility that the subscriber may ask changes from a set of
origins or even non-publisher origins.
--
Best Wishes,
Ashutosh Bapat
ng
if there are tools/libraries that can help us to do that. Googling
gives OS specific tools but nothing like a C or perl library which can
be used for this purpose.
--
Best Wishes,
Ashutosh Bapat
uldn't find an example where that is not true.
Tomas, you may want to incorporate this in your patch. If not, I will
incorporate it in my infinite interval patchset in [1].
[1]
https://www.postgresql.org/message-id/CAExHW5u1JE7dxK=wlzqhcszntoxqzjdiermhrepw6r8w6kc...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
On Thu, Oct 12, 2023 at 6:51 PM torikoshia wrote:
>
> On 2023-10-11 16:22, Ashutosh Bapat wrote:
> >
> > Considering the similarity with auto_explain I wondered whether this
> > function should be part of auto_explain contrib module itself? If we
> > do that users
On Mon, Oct 16, 2023 at 7:33 PM Tomas Vondra
wrote:
>
> On 10/16/23 11:25, Ashutosh Bapat wrote:
> > Thanks Tomas for bringing this discussion to hackers.
> >
> >
> > On Fri, Oct 13, 2023 at 8:58 PM Dean Rasheed
> > wrote:
> >>
> >>
#x27;t be able to know the number of such relations involved in the
query unless we start planning such a join. It's late to add new base
relations and assign them new Relids. Of course I haven't thought hard
about it. I haven't looked at the patch to see whether this problem is
solved and how.
--
Best Wishes,
Ashutosh Bapat
| character varying | | |
Partition of: tpart FOR VALUES FROM (7) TO (9)
Indexes:
"t_p4_pkey" PRIMARY KEY, btree (a)
Notice that ALTER TABLE succeeded and t_p4 was attached to tpart as a partition.
Is this backward compatibility break intentional? I haven't followed
NOT NULL constraint thread closely. I might have missed some
discussion.
--
Best Wishes,
Ashutosh Bapat
h IDENTITY columns in partitioned tables.
[1]
https://www.postgresql.org/message-id/CAExHW5uRUtDfU0R8zXofQxCV3S1B%2BPa%2BX%2BNrpMwzKraLc25%3DEg%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/flat/70be435b-05db-06f2-7c01-9bb8ee2fccce%40enterprisedb.com
--
Best Wishes,
Ashutosh Bapat
On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov
wrote:
>
> On 16/10/2023 23:21, Ashutosh Bapat wrote:
> > On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
> > Whenever I visited this idea, I hit one issue prominently - how would
> > we differentiate different scans of the
dex of
> RelOptInfo ?
See Scan::scanrelid
--
Best Wishes,
Ashutosh Bapat
t in core, you will need to port relevant parts of
auto_explain code to core.
--
Best Wishes,
Ashutosh Bapat
s easier to hit. It
> subtracts the values in the opposite order (smaller - larger), so the
> distances are negated. Which means we actually merge the values from the
> most distant ones, and thus are "guaranteed" to build very a very
> inefficient summary. People with multi-m
;
> >
> > Right. Do we highlight that in the commit message so that the person
> > writing release notes picks it up from there?
> >
>
> Yes, I think I'll mention what impact each issue can have on indexes.
Thanks.
--
Best Wishes,
Ashutosh Bapat
3 BC
4713-01-12 BC
4713-01-11 BC
4713-01-10 BC
4713-01-09 BC
4713-01-08 BC
4713-01-07 BC
4713-01-06 BC
4713-01-05 BC
4713-01-04 BC
4713-01-03 BC
4713-01-02 BC
4713-01-01 BC
(32 rows)
--
Best Wishes,
Ashutosh Bapat
On Thu, Oct 19, 2023 at 4:51 PM Tomas Vondra
wrote:
>
> On 10/19/23 11:22, Ashutosh Bapat wrote:
> > On Thu, Oct 19, 2023 at 2:31 PM Tomas Vondra
> > wrote:
> >
> >>
> >> Does that explain the algorithm? I'm not against clarifying the comment
using the same slot type is supposed to be faster. We
use same slot types for input and output in other places where as
well. May be we should fix the above said inefficiency in
tt_virtual_copyslot()?
--
Best Wishes,
Ashutosh Bapat
On Thu, Oct 19, 2023 at 6:11 PM Ashutosh Bapat
wrote:
>
> I think we should provide generate_series(date, date, integer) which
> will use date + integer -> date.
Just to be clear, I don't mean that this patch should add it.
--
Best Wishes,
Ashutosh Bapat
Right.
> However perhaps there is still an opportunity for moving some of the
> auto_explain code into core so as to enable deduplicating the code.
>
Right. That's what I also think.
--
Best Wishes,
Ashutosh Bapat
On Tue, Oct 24, 2023 at 4:30 AM David Rowley wrote:
>
> On Fri, 20 Oct 2023 at 22:30, Ashutosh Bapat
> wrote:
> > I ran my experiments again. It seems on my machine the execution times
> > do vary a bit. I ran EXPLAIN ANALYZE on the query 5 times and took
> > averag
On Tue, Oct 24, 2023 at 8:53 PM José Neves wrote:
>
> Hi there, hope to find you well.
>
> I have a follow-up question to this already long thread.
>
> Upon deploying my PostgreSQL logical replication fed application on a stale
> database, I ended up running out of space, as the replication slot
updated.
Please take a look at XLogSendLogical(void) and the places where
WalSndKeepaliveIfNecessary() is called.
--
Best Wishes,
Ashutosh Bapat
we include 002_standby.pl?
2. CreateReplicationSlotLSN, is not used anywhere. Instead I see
create_logical_replication_slot() in pg_subscriber.c. Which of these
two you intend to use finally?
--
Best Wishes,
Ashutosh Bapat
On Fri, Oct 27, 2023 at 8:48 AM David Rowley wrote:
>
> On Wed, 25 Oct 2023 at 22:48, Ashutosh Bapat
> wrote:
> > We may save the size of data in VirtualTupleTableSlot, thus avoiding
> > the first loop. I assume that when allocating
> > VirtualTupleTableSlot->dat
ttps://www.postgresql.org/message-id/flat/70be435b-05db-06f2-7c01-9bb8ee2fccce%40enterprisedb.com
[2]
https://www.postgresql.org/message-id/caexhw5toasjc7uwseszx6sgvktfxsv7pd606zp6dntx7y6o...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
On Fri, Oct 27, 2023 at 2:07 PM Dean Rasheed wrote:
>
> On Wed, 4 Oct 2023 at 14:29, Ashutosh Bapat
> wrote:
> >
> > I think we should introduce interval_out_of_range_error() function on
> > the lines of float_overflow_error(). Later patches introduce more
> >
d to wait for the
infinite interval patches to commit but I guess, the wait won't be too
long and the outcome will be better. I can include this change in
those patches.
--
Best Wishes,
Ashutosh Bapat
On Fri, Oct 27, 2023 at 10:32 PM Tomas Vondra
wrote:
>
> FWIW I've cleaned up and pushed all the patches we came up with this
> thread. And I've backpatched all of them to 14+.
>
Thanks a lot Tomas.
--
Best Wishes,
Ashutosh Bapat
ke socket. This will also mean that
operations which reduce the number of rows will be favoured and pushed
down. That's what is desired.
--
Best Wishes,
Ashutosh Bapat
On Mon, Oct 30, 2023 at 6:52 AM David Rowley wrote:
>
> On Sun, 29 Oct 2023 at 12:45, Bruce Momjian wrote:
> &
*)parent_rel->pathlist->elements
> [0].ptr_value)->subpath)->path->parent->cheapest_startup_path
> $20 = (struct Path *) 0x55bf9ef7f4e0
This looks familiar though. There was some nearby thread where Tom
Lane, if my memory serves well, provided a case where a path from
lower rel was added to an upper rel without copying or changing its
parent. This very much looks like that case.
--
Best Wishes,
Ashutosh Bapat
hing is wrong.
>
Thanks Andy.
Here's rebased patches. A conflict in explain.out resolved.
--
Best Wishes,
Ashutosh Bapat
From 171ce2bd03f846e7ba3e6972b1f51a432d5f75c5 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat
Date: Wed, 23 Aug 2023 16:23:12 +0530
Subject: [PATCH 2/3] Report memory
Rebased patchset. No changes in actual patches. 0001 is squashed
version of patches submitted at
https://www.postgresql.org/message-id/CAExHW5sCJX7696sF-OnugAiaXS=Ag95=-m1csrjcmyyj8pd...@mail.gmail.com.
On Tue, Oct 3, 2023 at 6:42 PM Ashutosh Bapat
wrote:
>
> On Fri, Sep 29, 2023 at 8:36 A
On Thu, Sep 14, 2023 at 4:39 PM Ashutosh Bapat
wrote:
>
> The patch set is thus
> 0001 - patch used to measure memory used during planning
>
> 0002 - Patch to free intermediate Relids computed by
> adjust_child_relids_multilevel(). I didn't test memory consumption for
>
On Fri, Sep 8, 2023 at 3:22 PM Ashutosh Bapat
wrote:
>
> On Fri, Jul 28, 2023 at 3:16 PM Ashutosh Bapat
> wrote:
> >
> > Hi Tom, Richard,
> >
> > On Mon, Jul 24, 2023 at 8:17 AM Richard Guo wrote:
> > >
> > > Thanks for pushing it!
> &
Hi,
For some reason plannode.h has declared variable to hold RTIs as
Bitmapset * instead of Relids like other places. Here's patch to fix
it. This is superficial change as Relids is typedefed to Bitmapset *.
Build succeeds for me and also make check passes.
--
Best Wishes,
Ashutosh Bapat
On Thu, Oct 26, 2023 at 5:17 PM Ashutosh Bapat
wrote:
>
> On Mon, Oct 23, 2023 at 9:34 AM Euler Taveira wrote:
>
> >
> > It is still a WIP but I would like to share it and get some feedback.
> >
> >
>
> I have started reviewing the patch. I have just
On Wed, Nov 1, 2023 at 7:10 PM Ashutosh Bapat
wrote:
>
> I noticed some differences between this and a similar utility
> https://github.com/2ndQuadrant/pglogical/blob/REL2_x_STABLE/pglogical_create_subscriber.c.
> I will be reviewing these differences next to see if we are missing
>
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks, a sample
script showing how to access the commits being pushed and other
arguments at
https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample.
I have not used it. But it seems that your script can be used to
implement the pre-push hook.
--
Best Wishes,
Ashutosh Bapat
pg_sleep('1000'::double precision)
> >
> > I think this is not an expected behavior and we set elevel to
> > LOG_SERVER_ONLY.
>
>
> Makes sens. Thanks.
--
Best Wishes,
Ashutosh Bapat
On Fri, Nov 3, 2023 at 7:31 PM Ashutosh Bapat
wrote:
>
> I have following questions related to the functionality. (Please point
> me to the relevant discussion if this has been already discussed.)
>
> 1. When a backend is running nested queries, we will see the plan of
> the inn
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 to the previous version.
On Tue, Oct 31, 2023 at 11:06 AM Ashutosh Bapat
wrote
h. Foreign table metadata stores the
mapping between local and remote table as well as column names. Import
can use that mapping to install the statistics appropriately. We may
want to support a command or function in postgres_fdw to import
statistics of all the tables that point to a given foreign server.
That may be some future work based on your current patches.
I have not looked at the code though.
--
Best Wishes,
Ashutosh Bapat
On Tue, Nov 7, 2023 at 8:54 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2023-Oct-31, Ashutosh Bapat wrote:
> >> For some reason plannode.h has declared variable to hold RTIs as
> >> Bitmapset * instead of Relids like other places. Here's patch to fix
l.
> I'm wondering if we can add this after the first patch for this feature
> is committed.
With the current patches, it will print the query from a parallel
backend. If that's not desirable we should prohibit that case at
least.
--
Best Wishes,
Ashutosh Bapat
On Thu, Nov 9, 2023 at 4:56 PM torikoshia wrote:
>
> On 2023-11-09 16:11, Ashutosh Bapat wrote:
> > On Thu, Nov 9, 2023 at 12:03 PM torikoshia
> > wrote:
> >> >>
> >> >> 1. When a backend is running nested queries, we will see the plan of
> &
On Tue, Nov 14, 2023 at 4:39 PM Dean Rasheed wrote:
>
> On Thu, 9 Nov 2023 at 12:49, Dean Rasheed wrote:
> >
> > OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
> >
>
> OK, I have now pushed the main patch.
Thanks a lot Dean.
--
Best Wishes,
Ashutosh Bapat
On Mon, Nov 13, 2023 at 3:51 PM Peter Eisentraut wrote:
>
> On 27.10.23 13:32, Ashutosh Bapat wrote:
> > I think we should fix these anomalies as follows
> > 1. Allow identity columns to be added to the partitioned table
> > irrespective of whether they have partitions
On Mon, Nov 13, 2023 at 3:39 PM Peter Eisentraut wrote:
>
> On 17.10.23 09:25, Ashutosh Bapat wrote:
> > #create table tpart (a serial primary key, src varchar) partition by
> > range(a);
> > CREATE TABLE
> > #create table t_p4 (a int primary key, src varchar);
&
s marked as "final", thus catching the places
where we expect a Bitmapset being modified when not intended. This
will catch shared bitmapsets as well. We could apply bms_copy in only
those cases then.
--
Best Wishes,
Ashutosh Bapat
a times it's only a single backend which needs to be subjected to
an injection. For inducing ERROR and NOTICE, many a times it's also
the same backend attached the client session. For WAIT, however we
need a way to inject from some other session. We might be able to use
current signalling mechanism for that (wake sends SIGUSR1 with
reason). Leaving aside WAIT for a moment when the same backend's
behaviour is being controlled, do we really need shared memory and
also affect all the running backends. I see some discussion about
being able to trigger only for a given PID, but when that PID of the
current backend itself shared memory is not required.
--
Best Wishes,
Ashutosh Bapat
On Wed, Nov 22, 2023 at 3:27 AM Bruce Momjian wrote:
>
> Should this patch be applied?
I think so.
> ---
>
> On Thu, Feb 15, 2018 at 06:57:50PM +0530, Ashutosh Bapat wrote:
> > Hi,
> &g
ty that
> I can think of is to use a custom wait event with a second point to
> setup a different condition. At the end, my point is that it is
> possible to control everything in some extension code that holds the
> callbacks, with an extra shmem area in the extension that associates
> some meta-data with a point name, for instance.
If the session which attaches to an injection point is same as the
session where the injection point is triggered (most of the ERROR and
NOTICE injections will see this pattern), we don't need shared memory.
There's a performance penalty to it since injection_run will look up
shared memory. For WAIT we may or may not need shared memory. But
let's see what other think and what usage patterns we see.
--
Best Wishes,
Ashutosh Bapat
l.org/message-id/CAExHW5tUcVsBkq9qT%3DL5vYz4e-cwQNw%3DKAGJrtSyzOp3F%3DXacA%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAM2%2B6%3DUC1mcVtM0Y_LEMBEGHTM58HEkqHPn7vau_V_YfuZjEGg%40mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
t of
sematically same RestrictInfos. Relids is another key to access the
exact RestrictInfo. A child RestrictInfo can not be used since there
will many child RestrictInfos. Similar parent RestrictInfo can not be
used since there will be multiple forms of the same RestrictInfo.
[1] https://commitfest.postgresql.org/45/4492/
--
Best Wishes,
Ashutosh Bapat
at this
> stuff is useful
I think so.
> and that there are no string objections, so feel free
> to comment.
Let's get some more opinions on the design. I will review the detailed
code then.
>
> I don't want to propose 0003 in the tree, just an improved version of
> 0004 for the test coverage (still need to improve that).
Are you working on v6 already?
--
Best Wishes,
Ashutosh Bapat
tch. My initial point was
> > that replace_relid() should either do in-place in all cases or make a
> > copy in all cases. Now I see that it should make a copy in all cases.
> > Note, that without making a copy in delete case, regression tests fail
> > with REALLOCATE_BITMAPSETS on.
> >
> > Please, find the revised patchset. As Ashutosh Bapat asked, asserts
> > are split into separate patch.
>
> Any objections to pushing this?
>
Did we at least measure the memory impact?
How do we ensure that we are not making unnecessary copies of Bitmapsets?
--
Best Wishes,
Ashutosh Bapat
On Fri, Nov 24, 2023 at 7:37 PM Michael Paquier wrote:
>
> On Fri, Nov 24, 2023 at 04:37:58PM +0530, Ashutosh Bapat wrote:
> > Interesting idea. For that the callback needs to know the injection
> > point name. At least we should pass that to the callback. It's trivial
&g
301 - 400 of 1357 matches
Mail list logo