From: | Damir Belyalov <dam(dot)bel07(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Danil Anisimow <anisimow(dot)d(at)gmail(dot)com>, "HukuToc(at)gmail(dot)com" <HukuToc(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, "a(dot)lepikhov(at)postgrespro(dot)ru" <a(dot)lepikhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Date: | 2023-02-06 05:00:27 |
Message-ID: | CALH1LgsbWZWS3qMxdGjg4n57DUHxqyBgTzvYSzfi-sP1N-ZORQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Andres!
Thank you for reviewing.
> I don't think this is the right approach. Creating a subtransaction for
> each row will cause substantial performance issues.
>
Subtransactions aren't created for each row. The block of rows in one
subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be changed. There is also
a constraint for the number of bytes MAX_SAFE_BUFFER_BYTES in safe_buffer:
while (sfcstate->saved_tuples < SAFE_BUFFER_SIZE &&
sfcstate->safeBufferBytes < MAX_SAFE_BUFFER_BYTES)
We now can call data type input functions without throwing errors, see
> InputFunctionCallSafe(). Use that to avoid throwing an error instead of
> catching it.
>
InputFunctionCallSafe() is good for detecting errors from input-functions
but there are such errors from NextCopyFrom () that can not be detected
with InputFunctionCallSafe(), e.g. "wrong number of columns in row''. Do
you offer to process input-function errors separately from other errors?
Now all errors are processed in one "switch" loop in PG_CATCH, so this
change can complicate code.
Regards,
Damir Belyalov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-06 05:03:03 | Re: Exit walsender before confirming remote flush in logical replication |
Previous Message | Amit Kapila | 2023-02-06 04:29:19 | Re: Exit walsender before confirming remote flush in logical replication |