| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: COPY FROM crash |
| Date: | 2024-07-30 05:37:11 |
| Message-ID: | CALdSSPgKKoG5xkcjdj4fGqD-d0GOVcm+0o1LsGNA=91KwyjwZQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
On Tue, 30 Jul 2024 at 08:52, Zhang Mingli <zmlpostgres(at)gmail(dot)com> wrote:
>
> Hi, all
>
> I got a crash when copy partition tables with mass data in Cloudberry DB[0](based on Postgres14.4, Greenplum 7).
>
> I have a test on Postgres and it has the similar issue(different places but same function).
Just to be clear, you are facing this on HEAD, on on REL_14_STABLE?
> However it’s a little hard to reproduce because it happened when inserting next tuple after a previous copy multi insert buffer is flushed.
>
> To reproduce easily, change the Macros to:
>
> #define MAX_BUFFERED_TUPLES 1
> #define MAX_PARTITION_BUFFERS 0
This way it's harder to believe that the problem persists with the
original settings. Are these values valid?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sutou Kouhei | 2024-07-30 05:47:34 | Re: Separate HEAP WAL replay logic into its own file |
| Previous Message | David Rowley | 2024-07-30 05:35:36 | Re: COPY FROM crash |