On Mon, Dec 16, 2019 at 8:53 AM Amit Kapila wrote:
>
> On Sun, Dec 15, 2019 at 8:51 AM Robert Haas wrote:
> >
> > On Thu, Dec 12, 2019 at 9:23 PM Amit Kapila wrote:
> > > Do you think we need such an Assert after having StaticAssert for
> > > (THRESHOLD_SUBTRANS_CLOG_OPT <=
On Sun, Dec 15, 2019 at 8:51 AM Robert Haas wrote:
>
> On Thu, Dec 12, 2019 at 9:23 PM Amit Kapila wrote:
> > Do you think we need such an Assert after having StaticAssert for
> > (THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUBXIDS) and then
> > an if statement containing (nsubxids <=
On Thu, Dec 12, 2019 at 9:23 PM Amit Kapila wrote:
> Do you think we need such an Assert after having StaticAssert for
> (THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUBXIDS) and then
> an if statement containing (nsubxids <= THRESHOLD_SUBTRANS_CLOG_OPT)
> just before this Assert? Sure, we
On Thu, Dec 12, 2019 at 8:44 PM Robert Haas wrote:
>
> On Tue, Dec 10, 2019 at 4:32 PM Andres Freund wrote:
> > and then, within an if():
> >
> > /*
> > * We don't try to do group update optimization if a
> > process has
> > * overflowed the
On Tue, Dec 10, 2019 at 4:32 PM Andres Freund wrote:
> and then, within an if():
>
> /*
> * We don't try to do group update optimization if a process
> has
> * overflowed the subxids array in its PGPROC, since in that
> case we
>
On 2019-Dec-12, Amit Kapila wrote:
> On Thu, Dec 12, 2019 at 6:10 PM Alvaro Herrera
> wrote:
> > The more I look at both these asserts, the less sense they make. Why
> > does clog.c care about PGPROC at all?
>
> It is mainly for group updates. Basically, we want to piggyback the
> procs
On Thu, Dec 12, 2019 at 6:10 PM Alvaro Herrera wrote:
>
> On 2019-Dec-11, Amit Kapila wrote:
>
> > On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
>
> > > /*
> > > * We don't try to do group update
On 2019-Dec-11, Amit Kapila wrote:
> On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> > /*
> > * We don't try to do group update optimization if a
> > process has
> > * overflowed the
On Wed, Dec 11, 2019 at 11:00 AM Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> >
> > > /*
> > > * Overflowed transactions should not use group XID status update
> > > * mechanism.
> > > */
> > >
On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
>
> > /*
> > * Overflowed transactions should not use group XID status update
> > * mechanism.
> > */
> > Assert(!pgxact->overflowed);
> >
> > A solution could be either we remove this assert
On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
>
> Hi,
>
> Amit, Robert, IIRC that's mostly your feature?
>
I will look into this today.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Hi,
Amit, Robert, IIRC that's mostly your feature?
On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> While testing, my colleague Vignesh has hit an assert in
> TransactionGroupUpdateXidStatus. But that is not reproducible. After
> some analysis and code review, I have found the reason for the
While testing, my colleague Vignesh has hit an assert in
TransactionGroupUpdateXidStatus. But that is not reproducible. After
some analysis and code review, I have found the reason for the same.
As shown in the below code, there is an assert in
TransactionGroupUpdateXidStatus, which assumes
13 matches
Mail list logo
