On Tue, Apr 20, 2021 at 6:59 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 19 Apr 2021 16:27:25 +0530, Amul Sul wrote in
> > On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi
> > wrote:
> > > + smgrwrite(RelationGetSmgr(index), INIT_FORKNUM,
On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 19 Apr 2021 12:56:18 +0530, Amul Sul wrote in
> > On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier
> > wrote:
> > >
> > > On Fri, Apr 09, 2021 at 06:45:45PM -0400, Alvaro Herrera wrote:
On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 06:45:45PM -0400, Alvaro Herrera wrote:
> > We forgot this patch earlier in the commitfest. Do people think we
> > should still get it in on this cycle? I'm +1 on that, since it's a
> > safety feature poised to
On Mon, Apr 19, 2021 at 11:05 AM Bharath Rupireddy
wrote:
>
> On Mon, Apr 19, 2021 at 9:32 AM Amul Sul wrote:
> > Kindly ignore the previous version -- has unnecessary change.
> > See the attached.
>
> Thanks for the patch!
>
> How about a slight rewording of the
On Mon, Apr 19, 2021 at 9:28 AM Amul Sul wrote:
>
> On Fri, Apr 16, 2021 at 6:26 AM Bharath Rupireddy
> wrote:
> >
> > On Thu, Apr 15, 2021 at 8:40 PM Jeevan Ladhe
> > wrote:
> > > IMHO, I think the idea here was to just get rid of an unnecessary va
PM Bharath Rupireddy
> > wrote:
> >>
> >> On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote:
> >> >
> >> > Hi,
> >> >
> >> > Attached patch removes "is_foreign_table" from transformCreateStmt()
> >> > since
On Thu, Apr 15, 2021 at 5:47 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote:
> >
> > Hi,
> >
> > Attached patch removes "is_foreign_table" from transformCreateStmt()
> > since it already has cxt.isforeign th
Hi,
Attached patch removes "is_foreign_table" from transformCreateStmt()
since it already has cxt.isforeign that can serve the same purpose.
Regards,
Amul
diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index 9dd30370dae..97e6d65158c 100644
---
On Fri, Apr 9, 2021 at 9:23 PM Fujii Masao wrote:
>
>
>
> On 2021/04/10 0:39, Amul Sul wrote:
> > On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy
> > wrote:
> >>
> >> Hi,
> >>
> >> While checking the ExecuteTruncate code for
On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> While checking the ExecuteTruncate code for the FOREIGN TRUNCATE
> feature, I saw that we filter out the duplicate relations specified in
> the TRUNCATE command. But before skipping the duplicates, we are just
> opening the
On Wed, Apr 7, 2021 at 6:52 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 6:04 PM Ashutosh Bapat
> wrote:
> > At best CREATE SEQUENCE START ... RESTART ... can be a shorthand
> > for CREATE SEQUENCE ... START; ALTER SEQUENCE ... RESTART run back to
> > back. So it looks useful but
On Thu, Mar 25, 2021 at 12:10 PM Kyotaro Horiguchi
wrote:
>
> Sorry for the bug.
>
> At Thu, 25 Mar 2021 01:50:29 -0400, Tom Lane wrote in
> > Amul Sul writes:
> > > On Wed, Mar 24, 2021 at 8:09 PM Tom Lane wrote:
> > >> static inline struct SMgrRelatio
On Wed, Mar 24, 2021 at 8:09 PM Tom Lane wrote:
>
> Amul Sul writes:
> > On Tue, Mar 23, 2021 at 8:59 PM Tom Lane wrote:
> >> On closer inspection, I believe the true culprit is c6b92041d,
> >> which did this:
> >> - heap_sync(state->rs_ne
On Tue, Mar 23, 2021 at 8:59 PM Tom Lane wrote:
>
> I wrote:
> > Michael Paquier writes:
> >> One bisect later, the winner is:
> >> commit: 3d351d916b20534f973eda760cde17d96545d4c4
> >> author: Tom Lane
> >> date: Sun, 30 Aug 2020 12:21:51 -0400
> >> Redefine pg_class.reltuples to be -1 before
On Mon, Mar 22, 2021 at 3:03 PM Amit Langote wrote:
>
> On Mon, Mar 22, 2021 at 5:26 PM Amul Sul wrote:
> > In heapam_relation_copy_for_cluster(), begin_heap_rewrite() sets
> > rwstate->rs_new_rel->rd_smgr correctly but next line
> > tuplesort_begin_cluste
In heapam_relation_copy_for_cluster(), begin_heap_rewrite() sets
rwstate->rs_new_rel->rd_smgr correctly but next line tuplesort_begin_cluster()
get called which cause the system cache invalidation and due to CCA setting,
wipe out rwstate->rs_new_rel->rd_smgr which wasn't restored for the
On Wed, Mar 3, 2021 at 7:56 PM Dilip Kumar wrote:
>
> On Wed, Mar 3, 2021 at 4:50 PM Amul Sul wrote:
> >
> > On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
> > >
> > Yes, it is possible to allow wal temporarily for itself by setting
> > Loca
On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
>
> On Tue, Mar 2, 2021 at 9:01 PM Dilip Kumar wrote:
>
> > >
> > > We don't want that to happen in cases where previous
> > > recovery-end-checkpoint is
> > > skipped in startup. We want Checkpointer first to convey the barrier to
> > > all
>
On Tue, Mar 2, 2021 at 5:52 PM Dilip Kumar wrote:
>
> On Fri, Feb 19, 2021 at 5:43 PM Amul Sul wrote:
> >
> > In the attached version I have made the changes accordingly what Robert has
> > summarised in his previous mail[1].
> >
> > In addition to tha
On Fri, Feb 5, 2021 at 11:53 AM Michael Paquier wrote:
>
> On Thu, Feb 04, 2021 at 12:58:29PM +0530, Dilip Kumar wrote:
> > Looks good to me.
>
> Rather than using the term "recovery state", I would just use
> SharedRecoveryState. This leads me to the attached.
Alright, that too looks good.
On Thu, Feb 4, 2021 at 6:18 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 3 Feb 2021 16:36:13 +0530, Amul Sul wrote in
> > On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote:
> > >
> > > On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote:
> > > >
> > &g
On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote:
>
> On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote:
> >
> > Hi,
> >
> > SharedRecoveryState member of XLogCtl is no longer a boolean flag, got
> > changes
> > in 4e87c4836ab9 to enum but, comment referri
Hi,
SharedRecoveryState member of XLogCtl is no longer a boolean flag, got changes
in 4e87c4836ab9 to enum but, comment referring to it still referred as the
boolean flag which is pretty confusing and incorrect.
Also, the last part of the same comment is as:
" .. although the boolean flag to
On Thu, Jan 7, 2021 at 12:45 PM Bharath Rupireddy
wrote:
>
> On Thu, Jan 7, 2021 at 11:32 AM Amul Sul wrote:
> > Snip from CreateCheckPoint():
> > --
> > /*
> > * Acquire CheckpointLock to ensure only one checkpoint happens at a time.
> > * (This is just pr
Hi ALL,
Snip from CreateCheckPoint():
--
/*
* Acquire CheckpointLock to ensure only one checkpoint happens at a time.
* (This is just pro forma, since in the present system structure there is
* only one process that is allowed to issue checkpoints at any given
* time.)
*/
On Mon, Dec 14, 2020 at 11:28 AM Amul Sul wrote:
>
> On Thu, Dec 10, 2020 at 6:04 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2020-12-09 16:13:06 -0500, Robert Haas wrote:
> > > That's not good. On a typical busy system, a system is going to be i
On Thu, Dec 10, 2020 at 6:04 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-12-09 16:13:06 -0500, Robert Haas wrote:
> > That's not good. On a typical busy system, a system is going to be in
> > the middle of a checkpoint most of the time, and the checkpoint will
> > take a long time to finish -
On Fri, 20 Nov 2020 at 9:53 PM, Robert Haas wrote:
> On Thu, Oct 8, 2020 at 6:23 AM Amul Sul wrote:
> > On a quick look at the latest 0001 patch, the following hunk to reset
> leftover
> > flags seems to be unnecessary:
> >
> > + /*
> > + * If some barrier
Hi,
On Mon, Oct 19, 2020 at 4:58 PM Amul Sul wrote:
>
> Hi,
>
> Assertion added in commits 6b2c4e59d016 is failing with following test:
>
> CREATE TABLE sales
> (
> prod_id int,
> prod_quantity int,
> sold_monthdate
> ) PARTITION BY RA
3372036854775807, isTopLevel=true, run_once=true,
dest=0x2dc1aa8, altdest=0x2dc1aa8, qc=0x7fff225f67c0) at pquery.c:779
#11 0x009389e8 in exec_simple_query (query_string=0x2dc07c0
"CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM
('2019-01-15') TO ('2019-02-15');") at postgres.c:1239
Regards,
Amul Sul
On Wed, Oct 7, 2020 at 11:19 PM Robert Haas wrote:
>
> On Wed, Sep 16, 2020 at 3:33 PM Robert Haas wrote:
> > I don't mind a loop, but that one looks broken. We have to clear the
> > bit before we call the function that processes that type of barrier.
> > Otherwise, if we succeed in absorbing
On Tue, Sep 29, 2020 at 1:58 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> Hello,
>
>
> We'd like to propose a feature to disable WAL to speed up data loading. This
> was inspired by a feature added in the latest MySQL. I wish you won't fear
> this feature...
>
TWIMW, pg_bulkload contrib
On Thu, Sep 10, 2020 at 2:33 AM Andres Freund wrote:
>
> Hi,
Thanks for your time.
>
> Thomas, there's one point below that could be relevant for you. You can
> search for your name and/or checkpoint...
>
>
> On 2020-09-01 16:43:10 +0530, Amul Sul wrote:
> >
On Sat, Aug 24, 2019 at 2:03 PM Kohei KaiGai wrote:
>
> 2019年8月24日(土) 7:02 Thomas Munro :
> >
> > On Fri, Aug 23, 2019 at 4:05 AM Kohei KaiGai wrote:
> > > We can consider the table join ptable X t1 above is equivalent to:
> > > (ptable_p0 + ptable_p1 + ptable_p2) X t1
> > > = (ptable_p0 X t1)
ffer(querybuf,
+ "SELECT public.bt_index_parent_check('%s'::regclass, %s, %s)",
+ idxoid,
+ settings.heapallindexed ? "true" : "false",
+ settings.rootdescend ? "true" : "false");
The assumption that the amcheck extension will be always inst
On Thu, Aug 20, 2020 at 8:00 AM Mark Dilger
wrote:
>
>
>
> > On Aug 16, 2020, at 9:37 PM, Amul Sul wrote:
> >
> > In addition to this, I found a few more things while reading v13 patch are
> > as
> > below:
> >
> > Patch v13-0001:
> >
>
On Thu, Jul 30, 2020 at 11:29 PM Robert Haas wrote:
>
> On Mon, Jul 27, 2020 at 1:02 PM Mark Dilger
> wrote:
> > Not at all! I appreciate all the reviews.
>
> Reviewing 0002, reading through verify_heapam.c:
>
> +typedef enum SkipPages
> +{
> + SKIP_ALL_FROZEN_PAGES,
> + SKIP_ALL_VISIBLE_PAGES,
On Fri, Jul 24, 2020 at 10:40 PM Soumyadeep Chakraborty <
soumyadeep2...@gmail.com> wrote:
> On Thu, Jul 23, 2020 at 10:14 PM Amul Sul wrote:
> >
> > On Fri, Jul 24, 2020 at 6:28 AM Soumyadeep Chakraborty <
> soumyadeep2...@gmail.com> wrote:
> > > In c
On Tue, Jul 21, 2020 at 2:32 AM Mark Dilger
wrote:
> []
> >
> > + StaticAssertStmt(InvalidOffsetNumber + 1 ==
> > FirstOffsetNumber,
> > +"InvalidOffsetNumber
> > increments to FirstOffsetNumber");
> >
> > If you are going to rely
On Fri, Jul 24, 2020 at 7:34 AM Andres Freund wrote:
>
> Hi,
Thanks for looking at the patch.
>
> > From f0188a48723b1ae7372bcc6a344ed7868fdc40fb Mon Sep 17 00:00:00 2001
> > From: Amul Sul
> > Date: Fri, 27 Mar 2020 05:05:38 -0400
> > Subject: [PATCH v3 2/6]
On Fri, Jul 24, 2020 at 6:28 AM Soumyadeep Chakraborty <
soumyadeep2...@gmail.com> wrote:
>
> On Thu, Jun 18, 2020 at 7:54 AM Robert Haas wrote:
> > I think we'd want the FIRST write operation to be the end-of-recovery
> > checkpoint, before the system is fully read-write. And then after that
> >
On Thu, Jul 23, 2020 at 6:08 AM Soumyadeep Chakraborty
wrote:
>
> Hi Amul,
>
Thanks, Soumyadeep for looking and putting your thoughts on the patch.
> On Tue, Jun 16, 2020 at 6:56 AM amul sul wrote:
> > The proposed feature is built atop of super barrier mechanism commit[1]
On Thu, Jul 23, 2020 at 4:34 AM SATYANARAYANA NARLAPURAM
wrote:
>
> +1 to this feature and I have been thinking about it for sometime. There are
> several use cases with marking database read only (no transaction log
> generation). Some of the examples in a hosted service scenario are 1/ when
On Thu, Jul 23, 2020 at 3:33 AM Soumyadeep Chakraborty
wrote:
>
> Hello,
>
> I think we should really term this feature, as it stands, as a means to
> solely stop WAL writes from happening.
>
True.
> The feature doesn't truly make the system read-only (e.g. dirty buffer
> flushes may succeed
On Tue, Jul 21, 2020 at 10:58 AM Amul Sul wrote:
>
> Hi Mark,
>
> I think new structures should be listed in src/tools/pgindent/typedefs.list,
> otherwise, pgindent might disturb its indentation.
>
> Regards,
> Amul
>
>
> On Tue, Jul 21, 202
Hi Mark,
I think new structures should be listed in src/tools/pgindent/typedefs.list,
otherwise, pgindent might disturb its indentation.
Regards,
Amul
On Tue, Jul 21, 2020 at 2:32 AM Mark Dilger
wrote:
>
>
>
> > On Jul 16, 2020, at 12:38 PM, Robert Haas wrote:
> >
> > On Mon, Jul 6, 2020 at
On Mon, Jul 13, 2020 at 8:35 PM Jehan-Guillaume de Rorthais
wrote:
>
> Hi,
>
> Another summary + patch + tests.
>
> This patch supports 2PC. The goal is to keep them safe during demote/promote
> actions so they can be committed/rollbacked later on a primary. See tests.
>
Wondering is it
On Wed, Jul 8, 2020 at 10:24 AM Fabien COELHO wrote:
>
>
> Hello Anastasia,
>
> My 0.02 €:
>
> > The patch implements following syntax:
> >
> > CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
> > partition_auto_create_clause
> >
> > where partition_auto_create_clause is
> >
> >
On Fri, Jul 3, 2020 at 1:32 PM Peter Eisentraut
wrote:
>
> On 2020-07-01 09:00, Amul Sul wrote:
> > Attached patch makes an adjustment to ipc.c code to be in the 80-column
> > window.
>
> I can see an argument that this makes the code a bit easier to read, but
> maki
On Wed, Jul 1, 2020 at 4:29 PM Bharath Rupireddy
wrote:
>
> changes look good to me.
Thanks for looking at the patch.
>
> one comment: instead of having block variables onexit, in the while
> loops in shmem_exit, can we have a single local variable defined at
> the start of the shmem_exit
Hi,
Attached patch makes an adjustment to ipc.c code to be in the 80-column
window.
Regards,
Amul
0001-cleanup-adjust-code-in-80-column-window.patch
Description: Binary data
On Fri, Jun 26, 2020 at 12:15 PM Michael Banck
wrote:
>
> Hi,
>
> On Wed, Jun 24, 2020 at 01:54:29PM +0530, tushar wrote:
> > On 6/22/20 11:59 AM, Amul Sul wrote:
> > > 2. Now skipping the startup checkpoint if the system is read-only mode, as
> > > discussed [
On Wed, Jun 24, 2020 at 1:54 PM tushar wrote:
>
> On 6/22/20 11:59 AM, Amul Sul wrote:
> > 2. Now skipping the startup checkpoint if the system is read-only mode, as
> > discussed [2].
>
> I am not able to perform pg_checksums o/p after shutting down my server
> in
On Thu, Jun 18, 2020 at 8:23 PM Robert Haas wrote:
>
> On Thu, Jun 18, 2020 at 5:55 AM Amit Kapila wrote:
> > For buffer replacement, many-a-times we have to also perform
> > XLogFlush, what do we do for that? We can't proceed without doing
> > that and erroring out from there means stopping
On Thu, Jun 18, 2020 at 3:25 PM Amit Kapila wrote:
>
> On Wed, Jun 17, 2020 at 8:12 PM Robert Haas wrote:
> >
> > On Wed, Jun 17, 2020 at 9:02 AM Amit Kapila wrote:
> > > Do we prohibit the checkpointer to write dirty pages and write a
> > > checkpoint record as well? If so, will the
On Wed, Jun 17, 2020 at 8:15 PM Robert Haas wrote:
>
> On Wed, Jun 17, 2020 at 9:51 AM tushar wrote:
> > 1) ALTER SYSTEM
> >
> > postgres=# alter system read only;
> > ALTER SYSTEM
> > postgres=# alter system reset all;
> > ALTER SYSTEM
> > postgres=# create table t1(n int);
> > ERROR: cannot
On Wed, Jun 17, 2020 at 8:12 PM Robert Haas wrote:
>
> On Wed, Jun 17, 2020 at 9:02 AM Amit Kapila wrote:
> > Do we prohibit the checkpointer to write dirty pages and write a
> > checkpoint record as well? If so, will the checkpointer process
> > writes the current dirty pages and writes a
On Fri, May 29, 2020 at 12:54 PM Fujii Masao
wrote:
>
>
> On 2020/05/27 16:10, Michael Paquier wrote:
> > On Tue, May 26, 2020 at 07:30:54PM +, Bossart, Nathan wrote:
> >> While an assertion in UpdateControlFile() would not have helped us
> >> catch the problem I initially reported, it does
On Thu, May 28, 2020 at 3:06 PM Amit Langote
wrote:
> On Thu, May 28, 2020 at 1:36 PM amul sul wrote:
> > On Wed, May 27, 2020 at 12:53 PM Amit Langote
> wrote:
> >> Actually, if you declare the cursor without FOR SHARE/UPDATE, the case
> >> would fail eve
On Wed, May 27, 2020 at 12:53 PM Amit Langote
wrote:
> On Fri, May 22, 2020 at 9:09 PM amul sul wrote:
> > I tried similar things on inherit partitioning as follow and that looks
> fine:
> >
> > DROP TABLE tbl;
> > CREATE TABLE tbl (c1 INT,c2 TEXT);
> > CRE
On Fri, May 22, 2020 at 5:00 PM Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> Hi All,
>
> I am getting ERROR when using the "FOR UPDATE" clause for the partitioned
> table. below is a reproducible test case for the same.
>
> CREATE TABLE tbl (c1 INT,c2 TEXT) PARTITION BY
On Wed, Apr 22, 2020 at 2:59 PM amul sul wrote:
>
>
> On Wed, Apr 22, 2020 at 2:27 PM David Rowley wrote:
>
>> On Wed, 22 Apr 2020 at 20:11, amul sul wrote:
>> >
>> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi <
>> rajkumar.
On Wed, Apr 22, 2020 at 2:27 PM David Rowley wrote:
> On Wed, 22 Apr 2020 at 20:11, amul sul wrote:
> >
> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi <
> rajkumar.raghuwan...@enterprisedb.com> wrote:
> >> #2 0x00acd16a in Exceptional
On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> Hi,
>
> Getting a server crash while creating partition table which have
> self-referencing foreign key
>
> postgres=# CREATE TABLE part1 (c1 int PRIMARY KEY, c2 int REFERENCES
> part1)
On Fri, Jan 24, 2020 at 11:31 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Fri, 6 Dec 2019 at 17:33, Kyotaro Horiguchi
> wrote:
> >
> > Hello.
> >
> > This is the reased (and a bit fixed) version of the patch. This
> > applies on the master HEAD and passes all provided
On Wed, Jan 29, 2020 at 4:34 PM vignesh C wrote:
> On Tue, Jan 21, 2020 at 11:22 AM Amit Kapila
> wrote:
> >
> > On Fri, Dec 6, 2019 at 11:24 AM vignesh C wrote:
> > >
[...]
>
> Thanks for your review and suggestion. I have made a patch based on
> similar lines. Attached patch has the doc
On Mon, Dec 9, 2019 at 3:08 PM amul sul wrote:
> Attached is the rebase version atop the latest master head(2d0fdfaccec).
>
>
Hi Fujita san,
I have been through your changes proposed in [1] -- the changes make sense
to me &
I didn't see any unobvious behaviour in testing as well.
On Sat, Nov 2, 2019 at 8:01 PM Tom Lane wrote:
> amul sul writes:
> > I wondered can we have a shortcut somewhat similar to following POC
> > in recomputeNamespacePath () when the recomputed path is the same as the
> > previous baseSearchPath/activeSearchPath :
Hi all,
I wondered can we have a shortcut somewhat similar to following POC
in recomputeNamespacePath () when the recomputed path is the same as the
previous baseSearchPath/activeSearchPath :
== POC patch ==
diff --git a/src/backend/catalog/namespace.c
b/src/backend/catalog/namespace.c
index
.es/m/CAPmGK145V8DNCNQ2gQBgNE3QqoJGjsmK5WMwaA3FMirNM723KQ%40mail.gmail.com
From c7f165b575fd984ca3053ce7162bdd8e4bf56be8 Mon Sep 17 00:00:00 2001
From: Amul Sul
Date: Thu, 24 Oct 2019 05:38:11 -0400
Subject: [PATCH] delta
Changes :
1. Call process_outer_partition & process_inner_partition
unconditi
On Wed, Sep 4, 2019 at 2:40 AM Alvaro Herrera
wrote:
> Fujita-san, amul,
>
> CFbot complains that Fujita-san submitted a patch that doesn't apply,
> which makes sense since the necessary previous patch was only referred
> to without being resubmitted. I suggest to always post all patches
>
Hi Fujita San,
Please find my comments inline below:
On Wed, Aug 28, 2019 at 3:52 PM Etsuro Fujita
wrote:
> On Fri, Aug 16, 2019 at 10:25 PM Etsuro Fujita
> wrote:
> >
[... skipped ..]
>
> About the attached:
>
> * The attached patch modified try_partitionwise_join() so that we call
>
Thank you Fujita San for the enhancement, will have a look.
Regards,
Amul
On Wed, Aug 28, 2019 at 3:52 PM Etsuro Fujita
wrote:
> On Fri, Aug 16, 2019 at 10:25 PM Etsuro Fujita
> wrote:
> > It seems that I performed the above tests on an assertion-enabled
> > build. :( So I executed the
On Sat, Aug 10, 2019 at 12:16 AM David Fetter wrote:
> On Thu, Aug 08, 2019 at 05:42:21PM +0900, Amit Langote wrote:
> > On Thu, Aug 8, 2019 at 5:33 PM amul sul wrote:
> > > On Thu, Aug 8, 2019 at 1:27 PM Amit Langote
> wrote:
> >
> > >> Thanks for
On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
> Hi Amul,
>
> On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
> >
> > Hi,
> >
> > In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> > bound info wasn't free at
On Mon, Jul 8, 2019 at 5:03 PM Etsuro Fujita
wrote:
> On Wed, Jul 3, 2019 at 3:44 PM Etsuro Fujita
> wrote:
> > On Tue, Jul 2, 2019 at 1:47 PM amul sul wrote:
> > > Attached version is rebase atop of the latest master head(c74d49d41c),
> thanks.
> >
> >
On Mon, Mar 11, 2019 at 8:29 AM Ashutosh Bapat
wrote:
> On Thu, Mar 7, 2019 at 8:20 PM amul sul wrote:
>
>>
>>
>> On Thu, Mar 7, 2019 at 1:02 PM amul sul wrote:
>>
>>> Thanks Rajkumar,
>>>
>>> I am looking into this.
>
Thanks Rajkumar,
I am looking into this.
Regards,
Amul
On Thu, Mar 7, 2019 at 11:54 AM Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
>
>
> On Tue, Mar 5, 2019 at 3:45 PM amul sul wrote:
>
>> Attached is the rebased atop of the latest master head(
You forgot to quote pg_toast_22345, try this:
psql -c " select * from pg_class where relname = 'pg_toast_22345' "
Regards,
Amul
On Fri, Feb 1, 2019 at 4:05 PM rajan wrote:
> postgres@Server2[DEV][backup] $ psql -c 'select * from pg_class where
> relname
> = pg_toast_22345'
> ERROR: column
On Mon, Nov 26, 2018 at 9:33 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Mon, Nov 26, 2018 at 1:41 PM Dmitry Dolgov <9erthali...@gmail.com>
> wrote:
> >
> > Thanks, I've messed this up too - rebased a wrong branch, the correct one
> > doesn't have this code already. Sorry for that, and
On Mon, Dec 17, 2018 at 12:20 PM amul sul wrote:
> On Mon, Dec 17, 2018 at 11:54 AM Michael Paquier
> wrote:
> >
> > On Mon, Dec 17, 2018 at 12:24:15AM -0500, Tom Lane wrote:
> > > If we were to rename the "foo.expr" column at this point,
> > > a
On Mon, Dec 17, 2018 at 1:57 PM Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 01:19:00PM +0530, amul sul wrote:
> > Laptop215:PG edb$ git --version
> > git version 2.14.1
>
> Using 2.20, git apply works fine for me but... If patch -p1 works, why
> not just usin
On Mon, Dec 17, 2018 at 1:04 PM Michael Paquier wrote:
>
> On Mon, Dec 17, 2018 at 12:49:03PM +0530, amul sul wrote:
> > On Mon, Dec 17, 2018 at 11:54 AM Michael Paquier
wrote:
> >> So this settles the argument that we had better not do anything before
> >> v11.
On Mon, Dec 17, 2018 at 11:54 AM Michael Paquier wrote:
>
> On Mon, Dec 17, 2018 at 12:24:15AM -0500, Tom Lane wrote:
> > If we were to rename the "foo.expr" column at this point,
> > and then dump and reload, the expression column in the
> > second index would presumably acquire the name "expr"
On Mon, Dec 17, 2018 at 10:44 AM Michael Paquier wrote:
>
> On Fri, Dec 14, 2018 at 08:08:45AM +, Amul Sul wrote:
> > dump-alter-index-stats-v2.patch looks pretty much reasonable to me, passing
> > on committer.
> >
> > The new status of this patch is: Ready
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
dump-alter-index-stats-v2.patch looks pretty much reasonable to me,
On Mon, Dec 10, 2018 at 2:51 PM rajan wrote:
>
> Thanks for the reply Amul.
>
> Btw, No my table does not has any index.
Thanks for the information.
Regards,
Amul
Apologize for delayed response.
On Mon, Dec 3, 2018 at 12:30 PM rajan wrote:
>
> Hello Amul,
>
> I have a doubt. Please find below the details,
>
> 1. autovacuum_vacuum_threshold and autovacuum_analyse_threshold are set at
> 300
> 2. autovacuum_vacuum_scale_factor and
On Wed, Nov 28, 2018 at 9:11 AM rajan wrote:
>
> Thanks, amul. I have already gone through this. What I would like to
> understand is the performance impact on autovacuum launcher and worker
> process when autovacuum is running from configurations done by
> *ALTER TABLE autvac_test SET
Hopefully, this[1] will help you.
1]
https://www.percona.com/blog/2018/08/10/tuning-autovacuum-in-postgresql-and-autovacuum-internals/
regards,
Amul
On Tue, Nov 27, 2018 at 11:50 AM rajan wrote:
>
> Hi,
>
> Please suggest me on the following,
>
> 1. Is it better to configure autovacuum
Thanks Tom for enhancing & committing these patches.
Regards,
Amul
On Sat, Nov 24, 2018 at 12:15 AM Tom Lane wrote:
>
> Andrew Gierth writes:
> > "Tomas" == Tomas Vondra writes:
> > Tomas> The important question is - can there be two different encodings
> > Tomas> for the same hstore value?
On Wed, Nov 21, 2018 at 10:34 AM Hironobu SUZUKI wrote:
>
> On 2018/09/26 11:20, amul sul wrote:
> > Hi all,
> >
> > Commit[1] has added 64-bit hash functions for core data types and in the
> > same
> > discussion thread[2] Robert Haas suggested to have th
On Thu, Oct 4, 2018 at 8:25 PM Alvaro Herrera wrote:
>
> On 2018-Oct-01, Rajkumar Raghuwanshi wrote:
>
> > On Tue, Sep 18, 2018 at 11:20 AM amul sul wrote:
> >
> > > Here is the complete patch proposes the aforesaid fix with regression
> > > test.
>
Hi all,
Commit[1] has added 64-bit hash functions for core data types and in the same
discussion thread[2] Robert Haas suggested to have the similar extended hash
function for hstore and citext data type. Attaching patch proposes the same.
Regards,
Amul
1]
On Thu, Sep 20, 2018, 3:22 AM Alexander Korotkov
wrote:
> On Wed, Sep 19, 2018 at 1:38 PM amul sul wrote:
> > On Wed, Sep 19, 2018 at 3:51 PM amul sul wrote:
> > >
> > > On Wed, Sep 19, 2018 at 2:57 PM Alexander Korotkov
> > [...]
> > >
> > >
On Wed, Sep 19, 2018 at 3:51 PM amul sul wrote:
>
> On Wed, Sep 19, 2018 at 2:57 PM Alexander Korotkov
[...]
>
> With this patch, to_date and to_timestamp behaving differently, see this:
>
> edb=# SELECT to_date('18 12 2011', 'xDDxMMx');
> to_date
>
On Wed, Sep 19, 2018 at 2:57 PM Alexander Korotkov
wrote:
>
> On Tue, Sep 18, 2018 at 4:42 PM Alexander Korotkov
> wrote:
> > But, I found related issue in cf9846724. Before it was:
> >
> > # select to_timestamp('2018 01 01', '9MM9DD');
> > to_timestamp
> >
>
On Mon, Sep 17, 2018 at 9:06 PM amul sul wrote:
>
> Nice catch Rajkumar.
>
> In index_check_primary_key(), relationHasPrimaryKey() called only for the an
> alter command but I think we need to call in this case as well, like this:
>
> diff --git a/src/backend/catalog/index.c
Nice catch Rajkumar.
In index_check_primary_key(), relationHasPrimaryKey() called only for the an
alter command but I think we need to call in this case as well, like this:
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 7eb3e35166..c8714395fe 100644
---
On Wed, Sep 5, 2018, 6:35 PM Alexander Korotkov
wrote:
> On Wed, Sep 5, 2018 at 3:10 PM amul sul wrote:
> > On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
> > wrote:
> > > On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
> > > wrote:
> > > > Fro
201 - 300 of 346 matches
Mail list logo
