> On 4. Dec 2021, at 22:43, Laurenz Albe wrote:
>
> On Fri, 2021-12-03 at 21:33 +0100, Daniel Frey wrote:
>> But the real issue, at least for me, is PQfinish(). Considering that my
>> application is not
>> allowed to hang (or crash, leak, ...), what should I do in case of a timeout?
>
> I am te
On Sun, Dec 5, 2021 at 10:55 AM Dilip Kumar wrote:
>
> On Fri, Dec 3, 2021 at 9:02 PM Tom Lane wrote:
> >
> > Dilip Kumar writes:
> > > On Thu, Dec 2, 2021 at 9:35 AM Dilip Kumar wrote:
> > >> I think there is no such view or anything which tells about which
> > >> backend or transaction has mo
Daniel Frey writes:
> With all that said, I think that PostgreSQL/libpq should have a clear,
> documented way to get rid of a connection that is guaranteed to not hang. It
> has something similar for almost all other methods like opening connections,
> sending request, retrieving results. Why s
> On 5. Dec 2021, at 17:01, Tom Lane wrote:
>
> Daniel Frey writes:
>> With all that said, I think that PostgreSQL/libpq should have a clear,
>> documented way to get rid of a connection that is guaranteed to not hang. It
>> has something similar for almost all other methods like opening conne
>
> Agreed with both points. What about we add, subxid count and overflow
> status in LocalPgBackendStatus and through that, we can show in
> pg_stat_activity. That way we don't have to report it ever and
> whenever the user is running pg_stat_activity they can fetch it
> directly from "proc->sub
On Mon, Dec 6, 2021 at 6:11 AM James Sewell wrote:
>>
>> Agreed with both points. What about we add, subxid count and overflow
>> status in LocalPgBackendStatus and through that, we can show in
>> pg_stat_activity. That way we don't have to report it ever and
>> whenever the user is running pg_s
At Fri, 3 Dec 2021 15:41:51 +0800, Yi Sun wrote in
> Hi Kyotaro,
>
> Thank you for your explanation, after putting the crl file to client, it
> works now, thanks.
Good to hear that. That portion of the documentation has been fixed on
the repository, and it will be released in the next minor rel
+1, I too like the idea. The patch doesn't seem to be doing any heavy
> lifting, I think that much overhead should be acceptable.
>
I'm guessing this won't be back-patched? Is it possible to somehow read
this information from a C function?
- James
--
The contents of this email are confidential
