Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Поиск
Список
Период
Сортировка
От Damir Belyalov
Тема Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Дата
Msg-id CALH1LgsbWZWS3qMxdGjg4n57DUHxqyBgTzvYSzfi-sP1N-ZORQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)  (Andres Freund <andres@anarazel.de>)
Ответы Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Exit walsender before confirming remote flush in logical replication
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Exit walsender before confirming remote flush in logical replication