Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) - Mailing list pgsql-hackers

From Damir Belyalov
Subject Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Date
Msg-id CALH1LgsbWZWS3qMxdGjg4n57DUHxqyBgTzvYSzfi-sP1N-ZORQ@mail.gmail.com
Whole thread Raw
In response to Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)  (Andres Freund <andres@anarazel.de>)
Responses Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication
Next
From: Andres Freund
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication