On Sat, Jan 18, 2020 at 2:42 AM Alvaro Herrera wrote:
>
> On 2020-Jan-17, vignesh C wrote:
>
> > Thanks Dilip for reviewing.
> > I have fixed the comments you have suggested.
>
> I ended up rewording that comment completely; I thought the original was
> not explaining things well enough.
>
> I
On Sat, Jan 18, 2020 at 2:42 AM Alvaro Herrera wrote:
>
> On 2020-Jan-17, vignesh C wrote:
>
> > Thanks Dilip for reviewing.
> > I have fixed the comments you have suggested.
>
> I ended up rewording that comment completely; I thought the original was
> not explaining things well enough.
>
> I
On 2020-Jan-17, vignesh C wrote:
> Thanks Dilip for reviewing.
> I have fixed the comments you have suggested.
I ended up rewording that comment completely; I thought the original was
not explaining things well enough.
I also changed the comment for final_lsn in reorderbuffer.h: not only I
On Fri, Jan 17, 2020 at 7:42 AM vignesh C wrote:
>
> On Thu, Jan 16, 2020 at 9:17 AM Dilip Kumar wrote:
> >
> > One minor comment. Otherwise, the patch looks fine to me.
> > + /*
> > + * We set final_lsn on a transaction when we decode its commit or abort
> > + * record, but we never see those
On Thu, Jan 16, 2020 at 9:17 AM Dilip Kumar wrote:
>
> One minor comment. Otherwise, the patch looks fine to me.
> + /*
> + * We set final_lsn on a transaction when we decode its commit or abort
> + * record, but we never see those records for crashed transactions. To
> + * ensure cleanup of
On Tue, Dec 31, 2019 at 11:35 AM vignesh C wrote:
>
> On Mon, Dec 30, 2019 at 11:17 AM Amit Kapila wrote:
> >
> > On Fri, Dec 27, 2019 at 8:37 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Dec-27, vignesh C wrote:
> > >
> > > > I felt amit solution also solves the problem. Attached patch
On Mon, Dec 30, 2019 at 11:17 AM Amit Kapila wrote:
>
> On Fri, Dec 27, 2019 at 8:37 PM Alvaro Herrera
> wrote:
> >
> > On 2019-Dec-27, vignesh C wrote:
> >
> > > I felt amit solution also solves the problem. Attached patch has the
> > > fix based on the solution proposed.
> > > Thoughts?
> >
>
On Fri, Dec 27, 2019 at 8:37 PM Alvaro Herrera wrote:
>
> On 2019-Dec-27, vignesh C wrote:
>
> > I felt amit solution also solves the problem. Attached patch has the
> > fix based on the solution proposed.
> > Thoughts?
>
> This seems a sensible fix to me, though I didn't try to reproduce the
>
On 2019-Dec-27, vignesh C wrote:
> I felt amit solution also solves the problem. Attached patch has the
> fix based on the solution proposed.
> Thoughts?
This seems a sensible fix to me, though I didn't try to reproduce the
failure.
> @@ -2472,6 +2457,7 @@
On Tue, Dec 17, 2019 at 2:32 PM Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 11:13 AM vignesh C wrote:
> >
> >
> > It sets the final_lsn here so that it can iterate from the start_lsn
> > to final_lsn and cleanup the serialized files in
> > ReorderBufferRestoreCleanup function. One solution We
On Wed, Dec 11, 2019 at 11:13 AM vignesh C wrote:
>
>
> It sets the final_lsn here so that it can iterate from the start_lsn
> to final_lsn and cleanup the serialized files in
> ReorderBufferRestoreCleanup function. One solution We were thinking
> was to store the lsn of the last serialized
> I found couple of crashes in reorderbuffer while review/testing of
> logical_work_mem and logical streaming of large in-progress
> transactions. Stack trace of the same are given below:
> Issue 1:
> #0 0x7f985c7d8337 in raise () from /lib64/libc.so.6
> #1 0x7f985c7d9a28 in abort ()
On Sat, Nov 9, 2019 at 5:07 PM Amit Kapila wrote:
>
> On Fri, Nov 8, 2019 at 10:05 AM vignesh C wrote:
> >
> > On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> > > > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
>
On Fri, Nov 8, 2019 at 10:05 AM vignesh C wrote:
>
> On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> > > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
> > > wrote:
> > > >
> > > > I'm a bit confused - does this happen
On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
> > wrote:
> > >
> > > I'm a bit confused - does this happen only with the logical_work_mem
> > > patches, or with clean master too?
>
Hi,
On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
> wrote:
> >
> > I'm a bit confused - does this happen only with the logical_work_mem
> > patches, or with clean master too?
> >
>
> This occurs with the clean master. This is a base code problem
On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
wrote:
>
> I'm a bit confused - does this happen only with the logical_work_mem
> patches, or with clean master too?
>
This occurs with the clean master. This is a base code problem
revealed while doing stress testing of logical_work_mem patches.
--
On Thu, Nov 07, 2019 at 11:01:17AM +0530, Dilip Kumar wrote:
On Thu, Nov 7, 2019 at 9:55 AM vignesh C wrote:
On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote:
>
> On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote:
> >
> > Hi,
> >
> > ...
> >
> > Issue1 it seems like if all the reorderbuffer
On Thu, Nov 7, 2019 at 9:55 AM vignesh C wrote:
>
> On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote:
> >
> > On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote:
> > >
> > > Hi,
> > >
> > > I found couple of crashes in reorderbuffer while review/testing of
> > > logical_work_mem and logical
On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote:
>
> On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote:
> >
> > Hi,
> >
> > I found couple of crashes in reorderbuffer while review/testing of
> > logical_work_mem and logical streaming of large in-progress
> > transactions. Stack trace of the same
On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote:
>
> Hi,
>
> I found couple of crashes in reorderbuffer while review/testing of
> logical_work_mem and logical streaming of large in-progress
> transactions. Stack trace of the same are given below:
> Issue 1:
> #0 0x7f985c7d8337 in raise ()
21 matches
Mail list logo
