any
of the publication doesn't exist)
This applies for both CREATE and ALTER subscription commands.
--
With Regards,
Ashutosh Sharma.
On Sat, Nov 13, 2021 at 12:50 PM vignesh C wrote:
>
> On Wed, Nov 10, 2021 at 11:16 AM Bharath Rupireddy
> wrote:
> >
> > On T
On Wed, Feb 9, 2022 at 11:53 PM Euler Taveira wrote:
>
> On Wed, Feb 9, 2022, at 12:06 PM, Ashutosh Sharma wrote:
>
> Just wondering if we should also be detecting the incorrect conninfo
> set with ALTER SUBSCRIPTION command as well. See below:
>
> -- try creating a subscr
tion we do connect to the publisher node hence
the incorrect connection info gets detected. But that's not the case
with alter subscription.
--
With Regards,
Ashutosh Sharma.
On Sat, Nov 13, 2021 at 6:27 PM Bharath Rupireddy
wrote:
>
> On Sat, Nov 13, 2021 at 12:50 PM vignesh C wrote:
>
On Wed, Feb 9, 2022 at 1:14 PM Kyotaro Horiguchi
wrote:
>
> Hi, Ashutosh.
>
> At Tue, 8 Feb 2022 18:35:34 +0530, Ashutosh Sharma
> wrote in
> > Here are some of my review comments on the v11 patch:
>
> Thank you for taking a look on this.
>
> > -
On Tue, Feb 8, 2022 at 2:02 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-07 13:38:38 +0530, Ashutosh Sharma wrote:
> > Are you talking about this scenario - what if the logical replication
> > slot on the publisher is dropped, but is being referenced by the
&g
lt.Write;
+ (errmsg("replication terminated by
primary server on timeline %u at %X/%X.",
+ startpointTLI,
+
LSN_FORMAT_ARGS(LogstreamResult.Write;
Is this change really required? I don't see any issue with the
existing error m
subscribers (if any) as well?
--
With Regards,
Ashutosh Sharma.
On Sun, Feb 6, 2022 at 1:29 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-01-03 14:46:52 +0100, Peter Eisentraut wrote:
> > From ec00dc6ab8bafefc00e9b1c78ac9348b643b8a87 Mon Sep 17 00:00:00 2001
> > From: Peter Eise
ge? I'm trying to think why users
> would want to sync logical slots to a reader but not have that be dropped
> as well if it's no longer present.
>
AFAIU this should be taken care of by the background worker used to
synchronize the replication slot.
--
With Regards,
Ashutosh Sharma.
On Wed, Dec 22, 2021 at 5:06 PM Dilip Kumar wrote:
>
> On Wed, Dec 22, 2021 at 4:26 PM Ashutosh Sharma wrote:
>
> >> Basically, ALTER TABLE SET TABLESPACE, will register the
> >> SYNC_UNLINK_REQUEST for the table files w.r.t the old tablespace, but
> >> tho
On Wed, Dec 22, 2021 at 2:44 PM Dilip Kumar wrote:
> On Tue, Dec 21, 2021 at 11:10 AM Ashutosh Sharma
> wrote:
> >
> > I am getting the below error when running the same test-case that Neha
> shared in her previous email.
> >
> > ERROR: 55000: some relation
On Wed, Dec 22, 2021 at 7:20 AM Dilip Kumar wrote:
> On Wed, 22 Dec 2021 at 12:28 AM, Ashutosh Sharma
> wrote:
>
>>
>> Is it okay to share the same tablespace (infact relfile) between the
>> primary and standby server? Perhaps NO.
>>
>
>>
Hi Dilip,
On Tue, Dec 21, 2021 at 11:10 AM Ashutosh Sharma
wrote:
> I am getting the below error when running the same test-case that Neha
> shared in her previous email.
>
> ERROR: 55000: some relations of database "test1" are already in
> tablespace "tab1&quo
*/
register_unlink_segment(rnode, forkNum, 0 /* first seg */ );
}
==
Is it okay to share the same tablespace (infact relfile) between the
primary and standby server? Perhaps NO.
--
With Regards,
Ashutosh Sharma.
On Tue, Dec 21, 2021 at 4:47 PM Dilip Kumar wrote:
> While testi
On Mon, Dec 20, 2021 at 7:04 PM Amit Langote
wrote:
> Hi,
>
> On Mon, Dec 13, 2021 at 11:37 PM Ashutosh Sharma
> wrote:
> >
> > Hi,
> >
> > Is this okay?
> >
> > postgres=# CREATE TABLE t1 (a int, b int) PARTITION BY LIST ( a, a, a );
>
ust move them back to the database's
default tablespace before using this command.")));
}
Also, if I run the checkpoint explicitly before executing the above alter
database statement, this error doesn't appear which means it only happens
with the new changes because earlier we were doing th
s inside this LocalPgBackendStatus structure are prefixed
with "backend" word. Can we do the same for the newly added variables as
well?
--
+ * Get the xid and xmin, nsubxid and overflow status of the backend.
The
Should this be put as - "xid, xmin, nsubxid and overflow" i
the source. please check.
--
With Regards,
Ashutosh Sharma.
On Mon, Dec 6, 2021 at 7:27 PM Nitin Jadhav
wrote:
> Thank you for reviewing the patch.
>
> > partbounds.c: In function ‘get_qual_for_list.isra.18’:
> > partbounds.c:4284:29: warning: ‘boundinfo’ may be used uninit
de.spcNode = srcrnode.spcNode;;
There is an extra semicolon here.
--
With Regards,
Ashutosh Sharma.
On Sun, Dec 12, 2021 at 1:39 PM Dilip Kumar wrote:
> On Fri, Dec 10, 2021 at 7:39 AM Ashutosh Sharma
> wrote:
> >>
> >> Logfile Snippet:
> >> 2021-12-09 17:49:18.110 +04 [
Hi Thomas,
I am unable to apply these new set of patches on HEAD. Can you please share
the rebased patch or if you have any work branch can you please point it
out, I will refer to it for the changes.
--
With Regards,
Ashutosh sharma.
On Tue, Nov 23, 2021 at 3:44 PM Thomas Munro wrote
On Thu, Dec 9, 2021 at 7:23 PM Neha Sharma
wrote:
> On Thu, Dec 9, 2021 at 11:12 AM Ashutosh Sharma
> wrote:
>
>> Hi,
>>
>> The issue here is that we are trying to create a table that exists inside
>> a non-default tablespace when doing ALTER DATABASE.
ch and let me know if it
looks fine or not?
Neha, can you please re-run the test-cases with the attached patch.
Thanks,
--
With Regards,
Ashutosh Sharma.
On Thu, Dec 9, 2021 at 8:43 AM Neha Sharma
wrote:
>
>
>
> On Thu, Dec 9, 2021 at 4:26 AM Greg Nancarrow wrote:
>
>> On T
Thanks Robert for sharing your thoughts.
On Mon, Dec 6, 2021 at 11:16 PM Robert Haas wrote:
> On Mon, Dec 6, 2021 at 9:23 AM Ashutosh Sharma
> wrote:
> > One last point - If we try to clone a huge database, as expected CREATE
> DATABASE emits a lot of WALs, causing a lot
.
--
With Regards,
Ashutosh Sharma.
On Mon, Dec 6, 2021 at 9:59 AM Dilip Kumar wrote:
> On Mon, Dec 6, 2021 at 9:17 AM Ashutosh Sharma
> wrote:
> >
> > Here are few more review comments:
>
> Thanks for reviewing it.
>
> > 1) It seems that we are not freeing
sistence == RELPERSISTENCE_PERMANENT || copying_initfork);
--
With Regards,
Ashutosh Sharma.
On Mon, Dec 6, 2021 at 9:12 AM Ashutosh Sharma
wrote:
> On Fri, Dec 3, 2021 at 8:28 PM Dilip Kumar wrote:
>
>> On Fri, Dec 3, 2021 at 7:38 PM Ashutosh Sharma
>> wrote:
>> >
>> > I see that
On Fri, Dec 3, 2021 at 8:28 PM Dilip Kumar wrote:
> On Fri, Dec 3, 2021 at 7:38 PM Ashutosh Sharma
> wrote:
> >
> > I see that this patch is reducing the database creation time by almost
> 3-4 times provided that the template database has some user data in it.
> H
you intentionally skipped pg_internal.init file from being copied to
the target database?
--
With Regards,
Ashutosh Sharma.
On Thu, Dec 2, 2021 at 7:20 PM Dilip Kumar wrote:
> On Wed, Dec 1, 2021 at 6:04 PM Dilip Kumar wrote:
>
> > Thanks a lot for testing this. From the err
nning server, but they would not be written to the
> server log.
>
That's a good idea. How about also adding some GUC(s) to the log archive,
recovery related log messages just like we have for checkpoints, autovacuum
etc? Maybe something like log_archive, log_recovery etc.
--
With Regards,
Ashutosh Sharma.
On Thu, Sep 30, 2021 at 7:45 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Thu, Sep 30, 2021 at 3:37 PM Ashutosh Sharma
> wrote:
> >
> > Hi All,
> >
> > While working on one of the internal projects I noticed that currently
> in
On Thu, Sep 30, 2021 at 8:40 PM Mark Dilger
wrote:
>
>
> > On Sep 30, 2021, at 3:07 AM, Ashutosh Sharma
> wrote:
> >
> > While working on one of the internal projects I noticed that currently
> in Postgres, we do not allow normal users to alter attributes of the
name to refusr;
ALTER ROLE
nonsu@postgres=> drop user refusr;
DROP ROLE
nonsu@postgres=> create user repusr2 with password 'repusr2' replication;
ERROR: 42501: must be superuser to create replication users
--
With Regards,
Ashutosh Sharma.
On Fri, Oct 30, 2020 at 8:49 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> At Fri, 30 Oct 2020 06:13:53 +0530, Ashutosh Sharma
> wrote in
> > Hi All,
> >
> > Today while working on some other task related to database encoding, I
> > noticed that the MINUS SI
in SJIS represents MINUS
SIGN in SJIS which means the MINUS SIGN in UTF8 got converted to the
MINUS SIGN in SJIS and that is what we expect. Isn't it?
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Fri, Oct 23, 2020 at 5:42 PM Ashutosh Sharma wrote:
>
> Hi Vignesh,
>
> Thanks for the updated patches. Here are some more comments that I can
> find after reviewing your latest patches:
>
> +/*
> + * This structure helps in storing the common data from CopyStateData th
how a brief description
about parallel vacuum has been added in the vacuumlazy.c file.
* Lazy vacuum supports parallel execution with parallel worker processes. In
* a parallel vacuum, we perform both index vacuum and index cleanup with
* parallel worker processes. Individual indexes a
On Mon, Sep 28, 2020 at 3:01 PM Amit Kapila wrote:
>
> On Tue, Sep 22, 2020 at 2:44 PM vignesh C wrote:
> >
> > Thanks Ashutosh for your comments.
> >
> > On Wed, Sep 16, 2020 at 6:36 PM Ashutosh Sharma
> > wrote:
> > >
> > > Hi Vignesh,
On Fri, Sep 25, 2020 at 8:12 AM Amit Kapila wrote:
>
> On Thu, Sep 24, 2020 at 6:33 PM Ashutosh Sharma wrote:
> >
> > Hi Amit,
> >
> > > Here, I think instead of using MySubscription->stream, we should use
> > > server/walrecv version number as we use
gs being UTF-8.
>
Thanks Bharath for the testing. The results look impressive.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
start streaming changes for the in-progress
transactions even if the streaming was disabled while creating the
subscription, won't it?
Please let me know if I am missing something here.
Thanks,
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Tue, Sep 22, 2020 at 12:22 PM Ashutosh Sharma wrote:
>
> On Tue, Sep 22, 2020 at 12:02 PM Amit Kapila wrote:
> >
> > On Tue, Sep 22, 2020 at 8:34 AM Ashutosh Sharma
> > wrote:
> > >
> > > On Mon, Sep 21, 2020 at 6:58 PM Amit Kapila
> > >
On Tue, Sep 22, 2020 at 12:02 PM Amit Kapila wrote:
>
> On Tue, Sep 22, 2020 at 8:34 AM Ashutosh Sharma wrote:
> >
> > On Mon, Sep 21, 2020 at 6:58 PM Amit Kapila wrote:
> > >
> > > On Mon, Sep 21, 2020 at 6:27 PM Ashutosh Sharma
> > > wrote:
>
On Mon, Sep 21, 2020 at 6:58 PM Amit Kapila wrote:
>
> On Mon, Sep 21, 2020 at 6:27 PM Ashutosh Sharma wrote:
> >
> > Thanks Dilip for the patch. AFAIU, the fix looks good. One small comment:
> >
>
> Thanks Ashutosh and Dilip for working on this. I'll look into
pport protocol %d or lower",
data->protocol_version, LOGICALREP_PROTO_VERSION_NUM)));
Other than this, I don't have any comments.
On Mon, Sep 21, 2020 at 5:34 PM Dilip Kumar wrote:
>
> On Mon, Sep 21, 2020 at 4:15 PM Dilip Kumar wrote:
> >
> > On Mon, Sep 21,
replication happens)
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
llow automated testing
> of this scenario, along the lines I sketched yesterday. This
> test passes if you run the two scripts serially, but not when
> you run them in parallel. I'm not proposing this for commit;
> it's a hack and its timing behavior is probably not stable enough
> for the buildfarm. But it's pretty useful for poking at these
> issues.
>
Yeah, understood, thanks for sharing this.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
t;
Looks good to me too.
Thanks,
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
CHUNK_COUNT 50
You may see these kinds of errors at other places as well if you scan
through your patch.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Wed, Aug 19, 2020 at 11:51 AM vignesh C wrote:
>
> Thanks Greg for reviewing the patch. Please find my thoughts
On Wed, Sep 16, 2020 at 10:40 AM Ashutosh Sharma wrote:
>
> On Wed, Sep 16, 2020 at 9:14 AM Tom Lane wrote:
> >
> > Ashutosh Sharma writes:
> > > On Wed, Sep 16, 2020 at 1:25 AM Tom Lane wrote:
> > >> * Should any of the other tables in the test be conv
On Wed, Sep 16, 2020 at 9:14 AM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > On Wed, Sep 16, 2020 at 1:25 AM Tom Lane wrote:
> >> * Should any of the other tables in the test be converted to temp?
>
> > Are you trying to say that we can achieve the things being
On Wed, Sep 16, 2020 at 1:25 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Sep 14, 2020 at 6:26 AM Ashutosh Sharma
> > wrote:
> >> Thanks for reporting. I'm able to reproduce the issue by creating some
> >> delay just before "-- n
inter" and use the
delay to start a new session either with repeatable read or
serializable transaction isolation level and run some query on the
test table. To fix this, as you suggested I've converted the test
table to the temp table. Attached is the patch with the changes.
Please hav
ion find_tids_one_page should state the
requirement that the tids array must be sorted.
> >
>
> Okay, will add a comment for this.
>
Added a comment for this in the attached patch.
Please have a look into the attached patch for the changes and let me know
for any other concern
On Thu, Aug 27, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 27, 2020 at 5:37 AM Ashutosh Sharma wrote:
> > While reviewing the patch for pg_surgery contrib module - [1], Asim
> > Praveen suggested that it would be better to replace the check for
> > access met
ate the
> requirement that the tids array must be sorted.
>
Okay, will add a comment for this.
>
> The heap_force_common function contains multiple ereport(NOTICE,...) within a
> critical section. I don't think that is normal practice. Can those reports
> be buffered until after the critical section is exited? You also have a
> CHECK_FOR_INTERRUPTS within the critical section.
>
This has been fixed in the v9 patch.
> [1] https://commitfest.postgresql.org/29/2700/
> —
Thanks for adding a commitfest entry for this.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Fri, Aug 28, 2020 at 1:44 AM Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 10:26 PM Ashutosh Sharma
> wrote:
> > Okay, point noted.
>
> I spent some time today working on this patch. I'm fairly happy with
> it now and intend to commit it if nobody sees a big
se types of questions are not for hackers
mailing-list. These are configuration related issues and should
probably be raised in pgsql-general mailing list
(pgsql-general.postgresql.org).
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
ar changes in these
contrib modules also.
Thoughts?
[1] -
https://www.postgresql.org/message-id/1D56CEFD-E195-4E6B-B870-3383E3E8C65E%40vmware.com
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
In addition to what Thomas said, I would also recommend you to refer
to the description of --with-libxml command line option provided in
the postgres installation-procedure page - [1].
[1] - https://www.postgresql.org/docs/12/install-procedure.html
--
With Regards,
Ashutosh Sharma
On Wed, Aug 26, 2020 at 9:19 PM Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 7:36 AM Ashutosh Sharma wrote:
> > Removed this note from the documentation and added a note saying: "The
> > user needs to ensure that they do not operate pg_force_freeze function
> &g
ICT;
>
> I think these functions should be PARALLEL UNSAFE.
>
By default the functions are marked PARALLEL UNSAFE, so I think there
is nothing to do here.
Attached patch with above changes.
This patch also takes care of all the other review comments from - [1].
[1] -
https://www.postgresql.
s in
heap_force_freeze to identify the deleted tuples and maybe skip such
tuples. So, yeah, I will do the code changes for handling this and
remove the note added in the documentation. Thank you Robert and
Masahiko-san for pointing this out.
[1] -
https://www.postgresql.org/message-id/CA%2BTgm
Hi Masahiko-san,
Thank you for the review. Please check my comments inline below:
On Tue, Aug 25, 2020 at 1:39 PM Masahiko Sawada
wrote:
>
> On Fri, 21 Aug 2020 at 22:25, Ashutosh Sharma wrote:
> >
> > Hi Masahiko-san,
> >
> > Please find the updated patch
On Mon, Aug 24, 2020 at 11:00 PM Andrey M. Borodin wrote:
>
> Hi!
>
> > 21 авг. 2020 г., в 18:24, Ashutosh Sharma
> > написал(а):
> >
> > Please find the updated patch with the following new changes:
>
> Do you have plans to support pg_surgery as externa
ption as soon as
> > the XID counter advances sufficiently.
>
> +1.
>
This has been taken care of in the latest v7 patch.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
know for any other concern.
Thanks,
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Thu, Aug 20, 2020 at 11:43 AM Ashutosh Sharma wrote:
>
> On Thu, Aug 20, 2020 at 11:04 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 19 Aug 2020 at 20:45, A
On Thu, Aug 20, 2020 at 11:04 AM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 20:45, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma
> > &g
On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma
> >
On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
wrote:
>
> On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma wrote:
> >
> > > pg_force_freeze() can revival a tuple that is already deleted but not
> > > vacuumed yet. Therefore, the user might need to reindex indexes a
On Tue, Aug 18, 2020 at 9:44 PM Alvaro Herrera wrote:
>
> On 2020-Aug-17, Ashutosh Sharma wrote:
>
> > > + if (heap_force_opt == HEAP_FORCE_KILL)
> > > + ItemIdSetDead(itemid);
> > >
> > > I think that if the page is an a
Attached is the new version of patch that addresses the comments from
Asim Praveen and Masahiko-san. It also improves the documentation to
some extent.
On Tue, Aug 18, 2020 at 1:46 PM Ashutosh Sharma wrote:
>
> Hello Masahiko-san,
>
> I've spent some more time trying to underst
PT_TERNARY_DISABLED)
nkeep += 1;
else
tupgone = true; /* we can delete the tuple */
..
..
}
So, the point is, would HeapTupleIsHotUpdated() ever be true?
--
With Regards,
Ashutosh Sharm
its ctid still has special values:
> MovedPartitionsOffsetNumber and MovedPartitionsBlockNumber. I don't
> see a problem yet caused by a visible tuple having the special ctid
> value, but it might be worth considering either to reset ctid value as
> well or to not freezing already-deleted tuple.
>
For this as well, the answer remains the same as above.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
ering if we should be doing similar changes
in other contrib modules (like pgrowlocks, pageinspect and
pgstattuple) as well?
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
Thanks Robert for the review. Please find my comments inline below:
On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> > Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
>
> Compiler warning:
On Tue, Aug 11, 2020 at 7:33 PM Robert Haas wrote:
>
> On Tue, Aug 11, 2020 at 3:39 AM Ashutosh Sharma wrote:
> > The other two messages for reporting unused items and dead items
> > remain the same. Hence, with above change, we would be reporting the
> > following 4
On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> There's a certain inconsistency to these messages:
>
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# insert into foo values (1);
> INS
these functions on the same tuple repeatedly and see the
behaviour.
...
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Thu, Aug 6, 2020 at 2:25 PM Rajkumar Raghuwanshi
wrote:
>
> I have been doing some user-level testing of this feature, apart from sanity
On Thu, Aug 6, 2020 at 9:19 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 2:11 AM Ashutosh Sharma wrote:
> > Okay, If you want I can remove the restriction on a toast table, but,
> > then that means a user can directly remove the data chunks from the
> > toast table w
not.
3) Declare some of the variables such as buf, page inside of the do
loop instead of declaring them at the top of heap_force_common
function.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Thu, Aug 6, 2020 at 2:49 PM Masahiko Sawada
wrote:
>
> On Thu, 6 A
Hello Masahiko-san,
Thanks for looking into the patch. Please find my comments inline below:
On Thu, Aug 6, 2020 at 1:42 PM Masahiko Sawada
wrote:
>
> On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
> > Please check the attached patch for the changes.
>
> I also look
On Thu, Aug 6, 2020 at 1:29 AM Robert Haas wrote:
>
> On Wed, Aug 5, 2020 at 9:42 AM Ashutosh Sharma wrote:
> > Yeah, it's being tested on the main table, not on a toast table. I've
> > removed this test-case and also restricted direct access to the toast
> > table usin
On Thu, Aug 6, 2020 at 1:04 AM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 12:13 PM Ashutosh Sharma wrote:
> > If the above path is taken that means none of the items in the page
> > got changed.
>
> Oops. I didn't realize that, sorry. Maybe it would be a little more
&g
Hi Robert,
Thanks for the review. Please find my comments inline:
On Sat, Aug 1, 2020 at 12:18 AM Robert Haas wrote:
>
> On Fri, Jul 31, 2020 at 8:52 AM Ashutosh Sharma wrote:
> > Attached is the new version of patch that addresses the comments from
> > Andrey and Been
On Mon, Aug 3, 2020 at 7:06 PM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma wrote:
> > Could you please explain this point once more in detail? I am not quite
> > able to understand under what circumstances a buffer would be modified, but
> >
en for it.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
Attached is the new version of patch that addresses the comments from
Andrey and Beena.
On Wed, Jul 29, 2020 at 10:07 AM Ashutosh Sharma
wrote:
> Hi Beena,
>
> Thanks for the review.
>
> 1. We would be marking buffer dirty and writing wal even if we have
>> not done any c
On Wed, Jul 29, 2020 at 9:58 AM Ashutosh Sharma
wrote:
>
> > I think we should let VACUUM do that.
>> Sometimes VACUUM will not get to these pages, because they are marked All
>> Frozen.
>> An possibly some tuples will get stale on this page again
>>
ns contain the word "Force" in it.
> 2. extension comment pg_surgery.control "extension to perform surgery
> the damaged heap table" -> "extension to perform surgery on the
> damaged heap table"
>
Okay, will fix that typo.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
that the operations
like vacuum, pg_dump/restore succeeds. It's users responsibility to
identify the corrupted data and pass its tid to either of these functions
as per the requirement.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
ions of these functions. But I do not
> recall exact rationale..
> Also, I'd be happy if we had something like "Restore this tuple iff this
> does not break unique constraint". To do so we need to sort tids by
> xmin\xmax, to revive most recent data first.
>
I d
know your feedback. Thank you.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Thu, Jul 16, 2020 at 9:44 PM Robert Haas wrote:
> On Thu, Jul 16, 2020 at 10:00 AM Robert Haas
> wrote:
> > I see your point, though: the tuple has to be able to survive
>
t; > On Fri, Jul 17, 2020 at 7:18 PM Ashutosh Sharma
> wrote:
> > >
> > > Some review comments (mostly) from the leader side code changes:
> > >
> > > 3) Should we allow Parallel Copy when the insert method is
> CIM_MULTI_CONDITIONAL?
> > >
&g
ine beaks* which
possibly means line breaks. This is applicable for other comments as well
where you
7) Is the following checking equivalent to IsWorker()? If so, it would be
good to replace it with an IsWorker like macro to increase the readability.
(IsParallelCopy() && !IsLeader())
--
With
hes as of
now. I will do that whenever possible. Thank you.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Fri, Jun 12, 2020 at 11:01 AM vignesh C wrote:
> On Thu, Jun 4, 2020 at 12:44 AM Andres Freund wrote
> >
> >
> > Hm. you don't explicitly men
Sharma
EnterpriseDB:http://www.enterprisedb.com
On Sat, Jun 13, 2020 at 9:42 AM Amit Kapila wrote:
> On Fri, Jun 12, 2020 at 4:57 PM Ashutosh Sharma
> wrote:
> >
> > Hi All,
> >
> > I've spent little bit of time going through the project discussion that
>
.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Fri, Jun 12, 2020 at 11:01 AM vignesh C wrote:
> On Thu, Jun 4, 2020 at 12:44 AM Andres Freund wrote
> >
> >
> > Hm. you don't explicitly mention that in your design, but given how
> > small the bene
On Sat, Jan 4, 2020 at 2:09 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Wed, Jan 1, 2020 at 10:50 AM Ashutosh Sharma
> > wrote:
> >> I know this is expected to happen considering the changes done in
> >> above commit because from this commit onwards,
provides the structure to the record
variable being written because having non-null tuple descriptor allows the
creation of an expanded object for the record variable eventually giving it
a structure.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Wed, Jan 1, 2020 at 9
behaviour change as a side effect of
the improvement done in the RECORD type of variable?
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Fri, Dec 27, 2019 at 9:20 AM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > Okay. Thanks for that fix. You've basically forced
> > revalidate_rectypeid() to update the PLpgSQL_rec's rectypeid
> > irrespective of typcache entry requires re-validation or not.
&g
On Fri, Dec 27, 2019 at 1:59 AM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > The issue here is that PLpgSQL_rec structure being updated by
> > revalidate_rectypeid() is actually a local/duplicate copy of the
> > PLpgSQL_rec structure available in
101 - 200 of 282 matches
Mail list logo
