Please join us in wishing them much success and few reverts!
>
> Thanks,
>
> Jonathan
>
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
On Tue, Apr 16, 2024 at 3:44 PM David Rowley wrote:
> On Tue, 16 Apr 2024 at 17:13, Amul Sul wrote:
> > Attached is a small patch adding the missing BumpContext description to
> the
> > README.
>
> Thanks for noticing and working on the patch.
>
> There were a
Attached is a small patch adding the missing BumpContext description to the
README.
Regards,
Amul
0001-Add-BumpContext-description-to-mmgr-README.patch
Description: Binary data
On Thu, Mar 14, 2024 at 12:48 AM Robert Haas wrote:
> On Fri, Mar 8, 2024 at 12:14 AM Amul Sul wrote:
> > Thank you for the improvement.
> >
> > The caller of verify_control_file() has the full path of the control
> file that
> > can pass it and avoid recomputing
On Thu, Mar 7, 2024 at 11:02 PM Alvaro Herrera
wrote:
> On 2024-Mar-07, Alvaro Herrera wrote:
>
> > Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> > RelationGetPrimaryKeyIndex returned InvalidOid for deferrable PKs; then
> > logical replication would continue to not know about
On Fri, Mar 8, 2024 at 1:22 AM Robert Haas wrote:
> On Thu, Mar 7, 2024 at 9:16 AM Robert Haas wrote:
> > It could. I just thought this was clearer. I agree that it's a bit
> > long, but I don't think this is worth bikeshedding very much. If at a
> > later time somebody feels strongly that it
On Thu, Mar 7, 2024 at 9:37 AM Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 11:05:36AM -0500, Robert Haas wrote:
> > So with that in mind, here's my proposal. This is an adjustment of
> > Amit's previous refactoring patch. He renamed the existing
> > get_controlfile() to
On Fri, Mar 1, 2024 at 11:28 AM Michael Paquier wrote:
> On Mon, Feb 19, 2024 at 12:06:19PM +0530, Amul Sul wrote:
> > Agreed, now they will have an error as _could not read file "":
> Is
> > a directory_. But, IIUC, that what usually happens with the dev version,
&
On Wed, Feb 21, 2024 at 10:01 AM Michael Paquier
wrote:
> On Mon, Feb 19, 2024 at 12:06:19PM +0530, Amul Sul wrote:
> > On Mon, Feb 19, 2024 at 4:22 AM Michael Paquier
> wrote:
> >> And the new option should be documented at the top of the init()
> >> rout
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
> All,
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
On Mon, Feb 19, 2024 at 4:22 AM Michael Paquier wrote:
> On Thu, Feb 15, 2024 at 05:41:46PM +0530, Robert Haas wrote:
> > On Thu, Feb 15, 2024 at 3:05 PM Amul Sul wrote:
> > > Kindly have a look at the attached version.
> >
> > IMHO, 0001 looks fine, except probabl
On Thu, Feb 15, 2024 at 7:18 AM Michael Paquier wrote:
> On Wed, Feb 14, 2024 at 12:29:07PM +0530, Amul Sul wrote:
> > Ok, I did that way in the attached version, I have passed the control
> file's
> > full path as a second argument to verify_system_identifie
On Fri, Feb 2, 2024 at 12:03 AM Robert Haas wrote:
> On Thu, Feb 1, 2024 at 2:18 AM Amul Sul wrote:
> > I intended to minimize the out param of parse_manifest_file(), which
> currently
> > returns manifest_files_hash and manifest_wal_range, and I need two more
> --
On Thu, Feb 1, 2024 at 3:06 AM Robert Haas wrote:
> On Thu, Jan 25, 2024 at 2:52 AM Amul Sul wrote:
> > Thank you for the review-comments, updated version attached.
>
> I generally agree with 0001. I spent a long time thinking about your
> decision to make verifier_context
On Wed, Jan 24, 2024 at 10:53 PM Robert Haas wrote:
> On Mon, Jan 22, 2024 at 2:22 AM Amul Sul wrote:
> > Thinking a bit more on this, I realized parse_manifest_file() has many
> out
> > parameters. Instead parse_manifest_file() should simply return manifest
> data
> >
On Sat, Jan 20, 2024 at 7:55 AM vignesh C wrote:
> On Fri, 22 Sept 2023 at 18:45, Amul Sul wrote:
> >
> >
> >
> > On Wed, Sep 20, 2023 at 8:29 PM Alvaro Herrera
> wrote:
> >>
> >> On 2023-Sep-20, Amul Sul wrote:
> >>
> >>
On Mon, Jan 22, 2024 at 10:08 AM Amul Sul wrote:
>
>
> On Fri, Jan 19, 2024 at 10:36 PM Amul Sul wrote:
>
>> On Wed, Jan 17, 2024 at 8:40 PM Robert Haas
>> wrote:
>>
>>>
>>>
>> Updated version is attached.
>>
>
> Anot
On Fri, Jan 19, 2024 at 10:36 PM Amul Sul wrote:
> On Wed, Jan 17, 2024 at 8:40 PM Robert Haas wrote:
>
>>
>>
> Updated version is attached.
>
Another updated version attached -- fix missing manifest version check in
pg_verifybackup before system identifier validat
On Thu, Jan 18, 2024 at 6:39 AM Sravan Kumar
wrote:
> I have also done a review of the patch and some testing. The patch looks
> good, and I agree with Robert's comments.
>
Thank you for your review, testing and the offline discussion.
Regards,
Amul
On Wed, Jan 17, 2024 at 8:40 PM Robert Haas wrote:
> On Wed, Jan 17, 2024 at 6:31 AM Amul Sul wrote:
> > With the attached patch, the backup manifest will have a new key item as
> > "System-Identifier" 64-bit integer whose value is derived from
> pg_
On Wed, Jan 17, 2024 at 5:15 PM Alvaro Herrera
wrote:
> On 2024-Jan-17, Amul Sul wrote:
>
> > This helps to identify the correct database server and/or backup for the
> > subsequent backup operations. pg_verifybackup validates the manifest
> system
> > identifier agai
binebackup is already a bit smarter -- checks the system identifier
from
the pg_control of all the backups, with this patch the manifest system
identifier also validated.
For backward compatibility, the manifest system identifier validation will
be
skipped for version 1.
--
Regards,
Amul Sul
On Mon, Jan 8, 2024 at 10:48 PM Nathan Bossart
wrote:
> On Mon, Jan 08, 2024 at 11:13:42AM +0530, Amul Sul wrote:
> > +void *
> > +dsm_registry_init_or_attach(const char *key, size_t size,
> >
> > I think the name could be simple as dsm_registry_init() li
On Mon, Jan 8, 2024 at 10:53 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Sat, Jan 6, 2024 at 10:05 PM Nathan Bossart
> wrote:
> >
> > I kept this the same, as I didn't see any need to tie the key size to
> > NAMEDATALEN.
>
> Thanks. A fresh look at the v5 patches
On Fri, Jan 5, 2024 at 12:28 AM Peter Eisentraut
wrote:
> On 25.12.23 13:10, Amul Sul wrote:
> >
> I have committed this patch set.
>
> I couple of notes:
>
> You had included the moving of the AT_PASS_ADD_COL enum in the first
> patch. This is not a good style.
On Mon, Dec 18, 2023 at 3:01 PM Peter Eisentraut
wrote:
> On 11.12.23 13:22, Amul Sul wrote:
> >
> > create table t1 (a int, b int generated always as (a + 1) stored);
> > alter table t1 add column c int, alter column b set expression as (a
> > + c);
>
On Mon, Dec 11, 2023 at 10:42 AM Dilip Kumar wrote:
> On Thu, Nov 30, 2023 at 3:30 PM Dilip Kumar wrote:
> >
> > On Wed, Nov 29, 2023 at 4:58 PM Dilip Kumar
> wrote:
>
> Here is the updated patch based on some comments by tender wang (those
> comments were sent only to me)
>
few nitpicks:
+
On Tue, Nov 28, 2023 at 5:40 PM Peter Eisentraut
wrote:
> On 23.11.23 15:13, Amul Sul wrote:
> > The exact sequencing of this seems to be tricky. It's clear that we
> > need to do it earlier than at the end. I also think it should be
> > strictly after
On Mon, Nov 20, 2023 at 1:12 PM Peter Eisentraut
wrote:
> On 17.11.23 13:25, Amul Sul wrote:
> > To fix this we should be doing something like ALTER COLUMN TYPE and the
> pass
> > should be AT_PASS_ALTER_TYPE (rename it or invent a new one near to
> that) so
> > that
On Thu, Nov 16, 2023 at 7:05 PM Amul Sul wrote:
> On Thu, Nov 16, 2023 at 2:50 AM Peter Eisentraut
> wrote:
>
>> On 15.11.23 13:26, Amul Sul wrote:
>> > Question: Why are you using AT_PASS_ADD_OTHERCONSTR? I don't know
>> if
>> > it's right or w
On Thu, Nov 16, 2023 at 2:50 AM Peter Eisentraut
wrote:
> On 15.11.23 13:26, Amul Sul wrote:
> > Question: Why are you using AT_PASS_ADD_OTHERCONSTR? I don't know if
> > it's right or wrong, but if you have a specific reason, it would be
> > good
> >
On Wed, Nov 15, 2023 at 9:26 PM Nathan Bossart
wrote:
> On Wed, Nov 15, 2023 at 09:27:18AM +0530, Amul Sul wrote:
> > Nevermind, I usually use git apply or git am, here are those errors:
> >
> > PG/ - (master) $ git apply
> ~/Downloads/retire_compatibility_macro_v1.patch
On Wed, Nov 15, 2023 at 5:09 PM Peter Eisentraut
wrote:
> On 14.11.23 11:40, Amul Sul wrote:
> > Please have a look at the attached version, updating the syntax to have
> "AS"
> > after EXPRESSION and other changes suggested previously.
>
> The code structure
On Tue, Nov 14, 2023 at 9:21 PM Nathan Bossart
wrote:
> On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
> > Changes looks pretty much straight forward, but patch failed to apply on
> the
> > latest master head(b41b1a7f490) at me.
>
> Thanks for taking a look.
On Tue, Nov 14, 2023 at 12:30 AM Nathan Bossart
wrote:
> I just found myself researching the difference between MemoryContextReset()
> and MemoryContextResetAndDeleteChildren(), and it turns out that as of
> commit eaa5808 (2015), there is none.
> MemoryContextResetAndDeleteChildren() is just a
On Mon, Nov 13, 2023 at 9:09 PM Peter Eisentraut
wrote:
> On 13.11.23 14:07, Amul Sul wrote:
> > Also, it seems to me that the SET EXPRESSION variant should just do
> an
> > update of the catalog table instead of a drop and re-insert.
> >
> > I am not sure
On Mon, Nov 13, 2023 at 1:40 PM Peter Eisentraut
wrote:
> On 09.11.23 13:00, Amul Sul wrote:
> > On Tue, Nov 7, 2023 at 8:21 PM Peter Eisentraut > <mailto:pe...@eisentraut.org>> wrote:
> >
> > On 25.10.23 08:12, Amul Sul wrote:
> > > Here i
On Tue, Nov 7, 2023 at 8:21 PM Peter Eisentraut
wrote:
> On 25.10.23 08:12, Amul Sul wrote:
> > Here is the rebase version for the latest master head(673a17e3120).
> >
> > I haven't done any other changes related to the ON UPDATE trigger since
> that
> > seems n
On Fri, Nov 3, 2023 at 10:59 AM Dilip Kumar wrote:
> On Mon, Oct 30, 2023 at 11:50 AM Dilip Kumar
> wrote:
> > [...]
> [1] 0001-Make-all-SLRU-buffer-sizes-configurable: This is the same
> patch as the previous patch set
> [2] 0002-Add-a-buffer-mapping-table-for-SLRUs: Patch to introduce
>
On Mon, Nov 6, 2023 at 4:44 PM Andrey M. Borodin
wrote:
>
>
> > On 6 Nov 2023, at 14:31, Alvaro Herrera wrote:
> >
> > dynahash is notoriously slow, which is why we have simplehash.h since
> > commit b30d3ea824c5. Maybe we could use that instead.
>
> Dynahash has lock partitioning. Simplehash
, and the correct
direction
for that.
Regards,
Amul
From 0b6ca9d74ecb7debfe02af340843fa80c937684f Mon Sep 17 00:00:00 2001
From: Amul Sul
Date: Mon, 9 Oct 2023 12:00:04 +0530
Subject: [PATCH v2 2/2] Allow to change generated column expression
---
doc/src/sgml/ref/alter_table.sgml | 14 +-
src/backend
slow down a code path.
> - Pause and release with condition variable.
+1 for the feature.
TWIMW, here[1] is an interesting talk from pgconf.in 2020 on the similar
topic.
1] https://pgconf.in/conferences/pgconfin2020/program/proposals/101
Regards,
Amul Sul
On Fri, Oct 6, 2023 at 6:03 PM Peter Eisentraut
wrote:
> On 28.08.23 11:54, Amul Sul wrote:
> > Thanks for the review comments, I have fixed those in the attached
> > version. In
> > addition to that, extended syntax to have the STORE keyword as suggested
> by
> >
On Wed, Sep 20, 2023 at 8:29 PM Alvaro Herrera
wrote:
> On 2023-Sep-20, Amul Sul wrote:
>
> > On the latest master head, I can see a $subject bug that seems to be
> related
> > commit #b0e96f311985:
> >
> > Here is the table definition:
> > create table
btree (i) DEFERRABLE
The pg_attribute entry:
=# select attname, attnotnull from pg_attribute
where attrelid = 'foo'::regclass and attnum > 0;
attname | attnotnull
-+
i | f
j | f
(2 rows)
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
On Thu, Sep 14, 2023 at 7:23 PM Ashutosh Bapat
wrote:
> Hi Amul,
> I share others opinion that this feature is useful.
>
> >> On Fri, 25 Aug 2023 at 03:06, Vik Fearing
> wrote:
> >>>
> >>>
> >>> I don't like this part of the patch at all. Not only is the
> >>> documentation only half baked,
On Wed, Sep 13, 2023 at 2:28 PM Maxim Orlov wrote:
> Hi!
>
> I'm pretty much like the idea of the patch. Looks like an overlook in SQL
> standard for me.
> Anyway, patch apply with no conflicts and implements described
> functionality.
>
>
Thank you for looking at this.
> On Fri, 25 Aug 2023
On Fri, Aug 25, 2023 at 5:35 AM Vik Fearing wrote:
> On 8/2/23 12:35, Amul Sul wrote:
> > Hi,
> >
> > Currently, we have an option to drop the expression of stored generated
> > columns
> > as:
> >
> > ALTER [ COLUMN ] column_name DROP EXPRESSION
On Thu, Aug 24, 2023 at 9:36 AM Vaibhav Dalvi <
vaibhav.da...@enterprisedb.com> wrote:
> Hi Amul,
>
>
> On Wed, Aug 2, 2023 at 4:06 PM Amul Sul wrote:
>
>> Hi,
>>
>> Currently, we have an option to drop the expression of stored generated
>> columns
&
On Wed, Aug 2, 2023 at 9:16 PM jian he wrote:
> On Wed, Aug 2, 2023 at 6:36 PM Amul Sul wrote:
> >
> > Hi,
> >
> > Currently, we have an option to drop the expression of stored generated
> columns
> > as:
> >
> > ALTER [ COLUMN ] column_name DROP
* FROM t1;
x | y
---+
1 | 4
2 | 8
3 | 12
(3 rows)
Thank you.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
From ef1448f7852000d5b701f9e3c7fe88737670740a Mon Sep 17 00:00:00 2001
From: Amul Sul
Date: Mon, 31 Jul 2023 15:43:51 +0530
Subject: [PATCH v1 2/2] Allow to change generated
On Fri, Jul 28, 2023 at 8:59 PM Christoph Berg wrote:
> The PostgreSQL contributors team has been looking over the community
> activity and, over the first half of this year, has been recognizing
> new contributors to be listed on
>
> https://www.postgresql.org/community/contributors/
>
> New
try to drop this policy, get dropped without any warning/error
unlike tables or other objects which are not allowed to drop at all.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
in wishing them much success and few reverts.
>
> regards, tom lane
>
>
>
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
Hi,
The attached patch removes the comment line noting the same as the
previous paragraph of the ExecUpdateAct() prolog comment.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index f419c47065a
On Tue, Dec 27, 2022 at 11:17 PM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Here's a patch that covers the ltree and intarray contrib modules.
>
> I would probably have done this a little differently --- I think
> the added "res" parameters aren't really necessary for most of
> these. But
On Thu, Dec 15, 2022 at 11:16 AM Tom Lane wrote:
>
> Amul Sul writes:
> > There are other a bunch of hard errors from get_multirange_io_data(),
> > get_range_io_data() and its subroutine can hit, shouldn't we care
> > about those?
>
> I think those are all "
On Thu, Dec 15, 2022 at 9:03 AM Tom Lane wrote:
>
> Here are some proposed patches for converting range_in and multirange_in.
>
> 0001 tackles the straightforward part, which is trapping syntax errors
> and called-input-function errors. The only thing that I think might
> be controversial here
we probably could fix the grammar to be non-throwing, but
> it'd be very invasive and I'm not sure about the performance impact.
> It might be best to content ourselves with soft reporting of lookup
> failures, as opposed to syntax problems.
>
Regards,
Amul
From 4c4c18bd8104114351ca58a73a9d92fbb0c85dd2 Mon S
On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote:
>
>
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 2022-12-08 Th 21:59, Tom Lane wrote:
> >>> Yeah, I was planning to take a look at that before walking away from
> >>> this stuff. (I'm sure not volunteering to
remove that.
>
>
> Regards,
>
> Karthik
>
>
>
> From: Amul Sul
> Date: Tuesday, 8 November 2022 at 5:38 PM
> To: Karthik Jagadish (kjagadis)
> Cc: pgsql-hack...@postgresql.org , Prasanna
> Satyanarayanan (prassaty) , Chandruganth Ayyavoo Selvam
> (chaayy
On Tue, Nov 8, 2022 at 5:00 PM Karthik Jagadish (kjagadis)
wrote:
>
> Hi,
>
> We have a NMS application where we are using postgres as database, what we
> are noticing is that vacuuming is not happening for certain tables for 2-3
> days and eventually the table bloats and disk space is running
On Fri, Oct 28, 2022 at 10:43 AM Tom Lane wrote:
>
> David Rowley writes:
> > On Fri, 28 Oct 2022 at 16:51, Amul Sul wrote:
> >> If we
> >> are too sure that the output usually comes in the same order then the
> >> ORDER BY clause that exists i
On Fri, Oct 28, 2022 at 10:28 AM David Rowley wrote:
>
> On Fri, 28 Oct 2022 at 16:51, Amul Sul wrote:
> >
> > On Thu, Oct 27, 2022 at 6:54 PM Tom Lane wrote:
> > > Please be specific about the circumstances in which the output is
> > > unstable f
On Thu, Oct 27, 2022 at 6:54 PM Tom Lane wrote:
>
> Nishant Sharma writes:
> > We would like to share a proposal of a patch, where we have added order by
> > clause in two select statements in src/test/regress/sql/insert.sql file and
> > respective changes in src/test/regress/expected/insert.out
On Tue, Oct 18, 2022 at 12:01 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> In standby mode, the state machine in WaitForWALToBecomeAvailable()
> reads WAL from pg_wal after failing to read from the archive. This is
> currently implemented in XLogFileReadAnyTLI() by calling
> XLogFileRead() with source
On Tue, Oct 4, 2022 at 12:00 PM Peter Eisentraut
wrote:
>
> On 16.05.22 10:27, Peter Eisentraut wrote:
> > Inspired by [0], I looked to convert more macros to inline functions.
>
> Here is another one from the same batch of work that I somehow didn't
> send in last time.
>
I think assertion can
On Fri, Sep 9, 2022 at 3:32 PM Dilip Kumar wrote:
>
> On Thu, Sep 8, 2022 at 4:10 PM Dilip Kumar wrote:
>
> > On a separate note, while reviewing the latest patch I see there is some
> > risk of using the unflushed relfilenumber in GetNewRelFileNumber()
> > function. Basically, in the current
On Wed, Sep 14, 2022 at 12:16 PM wrote:
>
> I still wonder, if assert doesn't catch why that place is marked as
> covered here?
> https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
>
Probably other tests cover that.
Regards,
Amul
we get rid of all prepared
+ * statements. This is annoying and not terribly bulletproof, but it's
+ * probably not worth trying harder.
+ *
+ * DEALLOCATE ALL only exists in 8.3 and later, so this constrains how old
+ * a server postgres_fdw can communicate with. We intentionally ignore
+
Hi,
On Thu, Jul 28, 2022 at 4:05 AM Jacob Champion wrote:
>
> On Fri, Apr 8, 2022 at 7:27 AM Amul Sul wrote:
> > Attached is rebase version for the latest maste head(#891624f0ec).
>
> Hi Amul,
>
> I'm going through past CF triage emails today; I noticed that
On Fri, Jul 22, 2022 at 4:21 PM vignesh C wrote:
>
> On Wed, Jul 20, 2022 at 4:57 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 18, 2022 at 4:51 PM Dilip Kumar wrote:
> > >
> > > I was doing some more testing by setting the FirstNormalRelFileNumber
> > > to a high value(more than 32 bits) I have
Thanks Aleksander and Álvaro for your inputs.
I understand this change is not making any improvement to the current
code. I was a bit concerned regarding the design and consistency of
the function that exists for the server in recovery and for the server
that is not in recovery. I was trying to
,
Amul Sul
EDB: http://www.enterprisedb.com
On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
wrote:
>
> Hi,
>
> Today I hit "ERROR: target lists can have at most 1664 entries", and I was
> surprised the limit was not documented.
>
> I suggest that the limit of "1664 columns per tuple" (or whatever is the
> right term) should be added
>
On Mon, May 16, 2022 at 1:58 PM Peter Eisentraut
wrote:
>
>
> Inspired by [0], I looked to convert more macros to inline functions.
> The attached patches are organized "bottom up" in terms of their API
> layering; some of the later ones depend on some of the earlier ones.
>
All the patches look
Sorry, hit the send button too early :|
Attached here !!
On Fri, May 13, 2022 at 10:20 AM Amul Sul wrote:
>
> Hi,
>
> PFA, attached patch to $SUBJECT.
>
> --
> Regards,
> Amul Sul
> EDB: http://www.enterprisedb.com
code_comment.patch
Description: Binary data
Hi,
PFA, attached patch to $SUBJECT.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
Hi Dilip,
On Fri, Mar 4, 2022 at 11:07 AM Dilip Kumar wrote:
>
> On Mon, Feb 21, 2022 at 1:21 PM Dilip Kumar wrote:
> >
> > On Thu, Jan 6, 2022 at 1:43 PM Dilip Kumar wrote:
> >
> > 2) GetNewRelFileNode() will not loop for checking the file existence
> > > and retry with other relfilenode.
>
On Tue, May 3, 2022 at 8:04 PM Peter Eisentraut
wrote:
>
> On 03.05.22 08:50, Amul Sul wrote:
> >> Do you have any data that supports removing DirectionFunctionCall()
> >> invocations? I suppose some performance benefit could be expected, or
> >> what do you
On Mon, May 2, 2022 at 8:23 PM Peter Eisentraut
wrote:
>
> On 22.04.22 14:26, Amul Sul wrote:
> > Yes, I think we can do cleanup to some extent. Attaching the
> > following patches that first intend to remove DirectFunctionCall as
> > much as possible:
>
> Do y
On Sat, Apr 23, 2022 at 1:34 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 15, 2021 at 12:56 PM Amul Sul wrote:
> > >
> > > It is a very minor change, so I rebased the patch. Please take a look, if
> > > that works for you.
> > >
> >
> > Than
On Mon, Apr 25, 2022 at 7:23 PM Alvaro Herrera wrote:
>
> On 2022-Apr-25, Alvaro Herrera wrote:
>
> > On 2022-Apr-25, Alvaro Herrera wrote:
> >
> > > I added one change to include spgist too, which was uncovered, and
> > > pushed this.
> >
Thanks for the commit with the improvement.
Regards,
On Fri, Mar 18, 2022 at 1:17 AM Greg Stark wrote:
>
> On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
> >
> > Amul Sul writes:
>
> > > Yeah, that's true, I am too not sure if we really need to refactor
> > > all those; If we want, I can give it a try.
&g
On Tue, Apr 19, 2022 at 2:14 AM Robert Haas wrote:
>
> On Sat, Jan 15, 2022 at 11:52 PM Julien Rouhaud wrote:
> > The cfbot reports that this version of the patch doesn't apply anymore:
>
> Here is a new version of the patch which, unlike v1, I think is
> something we could seriously consider
On Tue, Apr 19, 2022 at 2:14 AM Robert Haas wrote:
>
> On Sat, Jan 15, 2022 at 11:52 PM Julien Rouhaud wrote:
> > The cfbot reports that this version of the patch doesn't apply anymore:
>
> Here is a new version of the patch which, unlike v1, I think is
> something we could seriously consider
Hi,
The attached patch replaces the hard-coded type alignment value with
the defined macro for the same.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c
index ce8c1badb39..ef6f14785a0 100644
--- a/src/backend
On Wed, Feb 16, 2022 at 4:50 PM Peter Eisentraut
wrote:
>
> On 16.02.22 06:00, Amul Sul wrote:
> > Currently, numeric_pg_lsn is the only one that accepts the Numeric
> > value and converts to uint64 and that is the reason all the type
> > conversion code is embedded into
SQL function
like numeric_pg_lsn which wants to accept values up to the uint64
range can use that function.
Thoughts? Comments?
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
From 98feb2bb92d2534cccaea57cd9b9777193bacae4 Mon Sep 17 00:00:00 2001
From: Amul Sul
Date: Tue, 15 Feb 2022 23:57
On Mon, Feb 14, 2022 at 3:07 PM Heikki Linnakangas wrote:
>
> On 28/01/2022 12:10, Amul Sul wrote:
> > On Thu, Jan 27, 2022 at 12:01 PM Michael Paquier
> > wrote:
> >>
> >> After reading this patch and this thread, I have noticed that you are
> >>
On Thu, Jan 27, 2022 at 12:01 PM Michael Paquier wrote:
>
> On Thu, Jan 20, 2022 at 12:13:08PM +0530, Amul Sul wrote:
> > I found the cause for the test failing on window -- is due to the
> > custom archive command setting which wasn't setting the correct window
> >
On Wed, Jan 5, 2022 at 1:12 AM Robert Haas wrote:
>
> On Wed, Dec 29, 2021 at 7:08 AM Amul Sul wrote:
> > Thought patch is WIP, here are a few comments that I found while
> > reading the patch and thought might help:
> >
> > + {
> > +
On Tue, Jan 25, 2022 at 10:08 AM Michael Paquier wrote:
>
> On Wed, Dec 01, 2021 at 07:09:34PM +, Bossart, Nathan wrote:
> > The patch no longer applied, so I went ahead and rebased it.
>
> This was on the CF stack for some time, so applied. I have also
> changed the messages produced for
tom wal archive and restore patch in
the TAP test. The attach 0001 patch proposes the same, which enables
you to choose a custom WAL archive and restore directory. The only
concern I have is that $node->info() will print the wrong archive
directory path in that case, do we need to fix that? We might ne
On Sat, Jan 15, 2022 at 11:35 AM Julien Rouhaud wrote:
>
> Hi,
>
> On Mon, Jan 10, 2022 at 09:46:23AM +0530, Amul Sul wrote:
> >
> > Thanks for the note, I can see the same test is failing on my centos
> > vm too with the latest master head(376
On Mon, Jan 10, 2022 at 8:25 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-11-23 11:43:21 +0530, Amul Sul wrote:
> > Attached patch covers a case where TLI in the filename for a
> > record being read is different from where it belongs to. In other
> > words,
On Fri, Dec 31, 2021 at 7:56 AM Amit Langote wrote:
>
> On Tue, Dec 28, 2021 at 22:12 Ashutosh Bapat
> wrote:
>>
>> On Sat, Dec 25, 2021 at 9:06 AM Amit Langote wrote:
>> >
>> > Executing generic plans involving partitions is known to become slower
>> > as partition count grows due to a number
On Mon, Jan 3, 2022 at 2:56 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-12-14 20:23:57 +, Bossart, Nathan wrote:
> > As promised, here is v2. This patch set includes handling for all
> > four tasks noted upthread. I'd still consider this a work-in-
> > progress, as I've done minimal
On Wed, Dec 29, 2021 at 7:26 PM Nitin Jadhav
wrote:
>
>
> > -* For range partitioning, we must only perform pruning with values
> > -* for either all partition keys or a prefix thereof.
> > +* For range partitioning and list partitioning, we must only
> > perform
> > +
On Wed, Dec 15, 2021 at 9:04 PM Robert Haas wrote:
>
> On Wed, Dec 15, 2021 at 10:03 AM Matthias van de Meent
> wrote:
> [...]
Thought patch is WIP, here are a few comments that I found while
reading the patch and thought might help:
+ {
+ if (meta->cbm_oldest_index_segment ==
+
1 - 100 of 344 matches
Mail list logo
