From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reorderbuffer crash during recovery |
Date: | 2019-11-08 04:34:56 |
Message-ID: | CALDaNm3vTknLVkmYzBNyizWCb5DKCY0rnb0Oxg3-iiQ=KZfBhQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, Nov 7, 2019 at 10:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
> > <tomas(dot)vondra(at)2ndquadrant(dot)com> 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.
>
> As far as I can tell there are no repro steps included? Any chance to
> get those?
>
This problem does not occur consistently. When I was reviewing and testing
"logical streaming for large in-progress transactions" link [1] I found the
crashes.
This issue does not occur directly, meaning this issue will occur only when
some crash occurs in postgres process(not from reorderbuffer but due to
some other issue), after the original non-reorderbuffer crash this
reorderbuffer crash appears.
To simplify the reorderbuffer crash, I used the following steps:
1) Make replication setup with publisher/subscriber for some table
2) Prepare a sql file with the below:
begin;
4096 insert statements;
select pg_sleep(120)
3) Execute the above script.
4) Attach the postgres process when pg_sleep is in progress.
5) call abort() from attached gdb.
6) After sometime there will be many core files in publisher installation
data directory.
[1] https://commitfest.postgresql.org/25/1927/
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
On Thu, Nov 7, 2019 at 10:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2019-11-07 17:03:44 +0530, Amit Kapila wrote:
> > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra
> > <tomas(dot)vondra(at)2ndquadrant(dot)com> 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.
>
> As far as I can tell there are no repro steps included? Any chance to
> get those?
>
> Greetings,
>
> Andres Freund
>
From | Date | Subject | |
---|---|---|---|
Next Message | nemo | 2019-11-08 06:59:24 | pg_dump: error: schema with OID 7956828 does not exist |
Previous Message | Ryan Lambert | 2019-11-07 22:04:38 | EXPLAIN ANALYZE not displaying recheck condition |
From | Date | Subject | |
---|---|---|---|
Next Message | imai.yoshikazu@fujitsu.com | 2019-11-08 04:35:30 | RE: Planning counters in pg_stat_statements (using pgss_store) |
Previous Message | Andrey Lepikhov | 2019-11-08 04:33:35 | Re: pg_waldump and PREPARE |