Can I get an updated patch for this?
---
Tom Lane wrote:
Alon Goldshuv [EMAIL PROTECTED] writes:
Please help me understand this better. It appears to me that when the
client-backend pipe fills up, pqSendSome() consumes
I'll send it to -patches shortly
Alon.
On 1/23/06 10:20 PM, Bruce Momjian pgman@candle.pha.pa.us wrote:
Can I get an updated patch for this?
---
Tom Lane wrote:
Alon Goldshuv [EMAIL PROTECTED] writes:
Please
Tom,
It's not enough better, because it will still deadlock given a
sufficiently large message-to-send. I don't think you can postpone
the clearing-input action until after all the data is sent.
regards, tom lane
Please help me understand this better. It appears to me that when the
Alon Goldshuv [EMAIL PROTECTED] writes:
Please help me understand this better. It appears to me that when the
client-backend pipe fills up, pqSendSome() consumes any incoming
NOTICE/WARNING messages before waiting, which should prevent deadlock.
Hm, I had forgotten that the low-level
The following is a suggestion for optimizing the libpq COPY FROM call for
better performance. I submitted a similar suggestion awhile ago, but it
wasn't safe enough. This one is better. It shows a pretty significant
improvement while maintaining deadlock prevention.
The change is localized to
Title: Re: [HACKERS] Libpq COPY optimization
A note on this we see a huge performance benefit from this change on Solaris, so much so that it should be mandatory for that platform. Solaris error handling is deeper, and so the repeated redundant interrupts that this patch avoids causes 60
Alon Goldshuv [EMAIL PROTECTED] writes:
The following is a suggestion for optimizing the libpq COPY FROM call for
better performance. I submitted a similar suggestion awhile ago, but it
wasn't safe enough. This one is better.
It's not enough better, because it will still deadlock given a
