Rune,
This is a readline issue of some sort. Basically this seg fault happens when
you quit and the .psql_history file changes. I don't really know why it
happens and what the right solution is but if you empty the contents of this
file (or maybe delete it) then your seg fault will go away (until
Thank you very much, I'll verify this tomorrow and return if the error
persists. What led you to the conclusion that it was a readline error? I
looked into it for a couple of hours, but as I'm new to the postgres
source code I cound't find the error :)
For the life of me I can't remember!
Hi,
When persisting a holdable cursor at COMMIT time we currently choose to
rewind the executor and re-scan the whole result set into the tuplestore in
order to be able to scroll backwards later on. And then, we reposition the
cursor to the position we been in. However, unless I am missing
Alon Goldshuv on Bizgres has been working on this as well. Maybe you
could collaborate? Alon?
I would love to collaborate. The proposal is neat, however, I am not too
excited about handling errors in such high granularity, as far as the user
is concerned. I am more on the same line with Tom
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
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
In the libpq COPY interface function PQputCopyData():
/*
* Check for NOTICE messages coming back from the server. Since the
* server might generate multiple notices during the COPY, we have to
* consume those in a reasonably prompt fashion to prevent the comm
* buffers from filling up and
Tom,
And, unfortunately, you've broken it. The pqFlush call visible in that
routine is not the only place that may try to send data (see also
pqPutMsgEnd).
You are right, thanks for pointing that out.
Still, in pqPutMsgEnd we will be sending data only after 8K is reached,
which is about
This is a second iteration of a previous thread that didn't resolve few
weeks ago. I made some more modifications to the code to make it compatible
with the current COPY FROM code and it should be more agreeable this time.
The main premise of the new code is that it improves the text data parsing
Bruce,
Point taken.
Now, you can argue that
a different escape should be possible, or that some other escape syntax
could be used, but the existing mechanism is clearly 100% reliable when
used properly and not broken.
I think that having an option for another escape syntax (such as using
2) A modified command syntax for introducing a direct single row error
handling. By direct I mean - a row that if rejected from within the COPY
command context does not throw an error and rollsback the whole transaction.
Instead the error is caught and recorded elsewhere, maybe in some error
I have been working on improving the COPY command performance and as a
result also came up with other thoughts that may possibly be better off
implemented in a new command (i.e LOAD DATA) rather than adding them to the
existing COPY.
The improvements I made were in the COPY parsing logic -
Bruce,
The patch is not there to show that something is broken is it there to
show how things could be done in another way, which may or may not be more
desireable.
COPY works as designed. The idea that some guy we have never heard of
is going to appear and rewrite COPY's processing and tell
yeah, this is all a bit confusing, but I *hope* I can clarify things here as I
think I got a better understanding now.
before that, let me just clarify that the performance improvements in the patch
have nothing to do with the escaping mechanizm. Escapes could change. The
performance gain in
I've been following this thread, and I'm a little confused. Could you
possibly clarify what you mean, by providing a couple of lines of
input as it would be formatted with escape processing turned off -
containing a text field with an embedded newline and tab and a null field.
yeah, this is all
16 matches
Mail list logo
