Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 09:15 AM, Robert Haas wrote: > On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote: >> On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote: >>> OK, my reading of this thread is that there is a consensus is to >>> redefine max_parallel_degree=1 as "no

Re: [HACKERS] copyParamList

On Fri, May 27, 2016 at 6:07 PM, Andrew Gierth wrote: > copyParamList does not respect from->paramMask, in what looks to me like > an obvious oversight: > > retval->paramMask = NULL; > [...] > /* Ignore parameters we don't need, to save cycles and space.

Re: [HACKERS] parallel.c is not marked as test covered

On 5/9/16 10:50 AM, Andres Freund wrote: I think it's a good idea to run a force-parallel run on some buildfarm members. But I'm rather convinced that the core tests run by all animals need some minimal coverage of parallel queries. Both because otherwise it'll be hard to get some coverage of

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

Robert Haas writes: > On Thu, May 26, 2016 at 3:28 PM, Tom Lane wrote: >> 99% of the time, you'd be right. But this is an unusual case, for the >> reasons I mentioned before. > I tend to agree with Nikolay. I can't see much upside in making this >

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

On Thu, May 26, 2016 at 3:28 PM, Tom Lane wrote: > Nikolay Shaplov writes: >> Actually I did not expected any discussion for this case. Documentations >> missed an optional keyword, documentation should be fixed. > > 99% of the time, you'd be right.

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in > <14603.1464369...@sss.pgh.pa.us> >> Kyotaro HORIGUCHI writes: >>> By the way, the reason of the "invalid snapshot

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

Hi there, Refering to https://www.postgresql.org/message-id/1352742344.21373.4@mofo I'm running into situations where I'd need to bulk transfer of data tables across servers, but a drop and recreate schema isn't feasible as we are running different permissions etc. on the two databases. Thus

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 31, 2016 at 10:03 AM, Robert Haas wrote: > On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote: >>> As far as I can see normal index builds will allow concurrent hot >>> prunes and everything; since those only require page-level >>>

Re: [HACKERS] Statement timeout

Tatsuo Ishii writes: >> Oops. Previous example was not appropriate. Here are revised >> examples. (in any case, the time consumed at parse and bind are small, >> and I omit the CHECK_FOR_INTERRUPTS after these commands) FWIW, I think the existing behavior is just fine. It

Re: [HACKERS] Rename max_parallel_degree?

On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote: > On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote: >> OK, my reading of this thread is that there is a consensus is to >> redefine max_parallel_degree=1 as "no parallelism" and >> max_parallel_degree>1 as

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote: >> As far as I can see normal index builds will allow concurrent hot >> prunes and everything; since those only require page-level >> exclusive locks. >> >> So for !concurrent builds we might end up with a corrupt index. >

[HACKERS] Logical replication & oldest XID.

Hi, We are using logical replication in multimaster and are faced with some interesting problem with "frozen" procArray->replication_slot_xmin. This variable is adjusted by ProcArraySetReplicationSlotXmin which is invoked by ReplicationSlotsComputeRequiredXmin, which is in turn is called by

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

Hi, On 05/26/2016 10:10 PM, Tom Lane wrote: Tomas Vondra writes: Attached is a patch that should fix the coalescing, including the clock skew detection. In the end I reorganized the code a bit, moving the check at the end, after the clock skew detection.

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> I couldn't find appropriate system documentation.  Regarding Linux, I > remember I saw some HOWTO on tldp.org website which explains the > concept of shared library soname, but it's not very friendly for > users who just want to know the application binary compatibility > policy of PostgreSQL.  

Re: [HACKERS] Binary I/O for isn extension

> > I added this patch to the next CF (2016-09) under "Miscellaneous". > Thanks! > Out of curiosity, what is the motivation? I'm the owner of Npgsql, the open-source .NET driver for PostgreSQL, which is a binary-first driver. That is, working with types that have no binary I/O is possible but

Re: [HACKERS] Binary I/O for isn extension

Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. I did this. A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the extension by renaming the file,

Re: [HACKERS] Binary I/O for isn extension

> > When adding new functions to an extension you need to bump the version of > the extension by renaming the file, updating the .control file, creating an > upgrade script, and updating the Makefile to include the new files. Thanks for the guidance, I'll fix all that and resubmit a patch.

Re: [HACKERS] Binary I/O for isn extension

Hello, Attached is a small patch which adds binary input/output for the types added by the isn extension. I added this patch to the next CF (2016-09) under "Miscellaneous". Out of curiosity, what is the motivation? -- Fabien. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Binary I/O for isn extension

Hi, Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. https://commitfest.postgresql.org/ A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 04:06 AM, Tom Lane wrote: Andreas Karlsson writes: On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The % delimiter character is not only used at the end of the IPV6 address, from the RFC document, it is possible as follows also. fe80::%2/64 we need to handle

Re: [HACKERS] Question and suggestion about application binary compatibility policy

On 31/05/2016 08:10, Tsunakawa, Takayuki wrote: From: Michael Meskes [mailto:mes...@postgresql.org] Yes, but Windows users probably don't understand or know it. So, I suggested explicitly describing the application binary compatibility policy in the PostgreSQL manual. What do you think about

[HACKERS] Binary I/O for isn extension

Hi. Attached is a small patch which adds binary input/output for the types added by the isn extension. Shay isn-binary.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

27 мая 2016 г., в 19:57, Vladimir Borodin написал(а):-performance+hackers25 мая 2016 г., в 17:33, Vladimir Borodin написал(а):Hi all.We have found that queries through PgBouncer 1.7.2 (with transaction pooling) to local PostgreSQL are almost two times slower

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Hello, At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in <14603.1464369...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > By the way, the reason of the "invalid snapshot identifier" is > > that some worker threads try to use it after the

Re: [HACKERS] Statement timeout

> Oops. Previous example was not appropriate. Here are revised > examples. (in any case, the time consumed at parse and bind are small, > and I omit the CHECK_FOR_INTERRUPTS after these commands) > > [example 1] > > statement_timeout = 3s > > parse(statement1) -- time 0. set statement timout

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: Michael Meskes [mailto:mes...@postgresql.org] > > Yes, but Windows users probably don't understand or know it. So, I > > suggested explicitly describing the application binary compatibility > > policy in the PostgreSQL manual. What do you think about it? > > Couldn't you point your

<    1   2