On Thu, Sep 26, 2024 at 12:18 AM Robert Haas wrote:
>
> On Thu, Sep 12, 2024 at 7:05 AM Amul Sul wrote:
> > The updated version attached. Thank you for the review !
>
> I have spent a bunch of time on this and have made numerous revisions.
> I hope to commit the result, aft
ndle unpacking and
repacking tar files and the required path formats for these tests but
the "Cirrus CI / Windows - Server 2019, VS 2019" workflow doesn’t have
any issues with them. I’ve removed the flag.
> + my @files = glob("*");
> + system_or_bail($tar,
On Sat, Aug 24, 2024 at 2:02 AM Robert Haas wrote:
>
> On Wed, Aug 21, 2024 at 7:08 AM Amul Sul wrote:
> []
> Then the result verifies. But I feel like we should have some test
> cases that do this kind of stuff so that there is automated
> verification. In fact, the curr
On Tue, Aug 20, 2024 at 3:56 PM Amul Sul wrote:
>
> On Sat, Aug 17, 2024 at 1:34 AM Robert Haas wrote:
> >
> > On Fri, Aug 16, 2024 at 3:53 PM Robert Haas wrote:
[...]
> > There's probably more to look at here but I'm running out of energy for
> > tod
etical: you added .tgz elsewhere
> but not here.
>
Did this way.
> There's probably more to look at here but I'm running out of energy for today.
>
Thank you for the review and committing 0004 and 0006 patches.
Regards,
Amul
From dfaeebdc09fd689b7e45a705e32111cb226a0
acb44cfb526bdabcd3a3d9c06443f1 Mon Sep 17 00:00:00 2001
From: Amul Sul
Date: Tue, 20 Aug 2024 09:44:56 +0530
Subject: [PATCH] Remove unnecessary #include statements.
---
src/bin/pg_verifybackup/pg_verifybackup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/bin/pg_verify
Hi,
The Assert(buffer != NULL) is placed after the buffer is accessed,
which could lead to a segmentation fault before the check is executed.
Attached a small patch to correct that.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
diff --git a/src/backend/commands/copyfrom.c b/src/backend
On Tue, Aug 13, 2024 at 10:49 PM Robert Haas wrote:
>
> On Mon, Aug 12, 2024 at 5:13 AM Amul Sul wrote:
> > I tried this in the attached version and made a few additional changes
> > based on Sravan's off-list comments regarding function names and
> > descriptio
On Wed, Aug 7, 2024 at 11:28 PM Robert Haas wrote:
>
> On Wed, Aug 7, 2024 at 1:05 PM Amul Sul wrote:
> > The main issue I have is computing the total_size of valid files that
> > will be checksummed and that exist in both the manifests and the
> > backup, in the ca
On Wed, Aug 7, 2024 at 9:12 PM Robert Haas wrote:
>
> [ I committed 0001, then noticed I had a type in the subject line of
> the commit message. Argh. ]
>
> On Wed, Aug 7, 2024 at 9:41 AM Amul Sul wrote:
> > With the patch, I am concerned that we won't be able to giv
On Tue, Aug 6, 2024 at 10:39 PM Robert Haas wrote:
>
> On Thu, Aug 1, 2024 at 9:19 AM Amul Sul wrote:
> > > I think I would have made this pass context->show_progress to
> > > progress_report() instead of the whole verifier_context, but that's an
> > > ar
On Fri, Aug 2, 2024 at 7:07 PM Robert Haas wrote:
>
> On Fri, Apr 19, 2024 at 11:47 AM Robert Haas wrote:
> >
> [...]
> Here is a rebased version of the patch. No other changes since v1.
>
Here are two minor comments on this:
$ pg_combinebackup /tmp/backup_full/ /tmp/backup_incr2/
/tmp/backup_
On Mon, Aug 5, 2024 at 9:05 PM Junwang Zhao wrote:
>
> Hi Amul,
>
> Thanks for your review.
>
> On Mon, Aug 5, 2024 at 8:38 PM Amul Sul wrote:
> >
> > On Mon, Jul 15, 2024 at 11:19 AM Junwang Zhao wrote:
> > >
> >[...]
> > static Relat
On Mon, Aug 5, 2024 at 10:29 PM Robert Haas wrote:
>
> On Fri, Aug 2, 2024 at 7:43 AM Amul Sul wrote:
> > Please consider the attached version for the review.
>
> Thanks. I committed 0001-0003. The only thing that I changed was that
> in 0001, you forgot to pgindent, wh
On Mon, Jul 15, 2024 at 11:19 AM Junwang Zhao wrote:
>
> In [1], it is suggested that it might be a good idea to support
> specifying the tablespace for each merged/split partition.
>
> We can do the following after this feature is supported:
>
> CREATE TABLESPACE tblspc LOCATION '/tmp/tblspc';
>
On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote:
> On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote:
> >
> >
> >
> > On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
> >>
> >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila
> wrote:
> >> [...
On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote:
> On Wed, 5 Jun 2024 at 14:11, Amit Kapila wrote:
> [...]
> A new catalog table, pg_subscription_seq, has been introduced for
> mapping subscriptions to sequences. Additionally, the sequence LSN
> (Log Sequence Number) is stored, facilitating deter
ease 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 t
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 ne
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 get_dir_controlfile()
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()
> >> routine for
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_identif
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 co
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.
>>
>
> Another
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_control whil
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 le
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. Ref
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
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 b
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
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
> buffer
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 h
d 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/ba
- Sleep to 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
KEY, 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, but
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 at
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
ELECT * 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 gene
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 Pos
u 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 it
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 &qu
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 is
ose. Now, 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 4c4c18bd8104114351ca58a73a
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 co
ng 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
> (chaayyav
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 o
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 for you.
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 be
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
evel)
+ return false;
+
+ /*
+ * If there were any errors in subtransactions, and we made prepared
+ * statements, do a DEALLOCATE ALL to make sure we get rid of all prepared
+ * statements. This is annoying and not terribly bulletproof, but it's
+ * probably not worth trying harder.
+ *
+
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 th
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 not
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 w
eplayTLI;
Thoughts?
--
Regards,
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,
Amu
1 - 100 of 367 matches
Mail list logo
