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

Hi, > - Build an embedded SQL C application with PostgreSQL 9.2. > - Distribute the app without ecpg nor libpq libraries.  Require users > to install PostgreSQL client which includes ecpg and libpq libraries. > - Use the app with newer PostgreSQL major versions without rebuilding > the app.  That

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

> From: pgsql-hackers-ow...@postgresql.org > Sorry I fail to understand what you mean with "legal"? Are you wondering > about license restrictions? There are none. Sorry, I just meant "correct" or "valid". > As for compatibility, that's what major version numbers are for. This is > not a

Re: [HACKERS] foreign table batch inserts

On 2016/05/27 8:49, Michael Paquier wrote: On Thu, May 26, 2016 at 4:25 AM, Etsuro Fujita wrote: Honestly, I didn't have any idea for executing such an insert efficiently, but I was thinking to execute an insert into a foreign table efficiently, by sending the

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On 23 May 2016 at 17:01, Jeff Davis wrote: > On Fri, May 20, 2016 at 1:41 PM, David G. Johnston > wrote: >> How does the relatively new FILTER clause play into this, if at all? > > My interpretation of the standard is that FILTER is not allowable

Re: [HACKERS] Further stabilization of isolationtester's timeouts test

On 2016-05-27 04:06, Tom Lane wrote: In this case the process seems to have gone to sleep for just short of a minute rather than the expected 5 seconds. Presumably that just reflects overload on the buildfarm member rather than anything really exciting, but it explains the failure nicely: by

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

> > Sorry I fail to understand what you mean with "legal"? Are you > > wondering > > about license restrictions? There are none. > > Sorry, I just meant "correct" or "valid". Ah ok, thanks for clarifying. > > As for compatibility, that's what major version numbers are for. > > This is > > not a

Re: [HACKERS] foreign table batch inserts

On 30 May 2016 at 16:17, Etsuro Fujita wrote: > > That's a good point, but the basic idea is to send the local query > almost-as-is to the remote server if possible. For example, if the local > query is "INSERT INTO foreign_table(a,b,c) VALUES (1, 2, 3), (4, 5,

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

> 28 мая 2016 г., в 0:56, Andres Freund написал(а): > > Hi, > > > On 2016-05-27 19:57:34 +0300, Vladimir Borodin wrote: >> -performance >>> Here is how the results look like for 9.4, 9.5 and 9.6. All are built from >>> latest commits on yesterday in >>> *

Re: [HACKERS] "Allow usage of huge maintenance_work_mem for GIN build" patch

--- a/src/include/access/gin_private.h +++ b/src/include/access/gin_private.h @@ -903,7 +903,7 @@ typedef struct GinEntryAccumulator typedef struct { GinState *ginstate; - longallocatedMemory; + SizeallocatedMemory; GinEntryAccumulator *entryallocator;

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

> "Dean" == Dean Rasheed writes: Dean> That may be so, but we already support FILTER for all windows Dean> functions as well as aggregates: Not so: "If FILTER is specified, then only the input rows for which the filter_clause evaluates to true are fed to the

Re: [HACKERS] "Allow usage of huge maintenance_work_mem for GIN build" patch

Teodor Sigaev writes: >> Are you sure this is safe, Teodor? I don't have time to study the >> patch in detail, but offhand I think that it might have been better to >> make allocatedMemory of type int64, just like the tuplesort.c memory >> accounting variables are

[HACKERS] PostgreSQL Weekly News Survey

Folks, In lieu of the weekly news this week, I'd like to as you to help improve the PostgreSQL Weekly News by participating in this survey. http://goo.gl/forms/Q6FPPwzPG3Zq66pC2 Thanks in advance, and please let me know if you have any trouble reaching or using the survey. Cheers, David. --

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

Tom Dunstan writes: > Basically the inet data type cannot store or parse valid ipv6 address > literals with a scope / zone id suffix. Apparently the combination of > virtualised linux, ipv6 network and JVM that we are using has combined to > report connections on localhost as

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

> 28 мая 2016 г., в 0:56, Andres Freund написал(а): > > On 2016-05-27 19:57:34 +0300, Vladimir Borodin wrote: >> >> OS PostgreSQL version TPS Avg. >> latency >> RHEL 6 9.4 44898

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On 30 May 2016 at 15:44, Andrew Gierth wrote: >> "Dean" == Dean Rasheed writes: > > Dean> That may be so, but we already support FILTER for all windows > Dean> functions as well as aggregates: > > Not so: > > "If FILTER is specified,

Re: [HACKERS] Reviewing freeze map code

On Tue, May 31, 2016 at 4:40 AM, Jeff Janes wrote: > On Wed, May 18, 2016 at 3:57 PM, Alvaro Herrera > wrote: >> Andres Freund wrote: >> >>> >>> If we had a checking module for all this it'd possibly be sufficient, >>> but we don't. >> >> Here's an

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

> On 31 May 2016, at 2:07 AM, Tom Lane wrote: > > The impression I have is that scopes are not very well standardized --- > eg, OS X reports things like "fe80::1%lo0" not just "%0". If we could > get around that problem it would be worth doing. Yeah, we’d have to just

Re: [HACKERS] Does people favor to have matrix data type?

> On 05/29/2016 04:55 PM, Kouhei Kaigai wrote: > > For the closer integration, it may be valuable if PL/R and PL/CUDA can > > exchange > > the data structure with no serialization/de-serialization when PL/R code > > tries > > to call SQL functions. > > I had been thinking about something

Re: [HACKERS] Does people favor to have matrix data type?

On 31/05/16 12:01, Kouhei Kaigai wrote: On 05/29/2016 04:55 PM, Kouhei Kaigai wrote: For the closer integration, it may be valuable if PL/R and PL/CUDA can exchange the data structure with no serialization/de-serialization when PL/R code tries to call SQL functions. I had been thinking about

[HACKERS] Redesign of parallel dump/restore's response to SIGINT

There are several things that are not very good about the handling of cancel interrupts (control-C etc) in parallel pg_dump/pg_restore. Currently, the signal handler just sets a "wantAbort" flag which is tested in checkAborting(). That means: 1. There had better be a checkAborting() call in

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

On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The following is the content of IPV6 representation from RFC 4007 The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th

Re: [HACKERS] Does people favor to have matrix data type?

> -Original Message- > From: Gavin Flower [mailto:gavinflo...@archidevsys.co.nz] > Sent: Tuesday, May 31, 2016 9:47 AM > To: Kaigai Kouhei(海外 浩平); Joe Conway; Jim Nasby; Ants Aasma; Simon Riggs > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Does people favor to have matrix

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

On Tue, May 31, 2016 at 9:35 AM, Tom Dunstan wrote: > >> On 31 May 2016, at 2:07 AM, Tom Lane wrote: >> >> The impression I have is that scopes are not very well standardized --- >> eg, OS X reports things like "fe80::1%lo0" not just "%0". If we could >> get

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

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 both the scenarios, it

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:37 AM, Tom Lane wrote: Andreas Karlsson writes: Ok, then I can avoid touching all functions which are only called by operator classes, tsearch, pls, fdws, etc. Which also means that there is no need to care about Tom's changes to the signatures of GIN and

Re: [HACKERS] foreign table batch inserts

On 2016/05/30 22:59, Craig Ringer wrote: > On 30 May 2016 at 16:17, Etsuro Fujita wrote: >> >> That's a good point, but the basic idea is to send the local query >> almost-as-is to the remote server if possible. For example, if the local >> query is "INSERT INTO

Re: [HACKERS] Does people favor to have matrix data type?

On 05/29/2016 04:55 PM, Kouhei Kaigai wrote: > For the closer integration, it may be valuable if PL/R and PL/CUDA can > exchange > the data structure with no serialization/de-serialization when PL/R code tries > to call SQL functions. I had been thinking about something similar. Maybe PL/R can

Re: [HACKERS] RLS related docs

On 05/26/2016 12:26 AM, Dean Rasheed wrote: > On 25 May 2016 at 02:04, Joe Conway wrote: >> Please see attached two proposed patches for the docs related to RLS: >> >> 1) Correction to pg_restore >> 2) Additional mentions that "COPY FROM" does not allow RLS to be enabled >> >>

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

On 2016-05-30 12:51:17 +0900, Michael Paquier wrote: > On Sat, May 28, 2016 at 9:57 AM, Andres Freund wrote: > > On 2016-05-27 20:54:43 -0400, Tom Lane wrote: > >> Andres Freund writes: > >> > On 2016-05-26 12:44:51 -0400, Tom Lane wrote: > >> > 2016-04-27

Re: [HACKERS] regexp_match() returning text

> "Emre" == Emre Hasegeli writes: Emre> Attached patch adds regexp_match() function which is a simple Emre> variant of regexp_matches() that doesn't return a set. We already have a function that takes a string and a regexp and returns a single text result: substring().

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Andreas Seltenreich wrote: > Alvaro Herrera writes: > > > If you can re-run sqlsmith and see if you can find different bugs, I'd > > appreciate it. > [...] > > [2. text/x-diff; brincrash-2.patch] > > BRIN is inconspicuous since applying this patch. All coredumps I see > now are either due to

Re: [HACKERS] regexp_match() returning text

On Sun, May 29, 2016 at 1:28 PM, Emre Hasegeli wrote: > Attached patch adds regexp_match() function which is a simple variant of > regexp_matches() that doesn't return a set. It is based on Tom Lane's > comment to bug #10889 [1]. > > [1]

Re: [HACKERS] Reviewing freeze map code

On Wed, May 18, 2016 at 3:57 PM, Alvaro Herrera wrote: > Andres Freund wrote: > >> >> If we had a checking module for all this it'd possibly be sufficient, >> but we don't. > > Here's an idea. We need core-blessed extensions (src/extensions/, you > know I've proposed