Thread: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Perhaps we can throw a warning rather than an error, and adjust initdb
> to be consistent.
I like the idea of reducing the newline consistency check to a warning.
There is one thing we'd have to watch for though (it's already an issue
but would become a bigger one): client-side COPY code had better be
prepared to absorb backend Notice messages while processing COPY IN.
Currently libpq doesn't read input data at all during a COPY IN loop,
which means that if the COPY generates more than a few K of warning
messages, the backend gets blocked on a full pipe and the whole
operation locks up. I have been meaning to fix that in libpq anyway,
but what other client libraries might have the same issue? Anyone know
whether JDBC would need a similar fix?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Perhaps we can throw a warning rather than an error, and adjust initdb > > to be consistent. > > I like the idea of reducing the newline consistency check to a warning. > There is one thing we'd have to watch for though (it's already an issue > but would become a bigger one): client-side COPY code had better be > prepared to absorb backend Notice messages while processing COPY IN. > Currently libpq doesn't read input data at all during a COPY IN loop, > which means that if the COPY generates more than a few K of warning > messages, the backend gets blocked on a full pipe and the whole > operation locks up. I have been meaning to fix that in libpq anyway, > but what other client libraries might have the same issue? Anyone know > whether JDBC would need a similar fix? Wow, that sounds big. The ERROR will only happen once, while the WARNING could happen a lot --- we could add code to throw the WARNING only once per COPY command --- that would probably make sense. I don't see how we could get all clients to handle this for 7.4, particularly clients from previous releases. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> ... we could add code to throw the WARNING
> only once per COPY command --- that would probably make sense.
Seems like a bit of a kluge, but perhaps the best compromise. It would
be quite likely that you'd get the same warning on many lines of a COPY,
and that probably isn't really going to help people.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > ... we could add code to throw the WARNING > > only once per COPY command --- that would probably make sense. > > Seems like a bit of a kluge, but perhaps the best compromise. It would > be quite likely that you'd get the same warning on many lines of a COPY, > and that probably isn't really going to help people. I can't think of any cases where we throw _tons_ of warnings at people, like we could with COPY. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Fri, 26 Sep 2003, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Perhaps we can throw a warning rather than an error, and adjust initdb > > to be consistent. > > I like the idea of reducing the newline consistency check to a warning. > There is one thing we'd have to watch for though (it's already an issue > but would become a bigger one): client-side COPY code had better be > prepared to absorb backend Notice messages while processing COPY IN. > Currently libpq doesn't read input data at all during a COPY IN loop, > which means that if the COPY generates more than a few K of warning > messages, the backend gets blocked on a full pipe and the whole > operation locks up. I have been meaning to fix that in libpq anyway, > but what other client libraries might have the same issue? Anyone know > whether JDBC would need a similar fix? > JDBC does not support the COPY protocol at the moment. Kris Jurka