Re: [HACKERS] How about a option to disable autovacuum cancellation on lock conflict?

On 11/29/14, 2:22 AM, Andres Freund wrote: Hi, I've more than once seen that autovacuums on certain tables never succeed because regular exclusive (or similar) lockers cause it to give way/up before finishing. Usually if some part of the application uses explicit exclusive locks. In general I

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

David G Johnston writes: > Noah Misch-2 wrote >> I had considered that, and one could make a reasonable case for living >> with the new symbol on that basis. For the release candidate stage to >> have value, though, the "treat as released" principle must not be >> absolute. I regret not noticing

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

On Sun, Sep 21, 2014 at 02:31:15AM -0400, Noah Misch wrote: > It then dawned on me that every Windows build of PostgreSQL already has a way > to limit connections to a particular OS user. SSPI authentication is > essentially the Windows equivalent of peer authentication. A brief trial > thereof l

[HACKERS] Determining typmod of *source* of a cast

Is there any way to determine the typemod of the source data for a cast? Perhaps a modification on get_call_expr_argtype(), though I'd hate to put that in an extension... BTW, it'd be nice if we better emphasized that the typmod passed to a cast function is for the destination... :/ -- Jim Nas

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

Noah Misch-2 wrote > On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote: >> Noah Misch < > noah@ > > writes: >> > Revert "Add libpq function PQhostaddr()." >> > This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14. The >> > function returned the raw value of a connection parameter,

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

Noah Misch writes: > On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote: >> I confess to not having been paying too much attention to your discussion >> with Fujii over the holiday, but isn't it a bit too late to be making >> client-API-breaking changes in 9.4? I would have been fine with t

Re: [HACKERS] Review of GetUserId() Usage

All, * Stephen Frost (sfr...@snowman.net) wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > Attached is a patch to address the pg_cancel/terminate_backend and the > > statistics info as discussed previously. It sounds like we're coming to > > And I forgot the attachment, of course. Apolo

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote: > Noah Misch writes: > > Revert "Add libpq function PQhostaddr()." > > This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14. The > > function returned the raw value of a connection parameter, a task served > > by PQconninfo(). The

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

Andrew Dunstan writes: > Looks like this has broken the docs. See > That's because the cross-reference from the release notes wasn't removed. regards, tom lane -- Sent via pgsql-hac

Re: [HACKERS] [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

Noah Misch writes: > Revert "Add libpq function PQhostaddr()." > This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14. The > function returned the raw value of a connection parameter, a task served > by PQconninfo(). The next commit will reimplement the psql \conninfo > change that way.

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

Hi, Attached is v2 of the patch lowering array_agg memory requirements. Hopefully it addresses the issues issues mentioned by TL in this thread (not handling some of the callers appropriately etc.). The v2 of the patch does this: * adds 'subcontext' flag to initArrayResult* methods If it's 't

Re: [HACKERS] How about a option to disable autovacuum cancellation on lock conflict?

On Nov 29, 2014 9:23 AM, "Andres Freund" wrote: > > Hi, > > I've more than once seen that autovacuums on certain tables never > succeed because regular exclusive (or similar) lockers cause it to give > way/up before finishing. Usually if some part of the application uses > explicit exclusive lock

[HACKERS] Removing INNER JOINs

Hi, Starting a new thread which continues on from http://www.postgresql.org/message-id/caaphdvoec8ygwoahvsri-84en2k0tnh6gpxp1k59y9juc1w...@mail.gmail.com To give a brief summary for any new readers: The attached patch allows for INNER JOINed relations to be removed from the plan, providing none

[HACKERS] How about a option to disable autovacuum cancellation on lock conflict?

Hi, I've more than once seen that autovacuums on certain tables never succeed because regular exclusive (or similar) lockers cause it to give way/up before finishing. Usually if some part of the application uses explicit exclusive locks. In general I think it's quite imortant that autovacuum bhe