Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id 25357.1064600759@sss.pgh.pa.us
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [JDBC] initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Kris Jurka <books@ejurka.com>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Bruce Momjian
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)