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

[Michael Meskes]

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 is, the users just replaces the PostgreSQL client.
> 
> I expect this is legal, because the so_major versions of ecpg and
> libpq are 6 and 5 respectively for all PostgreSQL 9.x versions so
> far.  However, I could not find any description of this binary
> compatibility policy in the manual, so I haven't been able to answer
> the customer.

Sorry I fail to understand what you mean with "legal"? Are you
wondering about license restrictions? There are none.

As for compatibility, that's what major version numbers are for. This
is not a PostgreSQL topic, but a general system one as for instance the
same holds for libc.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tsunakawa, Takayuki]

> 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 PostgreSQL topic, but a general system one as for instance the same
> holds for libc.

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?


Regards
Takayuki Tsunakawa



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] foreign table batch inserts

[Etsuro Fujita]

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 whole insert to the remote server, if possible.  For example, if
the insert is of the form:

INSERT INTO foreign_table(a,b,c) VALUES (1, 2, 3), (4, 5, 6) or
INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM foreign_table2

where foreign_table and foreign_table2 belong to the same foreign server,
then we could send the whole insert to the remote server.

Wouldn't that make sense?



Query strings have a limited length, and this assumption is true for
many code paths in the backend code, so doing that with a long string
would introduce more pain in the logic than anything else, as this
would become more data type sensitive.


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, 6)", send the remote query "INSERT INTO remote_table(a,b,c) VALUES 
(1, 2, 3), (4, 5, 6)" to the remote server where remote_table is the 
table name for the foreign table on the remote server.  So, wouldn't the 
query string length be a problem in many cases?  Maybe I'm missing 
something, though.


Best regards,
Etsuro Fujita




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Dean Rasheed]

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 for
> a window function, and IGNORE|RESPECT NULLS is not allowable for an
> ordinary aggregate.
>

That may be so, but we already support FILTER for all windows
functions as well as aggregates:

https://www.postgresql.org/docs/current/static/sql-expressions.html#SYNTAX-AGGREGATES
https://www.postgresql.org/docs/current/static/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS

so to be clear, what we're talking about here is just supporting SQL
standard syntax for window functions, rather than adding any new
functionality, right?


> So if we support IGNORE|RESPECT NULLS for anything other than a window
> function, we have to come up with our own semantics.
>

Given that we can already do this using FILTER for aggregates, and
that IGNORE|RESPECT NULLS for aggregates is not part of the SQL
standard, I see no reason to support it.

Regards,
Dean


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Michael Meskes]

> > 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 PostgreSQL topic, but a general system one as for instance
> > the same
> > holds for libc.
> 
> 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 customer to the system documentation?

Personally I don't think standard system behavior should be documented
for each application relying on it but ymmv.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Mikael Kjellström]

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 the time we got to postgres.c's
ProcessInterrupts(), both the lock and statement timeouts had expired,
and the code there preferentially reports "lock timeout" in that case.


Just wanted to chip in and say that it's almost certain due to 
overloading.  It's a virtual server (VMWare) that runs 4 build animals 
and they all where scheduled to run at the same time and it's on 
spinning rust (i.e. HDD) so it will get overloaded easilly.


I've changed the schedules of the 4 animals so that they shouldn't 
overloap so from now on it should hopefully be much better.


/Mikael


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] foreign table batch inserts

[Craig Ringer]

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, 6)",
> send the remote query "INSERT INTO remote_table(a,b,c) VALUES (1, 2, 3),
> (4, 5, 6)" to the remote server where remote_table is the table name for
> the foreign table on the remote server.  So, wouldn't the query string
> length be a problem in many cases?  Maybe I'm missing something, though.
> 
>


FDWs don't operate at that level. They don't see the original query string.
They're plan nodes that operate with a row-by-row push/pull model. The
foreign table node in question has no idea you're doing a multivalued
insert and doesn't care if it's INSERT INTO ... SELECT, INSERT INTO ...
VALUES, or COPY.

That's why I think using batching is the way to go here. Each operation
remains isolated, but you don't force a round trip for each one, you just
queue them up on the wire and you flush only at end-of-statement. A failure
will cause the statement to ERROR and abort the tx, so the effect is the
same, though the failure might be a bit later than if you forced a flush
each time.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

[Teodor Sigaev]

--- 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;
 uint32  eas_used;
 RBTree *tree;

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 post-MaxAllocHuge. It's not obvious to me
that this variable isn't allowed to occasionally become negative, just
like in tuplesort.c. It looks like that *might* be true -- ginbulk.c
may let allocatedMemory go negative for a period, which would now be
broken.
It could not be negative - subtruction is doing only around repalloc call, in 
all other places it only grows.




If you did make this exact error, you would not be the first. If it
isn't actually broken, perhaps you should still make this change,
simply on general principle. I'd like to hear other opinions on that,
though.
It could be an int64 without any regressions or problems. I choose Size type 
because variable allocatedMemory actually stores a size of piece of memory and 
it's the same type as returned by GetMemoryChunkSpace()


AFAIK, size_t type (type Size is a just typedef alias) is a part of C99 and it 
should be unsigned and large enough to store size of any chunk of avaliable RAM. 
And it at least twice larger than allowed all memory-related GUC variables.


I don't see a reason to use int64 except, may be, general practice in pgsql. But 
then why we keep Size type - let us just use int64.



--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Andrew Gierth]

> "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 window function; other
rows are discarded. Only window functions that are aggregates accept a
FILTER clause."

(Per spec, FILTER appears only in the  production,
which is just one of the several options for .)

-- 
Andrew (irc:RhodiumToad)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Vladimir Borodin]

> 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
>>> * REL9_4_STABLE (a0cc89a28141595d888d8aba43163d58a1578bfb),
>>> * REL9_5_STABLE (e504d915bbf352ecfc4ed335af934e799bf01053),
>>> * master (6ee7fb8244560b7a3f224784b8ad2351107fa55d).
>>> 
>>> All of them are build on the host where testing is done (with stock gcc 
>>> versions). Sysctls, pgbouncer config and everything we found are the same, 
>>> postgres configs are default, PGDATA is in tmpfs. All numbers are 
>>> reproducible, they are stable between runs.
>>> 
>>> Shortly:
>>> 
>>> OS  PostgreSQL version  TPS Avg. 
>>> latency
>>> RHEL 6  9.4 44898   
>>> 1.425 ms
>>> RHEL 6  9.5 26199   
>>> 2.443 ms
>>> RHEL 6  9.5 43027   
>>> 1.487 ms
>>> Ubuntu 14.049.4 67458   
>>> 0.949 ms
>>> Ubuntu 14.049.5 64065   
>>> 0.999 ms
>>> Ubuntu 14.049.6 64350   
>>> 0.995 ms
>> 
>> The results above are not really fair, pgbouncer.ini was a bit different on 
>> Ubuntu host (application_name_add_host was disabled). Here are the right 
>> results with exactly the same configuration:
>> 
>> OS   PostgreSQL version  TPS Avg. 
>> latency
>> RHEL 6   9.4 44898   
>> 1.425 ms
>> RHEL 6   9.5 26199   
>> 2.443 ms
>> RHEL 6   9.5 43027   
>> 1.487 ms
>> Ubuntu 14.04 9.4 45971   1.392 ms
>> Ubuntu 14.04 9.5 40282   1.589 ms
>> Ubuntu 14.04 9.6 45410   1.409 ms
> 
> Hm. I'm a bit confused. You show one result for 9.5 with bad and one
> with good performance. I suspect the second one is supposed to be a 9.6?

No, they are both for 9.5. One of them is on RHEL 6 host, another one on Ubuntu 
14.04.

> 
> Am I understanding correctly that the performance near entirely
> recovered with 9.6?

Yes, 9.6 is much better than 9.5.

> If so, I suspect we might be dealing with a memory
> alignment issue. Do the 9.5 results change if you increase
> max_connections by one or two (without changing anything else)?

Results with max_connections=100:

OS  Version TPS Avg. latency
RHEL 6  9.4 69810   0.917
RHEL 6  9.5 35303   1.812
RHEL 6  9.6 71827   0.891
Ubuntu 14.049.4 76829   0.833
Ubuntu 14.049.5 67574   0.947
Ubuntu 14.049.6 79200   0.808

Results with max_connections=101:

OS  Version TPS Avg. latency
RHEL 6  9.4 70059   0.914
RHEL 6  9.5 35979   1.779
RHEL 6  9.6 71183   0.899
Ubuntu 14.049.4 78934   0.811
Ubuntu 14.049.5 67803   0.944
Ubuntu 14.049.6 79624   0.804


Results with max_connections=102:

OS  Version TPS Avg. latency
RHEL 6  9.4 70710   0.905
RHEL 6  9.5 36615   1.748
RHEL 6  9.6 69742   0.918
Ubuntu 14.049.4 76356   0.838
Ubuntu 14.049.5 66814   0.958
Ubuntu 14.049.6 78528   0.815

Doesn’t seem that it is a memory alignment issue. Also please note that there 
is no performance degradation when connections from pgbench to postgres are 
established without pgbouncer:

OS  Version TPS Avg. latency
RHEL 6  9.4 167427  0.382
RHEL 6  9.5 223674  0.286
RHEL 6  9.6 215580  0.297
Ubuntu 14.049.4 176659  0.362
Ubuntu 14.049.5 248277  0.258
Ubuntu 14.049.6 245871  0.260

> 
> What's the actual hardware?

Host with RHEL has Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2 sockets, 16 
physical cores, 32 cores with Hyper-Threading) and 256 GB of RAM while host 
with Ubuntu has Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz (2 sockets, 16 
physical cores, 32 cores with Hyper-Threading) and 128 GB of RAM.

> 
> Greetings,
> 
> Andres Freund


--
May the fo

[HACKERS] PostgreSQL Weekly News Survey

[David Fetter]

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.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 post-MaxAllocHuge. It's not obvious to me
>> that this variable isn't allowed to occasionally become negative, just
>> like in tuplesort.c. It looks like that *might* be true -- ginbulk.c
>> may let allocatedMemory go negative for a period, which would now be
>> broken.

> It could not be negative - subtruction is doing only around repalloc call, in 
> all other places it only grows.

As long as we're certain of that, Size seems like the appropriate field
type.  But I wonder if it'd be worth adding an assert to the subtraction
steps, ie

Assert(accum->allocatedMemory >= delta);
accum->allocatedMemory -= delta;

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 coming from ‘::1%0’, which our app is 
> unsuccessfully attempting to store in the db in an inet column. This is the 
> first time that I have ever seen this, but perhaps it will get more common as 
> ipv6-first usage increases.

> Given that inet is a varlena struct with only known-length fields, it seems 
> potentially possible to extend it to add an optional, variable length zone id 
> on the end, with the result being backwards compatible with existing data.

> Thoughts?

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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Vladimir Borodin]

> 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   
>> 1.425 ms
>> RHEL 6   9.5 26199   
>> 2.443 ms
>> RHEL 6   9.5 43027   
>> 1.487 ms
> 
> Hm. I'm a bit confused. You show one result for 9.5 with bad and one
> with good performance. I suspect the second one is supposed to be a 9.6?

Sorry, I misunderstood. Yes, the last line above is for 9.6, that was a typo.

> 
> Greetings,
> 
> Andres Freund


--
May the force be with you…
https://simply.name

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

[Dean Rasheed]

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, then only the input rows for which the
> filter_clause evaluates to true are fed to the window function; other
> rows are discarded. Only window functions that are aggregates accept a
> FILTER clause."
>

Ah, yes. It's all coming back to me now.

Regards,
Dean


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] regexp_match() returning text

[David G. Johnston]

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] https://www.postgresql.org/message-id/23769.1404747...@sss.pgh.pa.us


Not sure if we need two functions or what but I dislike that:

"It ignores the parenthesized subexpressions in the pattern."

​The main problem being solved is the use of a SETOF result.  I'm inclined
to prefer that the final, single, result is still an array.

Even if we return a single text value instead of an array it would be nice
to return the first (only...) parenthesized subexpression so that the input
pattern isn't constrained.

​I've got a style issue with the information_schema - I like to call it
useless-use-of-E'' -  but that was there long before this patch...

/* user mustn't specify 'g' for regexp_split */ - do we add "or
regexp_match" or just removed the extraneous detail?

There seems to be scope creep regarding "regexp_split_to_table" that I'm
surprised to find.  Related to that is the unexpected removal of the
"force_glob" parameter to setup_regexp_matches.  You took what was a single
block of code and now duplicated it without any explanation in the commit
message (a code comment wouldn't work for this kind of change).  The change
to flags from passing a pointer to text to passing in a pointer to a
previously derived pg_re_flags makes more sense on its face, and it is
apparently a non-public API, but again constitutes a refactoring that at
least would ideally be a separate commit from the one the introduces the
new behavior.

Also, I see an assert for the "no subexpressions" policy but I have seemed
to have overlooked where the non-assert-enabled user is informed of the
prohibition.

Tom's opinion on all this will be needed - I am not a C code writer nor do
I follow the patch writing process that closely generally, but I have a
keen interest in this topic - but there seems to be a bit more here than
simply having a function identical to the existing regexp_matches function
that prohibits the global flag and only ever returns a single array per the
existing API.

I'm good with the name, regexp_match - even with the behavior being changed
to returning an array instead of text.  If there was any active plans to
redo the API so that we'd return a composite type instead of an array I'd
be more inclined to reserve "match" for that change and make this one a bit
more verbose.

David J.

Re: [HACKERS] regexp_match() returning text

[Andrew Gierth]

> "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().

Regexp flags other than 'g' can also be embedded in the regexp:

postgres=# select substring('foo bar' from '(?i)BA+');
 substring 
---
 ba

Returning an array containing the values of all capture groups might be
more useful (substring returns the value of the first capture group if
any, otherwise the matched string).

-- 
Andrew (irc:RhodiumToad)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Alvaro Herrera]

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 the parallel worker shutdown issue or acl.c's
> text/name confusion, both reported earlier.

Great.  Pushed patch, after some further cosmetic changes.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reviewing freeze map code

[Jeff Janes]

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 this before), so why not take this opportunity to
> create our first such and make it carry a function to scan a table
> completely to do this task.
>
> Since we were considering a new VACUUM option, surely this is serious
> enough to warrant more than just contrib.

What does "core-blessed" mean?  The commit rights for contrib/ are the
same as they are for src/

Cheers,

Jeff


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Joe Conway]

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 create an
extension within the R environment that wraps PL/CUDA directly or at the
least provides a way to use a fast-path call. We should probably try to
start out with one common use case to see how it might work and how much
benefit there might be.

> IIUC, pg.spi.exec("SELECT my_function(...)") is the only way to call SQL 
> functions inside PL/R scripts.

Correct (currently).

BTW, this is starting to drift off topic I think -- perhaps we should
continue off list?

Thanks,

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] RLS related docs

[Joe Conway]

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
>>
>> Comments?
>>
> 
> The pg_restore change looks good -- that was clearly wrong.
> 
> Also, +1 for the new note in pg_dump.

Great, thanks!

> For COPY, I think perhaps it would be more logical to put the new note
> immediately after the third note which describes the privileges
> required, since it's kind of related, and then we can talk about the
> RLS policies required, e.g.:
> 
> If row-level security is enabled for the table, COPY table TO is
> internally converted to COPY (SELECT * FROM table) TO, and the
> relevant security policies are applied. Currently, COPY FROM is not
> supported for tables with row-level security.

This sounds better than what I had, so I will do it that way.

Thanks,

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

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

[Andres Freund]

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 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL:  
> >> > 42501:
> >> > could not open file "pg_xlog/RECOVERYXLOG": Permission denied
> >>
> >> > So, what's the permission of RECOVERYXLOG at that point?  It's pretty
> >> > weird that directly after running reason_command it's not readable.
> >>
> >> s/not readable/not writable/.  I doubt that it's a good idea for that
> >> code to think that it can fail hard on non-writable files.
> >
> > But we actually sometimes write to files we've recovered; if they're the
> > end of the WAL after archive recovery and/or promotion. If a
> > restore_command restores files in a non-writable way it's buggy; I don't
> > see why it's worthwhile to work around that.
> 
> Not exactly, startup process does not write directly to the files of
> pg_xlog while in recovery.

It does at the end of crash recovery. And the wal receiver does so at
the end of archive recovery (which can repeatedly be reached).

- Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Dunstan]

> 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 store it as a string I think. That’s why I was happy to 
see that inet was already a varlena but only with known-length content.

Cheers

Tom



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Kouhei Kaigai]

> 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 create an
> extension within the R environment that wraps PL/CUDA directly or at the
> least provides a way to use a fast-path call. We should probably try to
> start out with one common use case to see how it might work and how much
> benefit there might be.
>
My thought is the second option above. If SPI interface supports fast-path
like 'F' protocol, it may become a natural way for other PLs also to
integrate SQL functions in other languages.

> > IIUC, pg.spi.exec("SELECT my_function(...)") is the only way to call SQL 
> > functions
> inside PL/R scripts.
> 
> Correct (currently).
> 
> BTW, this is starting to drift off topic I think -- perhaps we should
> continue off list?
>
Some elements are common for PostgreSQL (matrix data type and fastpath SPI
interface). I like to keep the discussion on the list.
Regarding to the PoC on a particular use case, it might be an off-list
discussion.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Haribabu Kommi]

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 around that problem it would be worth doing.

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 organization of the node)

   would be represented as follows:

 fe80::1234%1
 ff02::5678%5
 ff08::9abc%10

   (Here we assume a natural translation from a zone index to the
part, where the Nth zone of any scope is translated into
   "N".)

   If we use interface names as , those addresses could also be
   represented as follows:

fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10

The digit and string both are considered as proper format.

>
> Yeah, we’d have to just store it as a string I think. That’s why I was happy 
> to see that inet was already a varlena but only with known-length content.

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 may not be a straight
forward to store the zone id data.

Regards,
Hari Babu
Fujitsu Australia


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reviewing freeze map code

[Michael Paquier]

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 idea.  We need core-blessed extensions (src/extensions/, you
>> know I've proposed this before), so why not take this opportunity to
>> create our first such and make it carry a function to scan a table
>> completely to do this task.
>>
>> Since we were considering a new VACUUM option, surely this is serious
>> enough to warrant more than just contrib.
>
> What does "core-blessed" mean?  The commit rights for contrib/ are the
> same as they are for src/

Personally I understand contrib/ modules as third-part plugins that
are considered as not enough mature to be part of src/backend or
src/bin, but one day they could become so. See pg_upgrade's recent
move for example. src/extensions/ includes third-part plugins that are
thought as useful, are part of the main server package, but are not
something that we want to enable by default.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Gavin Flower]

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 something similar. Maybe PL/R can create an
extension within the R environment that wraps PL/CUDA directly or at the
least provides a way to use a fast-path call. We should probably try to
start out with one common use case to see how it might work and how much
benefit there might be.


My thought is the second option above. If SPI interface supports fast-path
like 'F' protocol, it may become a natural way for other PLs also to
integrate SQL functions in other languages.


IIUC, pg.spi.exec("SELECT my_function(...)") is the only way to call SQL 
functions

inside PL/R scripts.

Correct (currently).

BTW, this is starting to drift off topic I think -- perhaps we should
continue off list?


Some elements are common for PostgreSQL (matrix data type and fastpath SPI
interface). I like to keep the discussion on the list.
Regarding to the PoC on a particular use case, it might be an off-list
discussion.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei 

Possibly there should be two matrix types in Postgres: the first would 
be the default and optimized for small dense matrices, the second would 
store large sparse matrices efficiently in memory at the expensive of 
speed (possibly with one or more parameters relating to how sparse it is 
likely to be?) - for appropriate definitions 'small' & 'large', though 
memory savings for the latter type might not kick in unless the matrices 
are big enough (so a small sparse matrix might consume more memory than 
a nominally larger dense matrix type & a sparse matrix might have to be 
sufficiently sparse to make real memory savings at any size).


Probably good to think of 2 types at the start, even if the only the 
first is implemented initially.



Cheers,
Gavin



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 every potentially
long-running loop in pg_dump or pg_restore.  I already fixed two such
oversights yesterday in commit 3c8aa6654, but I have little confidence
that there aren't more omissions of that ilk, and none whatsoever that
we won't introduce more of them in the future.

2. If we're not executing code on the client side, but just waiting for
a SQL query to finish, this infrastructure fails to move things along at
all.  That's not a huge problem for pg_dump, nor for data transfer in
pg_restore.  But operations such as a long-running CREATE INDEX in
pg_restore will not get cancelled, and IMV that *is* a problem.

3. On Unix, the key reason the current code manages to produce early exit
in parallel mode is that if you run pg_dump or pg_restore manually, and
type control-C at the console, the SIGINT will be delivered to all members
of the terminal process group; that is, all the worker processes along
with the master.  It's not hard to envision use-cases in which someone
tries to SIGINT just the master.  There's a kluge in the current code that
tries to deal with that case by checking wantAbort in select_loop(), but
that only helps if the master is waiting for workers at the instant the
SIGINT arrives.  If it's someplace else, it will fail to notice wantAbort
till after the next worker finishes, which might be a long time.

4. On Windows, there's no signal handler and so no designed response to
control-C at all.  The pg_dump or pg_restore process just exits, leaving
the connected backend(s) to clean up.  This isn't too awful ... except in
the long-running-CREATE-INDEX case.

Point 2 is basically unfixable without a redesign of pg_dump/pg_restore's
interrupt handling ... so attached is one.  The key idea here is to make
the signal handler itself send a PQcancel request, and then exit(1),
rather than trusting the mainline code to notice the signal anytime soon.
So we can get rid of checkAborting() and thus point 1 goes away too.
Point 3 is dealt with by teaching the master's signal handler to also send
SIGTERM to all the workers.  (Each worker PQcancel's its own connection
and then exits.)  Point 4 is dealt with by introducing a console interrupt
handler (code stolen from psql), which unlike the Unix case can directly
send all the required PQcancels, and then just let the process exit.

We need a bit of notational complexity to ensure that the signal handler
or console interrupt handler thread can't see an inconsistent state; but
we already had some critical-section code in place for that, so it doesn't
get much worse than before.

This patch fixes a few other minor bugs too, for instance that on Windows
we never bothered to set a ParallelSlot's args->AH, so that the intended
DisconnectDatabase call in a worker's archive_close_connection callback
never happened, and thus even the weak existing provision for sending a
PQcancel didn't work.

I've done a fair amount of testing of this behavior on Unix, including
strace'ing the run to make sure it did what I expected.  One thing
I noticed while doing that is that in worker processes, DisconnectDatabase
tends to send a cancel request before exiting, even if nothing went wrong.
This is at least a waste of cycles, and could lead to unexpected log
messages, or maybe even data loss if it happened in pg_restore.  I dug
into it and found that the reason is that after a COPY step, pg_dump was
leaving libpq in PGASYNC_BUSY state, causing PQtransactionStatus to report
PQTRANS_ACTIVE.  That's normally harmless because the next PQexec() will
silently clear the PGASYNC_BUSY state; but in a parallel worker we might
exit without any additional commands after a COPY.  The attached patch
adds an extra PQgetResult() call after a COPY to allow libpq to return to
PGASYNC_IDLE state.

I have not, however, tested the Windows side of this at all.

I think this is a bug fix and should be back-patched, but I'm not going
to risk committing it without review and testing of the Windows version.
Any volunteers?

regards, tom lane

diff --git a/src/bin/pg_dump/compress_io.c b/src/bin/pg_dump/compress_io.c
index 4cf0935..e0ef9cd 100644
*** a/src/bin/pg_dump/compress_io.c
--- b/src/bin/pg_dump/compress_io.c
***
*** 54,60 
  #include "postgres_fe.h"
  
  #include "compress_io.h"
- #include "parallel.h"
  #include "pg_backup_utils.h"
  
  /*--
--- 54,59 
*** void
*** 184,192 
  WriteDataToArchive(ArchiveHandle *AH, CompressorState *cs,
     const void *data, size_t dLen)
  {
- 	/* Are we aborting? */
- 	checkAborting(AH);
- 
  	switch (cs->comprAlg)
  	{
  		case COMPR_ALG_LIBZ:
--- 183,188 
*** ReadDataFro

Re: [HACKERS] Parallel safety tagging of extension functions

[Andreas Karlsson]

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 GiST
support functions.


I think as long as you already did the work, we should keep those updates.
I'm not totally convinced by Alexander's argument that those changes pose
a future hazard, but I'm not convinced he's wrong either.  If we're going
to be bumping a lot of contrib module versions anyway, it'd be silly to
take the risk that that's not a problem.


So how to best change the function signatures? I do not think it is 
possible without locking indexes by just using the SQL commands. You 
cannot drop a function from the operator family without dropping the 
operator class first.


Is the correct solution to manually update pg_amop with a new value for 
amopmethod?


Andreas


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Andreas Karlsson]

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 organization of the node)

would be represented as follows:

  fe80::1234%1
  ff02::5678%5
  ff08::9abc%10

(Here we assume a natural translation from a zone index to the
 part, where the Nth zone of any scope is translated into
"N".)

If we use interface names as , those addresses could also be
represented as follows:

 fe80::1234%ne0
 ff02::5678%pvc1.3
 ff08::9abc%interface10

The digit and string both are considered as proper format.


Since we cannot tell if %1 is the same interface as %ne0, isn't the best 
thing we can do to just store them as raw strings and treat them as 
different addresses from PostgreSQL's point of view? I do not see any 
problem with doing so.



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 may not be a straight
forward to store the zone id data.


This case needs to be handled by the parser for at least the cidr type, 
but I do not think it would make parsing any trickier.


Andreas


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 may not be a straight
>> forward to store the zone id data.

> This case needs to be handled by the parser for at least the cidr type, 
> but I do not think it would make parsing any trickier.

Unless there's a semantic difference between fe80::1%2/64 and
fe80::1/64%2, this doesn't seem like a big deal to me.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Kouhei Kaigai]

> -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 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 something similar. Maybe PL/R can create an
> >> extension within the R environment that wraps PL/CUDA directly or at the
> >> least provides a way to use a fast-path call. We should probably try to
> >> start out with one common use case to see how it might work and how much
> >> benefit there might be.
> >>
> > My thought is the second option above. If SPI interface supports fast-path
> > like 'F' protocol, it may become a natural way for other PLs also to
> > integrate SQL functions in other languages.
> >
> >>> IIUC, pg.spi.exec("SELECT my_function(...)") is the only way to call SQL 
> >>> functions
> >> inside PL/R scripts.
> >>
> >> Correct (currently).
> >>
> >> BTW, this is starting to drift off topic I think -- perhaps we should
> >> continue off list?
> >>
> > Some elements are common for PostgreSQL (matrix data type and fastpath SPI
> > interface). I like to keep the discussion on the list.
> > Regarding to the PoC on a particular use case, it might be an off-list
> > discussion.
> >
> > Thanks,
> > --
> > NEC Business Creation Division / PG-Strom Project
> > KaiGai Kohei 
> >
> Possibly there should be two matrix types in Postgres: the first would
> be the default and optimized for small dense matrices, the second would
> store large sparse matrices efficiently in memory at the expensive of
> speed (possibly with one or more parameters relating to how sparse it is
> likely to be?) - for appropriate definitions 'small' & 'large', though
> memory savings for the latter type might not kick in unless the matrices
> are big enough (so a small sparse matrix might consume more memory than
> a nominally larger dense matrix type & a sparse matrix might have to be
> sufficiently sparse to make real memory savings at any size).
>
One idea in my mind is that a sparse matrix is represented as a grid
of a smaller matrixes, and omit all-zero area. It looks like indirect
pointer reference. The header of matrix type has offset values to
each grid. If offset == 0, it means this grid contains all-zero.

Due to performance reason, location of each element must be deterministic
without walking on the data structure. This approach guarantees we can
reach individual element with 2 steps.

A flat matrix can be represented as a special case of the sparse matrix.
If entire matrix is consists of 1x1 grid, it is a flat matrix.
We may not need to define two individual data types.

> Probably good to think of 2 types at the start, even if the only the
> first is implemented initially.
>
I agree.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] foreign table batch inserts

[Amit Langote]

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 foreign_table(a,b,c) VALUES (1, 2, 3), (4, 5, 6)",
>> send the remote query "INSERT INTO remote_table(a,b,c) VALUES (1, 2, 3),
>> (4, 5, 6)" to the remote server where remote_table is the table name for
>> the foreign table on the remote server.  So, wouldn't the query string
>> length be a problem in many cases?  Maybe I'm missing something, though.
>> 
> 
> FDWs don't operate at that level. They don't see the original query string.
> They're plan nodes that operate with a row-by-row push/pull model. The
> foreign table node in question has no idea you're doing a multivalued
> insert and doesn't care if it's INSERT INTO ... SELECT, INSERT INTO ...
> VALUES, or COPY.

IIUC, what Fujita-san seems to be referring to here is safe push-down of a
insert's query or values expression (and hence the whole insert itself)
considered during the *planning* step.  Although that sounds like a
different optimization from  what's being discussed on this thread.  The
latter certainly seems to have its benefits in case of push-down failure
and might as well be the majority of cases.

Thanks,
Amit




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tsunakawa, Takayuki]

> 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 customer to the system documentation?
> 
> Personally I don't think standard system behavior should be documented for
> each application relying on it but ymmv.

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.  And I don't think 
there's suitable documentation on Windows.  Even if there is any, users will 
not be sure whether PostgreSQL follows those platform-specific conventions.  
They may have doubts about it, because even the product version "PostgreSQL 
x.y.z" causes misconception that x is the major version and y is the minor one.

So, I suggested documenting the compatibility policy for clarification and user 
friendliness as in the Oracle Database documentation below.

http://docs.oracle.com/database/121/UPGRD/app.htm#UPGRD12547


BTW, although this may be a separate topic, it may be better that we add the 
major version in the library names like libpq5.dll and libecpg6.dll, so that 
the application can fail to run with the incompatible versions of libpq and 
libecpg.  FYI:

https://en.wikipedia.org/wiki/Side-by-side_assembly

[Excerpt]
Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries. 
However, runtime libraries in Visual C++ 2010 no longer use this technology; 
instead, they include the version number of a DLL in its file name, which means 
that different versions of one DLL will technically be completely different 
DLLs now.


Any comments on these?  If there's no strong objection, I think I'll submit a 
documentation patch in the future.

Regards
Takayuki Tsunakawa


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers