Re: [GENERAL] question on error during COPY FROM

On Tue, Aug 23, 2016 at 6:04 AM, Jerome Wagner wrote: > Hello, > > in the documentation I read > https://www.postgresql.org/docs/current/static/sql-copy.html > > > COPY stops operation at the first error. This should not lead to problems > in the event of a COPY TO,

Re: [GENERAL] Nonblocking libpq + openssl = ?

17.09.2016 3:27, Andres Freund: [...] The relevant user-level API of libpq (PQisBusy) doesn't have a way to return "waiting for write". So we'd have to break API compatibility. I think this is actually not entirely correct. PQisBusy is fine, I do not see a need to touch it at all. Rather, the

Re: [GENERAL] Verifying LISTEN subscriptions?

NVM, a quick search through the output of `\dfS` showed me the `pg_listening_channels()` function, which returns a TEXT[] of currently subscribed channels. Cheers, Deven On Sat, Sep 17, 2016 at 8:45 AM, Deven Phillips wrote: > From a connection which has previously

[GENERAL] Verifying LISTEN subscriptions?

>From a connection which has previously executed a LISTEN statement, is there a query which I can run which will tell me if it is still listening on those channels? Thanks in advance!! Deven Phillips

Re: [GENERAL] Nonblocking libpq + openssl = ?

17.09.2016 11:15, I wrote: [...] The relevant user-level API of libpq (PQisBusy) doesn't have a way to return "waiting for write". So we'd have to break API compatibility. Ah, I see. But then, this is a very common sort of problem (Existing API spec getting inadequate for some new features

Re: [GENERAL] Nonblocking libpq + openssl = ?

17.09.2016 3:27, Andres Freund: [...] Looks like it _usually_ happens so that such interdependent reads and writes are unnecessary in the absence of renegotiations. But still [1] instructs to always check for both SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE in all cases. Supposedly it is for a