On Tue, Apr 26, 2016 at 10:09 PM, Christian Ullrich
wrote:
> The first patch passes the value of the MSBFLAGS environment variable to
> msbuild's command line.
>
> The output of parallel and sequential builds has identical file count and
> size after installing; all tests pass.
If a committer is
On Tue, Apr 26, 2016 at 2:24 PM, Tom Lane wrote:
> Now, whether using END is really an improvement is a separate question.
> I have the impression that END calls happen in a better-defined order,
> but I'm not a perl monk.
For the archive's sake, 08af9219 is the result commit.
--
Michael
--
S
On Wed, Apr 27, 2016 at 12:08 PM, Joe Conway wrote:
> On 04/26/2016 07:23 PM, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 9:35 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'm not prepared to commit this over the objection offered by Tomas
Vondra on that thread.
>>>
>>> FWIW, I agree
On Wed, Apr 27, 2016 at 12:25 AM, Robert Haas wrote:
> In other words, I think Masahiko Sawada's patch in the original post
> is pretty much right on target, except that we don't need to do that
> always, but rather only in the FPI case when the call to
> visibilitymap_pin() is being optimized awa
A later thought:
On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> src/bin/pg_dump: make check
>
> implemented using the TAP testing system. There are a total of 360
> tests, generally covering:
>
> Various invalid sets of command-line options.
>
> Valid command-line options (ge
On Wed, Apr 27, 2016 at 10:14 AM, Kyotaro HORIGUCHI
wrote:
> I just added a comment in the v9.
Sorry, I have attached an empty patch. This is another one that should
be with content.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
fix_sync_rep_update_conf_v9.patch
Description:
On 27 April 2016 at 15:12, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 10:57 PM, David Rowley
> wrote:
>> On 27 April 2016 at 14:30, Robert Haas wrote:
>>> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
wrote:
> I'd also have ex
Hi,
On 2016-04-25 20:53:26 +0200, Fabien COELHO wrote:
> I have just a small naming point:
>
> /* ereport if segment not present, create in recovery */
> EXTENSION_FAIL,
> /* return NULL if not present, create in recovery */
> EXTENSION_RETURN_NULL,
> /* return NULL if not present */
>
On 2016/04/26 21:45, Etsuro Fujita wrote:
While re-reviewing the fix, I noticed that since PQcancel we added to
pgfdw_xact_callback to cancel a DML pushdown query isn't followed by a
ROLLBACK, the connection to the remote server will be discarded at the
end of the while loop in that function, whi
On Tue, Apr 26, 2016 at 10:57 PM, David Rowley
wrote:
> On 27 April 2016 at 14:30, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
>>> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
>>> wrote:
I'd also have expected the output of both partial nodes to be the
s
On 04/26/2016 07:23 PM, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 9:35 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'm not prepared to commit this over the objection offered by Tomas
>>> Vondra on that thread.
>>
>> FWIW, I agree with Peter that we should remove this code. We know that it
On 2016-04-27 14:57:24 +1200, David Rowley wrote:
> "private" is reserved in C++? I understood we want our C code to
> compile as C++ too, right? or did I get my wires crossed somewhere?
Just headers. Our C code unfortunately is very far away from being C++
compliant.
--
Sent via pgsql-hackers
On 27 April 2016 at 14:30, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
>> wrote:
>>> I'd also have expected the output of both partial nodes to be the
>>> same, i.e. both prefixed with PARTIAL. Is it intended that they
On Tue, Apr 26, 2016 at 1:24 AM, Ashutosh Sharma wrote:
> In PGSQL-9.6, if we create a function with PARALLEL clause and try
> displaying it's definition using "pg_get_functiondef" we see that the
> PARALLEL keyword used during function creation is missing.
>
> Below are the steps to reproduce:
>
On Mon, Apr 11, 2016 at 12:16 PM, Robert Haas wrote:
> The PostgreSQL 9.6 release management team has determined that
> PostgreSQL 9.6beta1 should wrap on May 9, 2016 for release on May
> 12,2016, ...
Update: It looks like this plan is going to stick. So, the plan of
record is still to wrap 9.6b
On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
> wrote:
>> I'd also have expected the output of both partial nodes to be the
>> same, i.e. both prefixed with PARTIAL. Is it intended that they don't?
>> or have I made some other mistake?
>
> No,
On Tue, Apr 26, 2016 at 9:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not prepared to commit this over the objection offered by Tomas
>> Vondra on that thread.
>
> FWIW, I agree with Peter that we should remove this code. We know that it
> is buggy. Leaving it there constitutes an "attr
Robert Haas wrote:
> On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> > Working up a patch to remove these checks should be pretty quickly done
> > (iirc, I've actually got an independent patch around from when I added
> > them, just need to find it and then go through the committed patche
On Mon, Apr 25, 2016 at 11:52:04AM -0700, Andres Freund wrote:
> On 2016-04-23 21:54:07 -0400, Noah Misch wrote:
> > The bug is that the pg_atomic_compare_exchange_*() specifications
> > grant "full barrier semantics", but generic-xlc.h provided only the
> > semantics of an acquire barrier.
>
> I
On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
wrote:
> I'd also have expected the output of both partial nodes to be the
> same, i.e. both prefixed with PARTIAL. Is it intended that they don't?
> or have I made some other mistake?
No, that's a defect in the patch. I didn't consider that we need
Robert Haas writes:
> I'm not prepared to commit this over the objection offered by Tomas
> Vondra on that thread.
FWIW, I agree with Peter that we should remove this code. We know that it
is buggy. Leaving it there constitutes an "attractive nuisance" --- that
is, I'm afraid that someone will
Hello,
At Tue, 26 Apr 2016 09:57:50 +0530, Amit Kapila wrote
in
> > > > Amit Kapila writes:
> > > > > The main point for this improvement is that the handling for guc
> > s_s_names
> > > > > is not similar to what we do for other somewhat similar guc's and
> > which
> > > > > causes in-efficie
On 27 April 2016 at 12:37, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 6:44 PM, David Rowley
> wrote:
>> On 27 April 2016 at 08:46, Robert Haas wrote:
>>> My proposed fix for this issue is attached. Review is welcome;
>>> otherwise, I'll just commit this. The output looks like what I
>>> sugg
On Wed, Apr 27, 2016 at 10:00 AM, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 8:45 PM, Bruce Momjian wrote:
>> On Fri, Mar 11, 2016 at 05:36:34PM +, Robert Haas wrote:
>>> pg_upgrade: Convert old visibility map format to new format.
>>>
>>> Commit a892234f830e832110f63fc0a2afce2fb21d1584 add
On Sat, Mar 12, 2016 at 08:33:55PM +0300, Vladimir Borodin wrote:
> That’s why proposal included GUC for that with a default to turn timings
> measuring off. I don’t remember any objections against that.
>
> And I’m absolutely sure that a real highload production (which of course
> doesn’t use vir
On Tue, Apr 26, 2016 at 8:45 PM, Bruce Momjian wrote:
> On Fri, Mar 11, 2016 at 05:36:34PM +, Robert Haas wrote:
>> pg_upgrade: Convert old visibility map format to new format.
>>
>> Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
>> page to the visibility map, but pg_up
On Tue, Apr 26, 2016 at 05:37:40PM -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Noah Misch wrote:
> > > The above-described topic is currently a PostgreSQL 9.6 open item.
> > > Alvaro,
> > > since you committed the patch believed to have created it, you own this
> > > open
> > > item
On Tue, Apr 26, 2016 at 6:44 PM, David Rowley
wrote:
> On 27 April 2016 at 08:46, Robert Haas wrote:
>> My proposed fix for this issue is attached. Review is welcome;
>> otherwise, I'll just commit this. The output looks like what I
>> suggested upthread:
>
> + if (!aggref->aggpartial)
> + elog
On Tue, Apr 26, 2016 at 7:54 PM, Peter Geoghegan wrote:
> On Tue, Apr 26, 2016 at 4:47 PM, Robert Haas wrote:
>>> You don't want to remove buggy code that is currently unused simply
>>> because it might be useful to have that functionality in the future?
>>
>> No, I don't want to remove code that
On Tue, Apr 26, 2016 at 4:47 PM, Robert Haas wrote:
>> You don't want to remove buggy code that is currently unused simply
>> because it might be useful to have that functionality in the future?
>
> No, I don't want to remove code that somebody thinks we should fix
> instead of removing on your sa
On Tue, Apr 26, 2016 at 7:46 PM, Peter Geoghegan wrote:
> On Tue, Apr 26, 2016 at 4:41 PM, Robert Haas wrote:
>> I'm not prepared to commit this over the objection offered by Tomas
>> Vondra on that thread.
>
> You don't want to remove buggy code that is currently unused simply
> because it might
On Tue, Apr 26, 2016 at 4:41 PM, Robert Haas wrote:
> I'm not prepared to commit this over the objection offered by Tomas
> Vondra on that thread.
You don't want to remove buggy code that is currently unused simply
because it might be useful to have that functionality in the future?
--
Peter Ge
On Mon, Apr 25, 2016 at 10:39 PM, Peter Geoghegan wrote:
> The function hyperLogLogMerge() is faulty [1]. It has no current
> callers, though. I propose that we rip it out, as in the attached
> patch.
>
> [1]
> http://www.postgresql.org/message-id/CAM3SWZT-i6R9JU5YXa8MJUou2_r3LfGJZpQ9tYa1BYxfkj0=
On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> Based on our discussion at PGConf.US and the comments up-thread from
> Tom, I'll work up a patch to remove those checks around SET ROLE and
> friends which were trying to prevent default roles from possibly being
> made to own objects.
>
> Sh
On 27 April 2016 at 08:46, Robert Haas wrote:
> My proposed fix for this issue is attached. Review is welcome;
> otherwise, I'll just commit this. The output looks like what I
> suggested upthread:
+ if (!aggref->aggpartial)
+ elog(ERROR, "referenced Aggref is not partial");
I think this is ov
Robert Haas writes:
> On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky wrote:
>> Sure. I'd consider sending in a patch, but as this is a protocol-changing
>> feature it seems like working on this before the team "officially" starts
>> working on a new protocol might be a waste of time. Once there'
On 2016-04-26 17:25:18 -0400, Robert Haas wrote:
> On Mon, Apr 25, 2016 at 4:57 PM, Andres Freund wrote:
> > On 2016-04-25 16:29:36 -0400, Robert Haas wrote:
> >> On Mon, Apr 25, 2016 at 2:05 PM, Andres Freund wrote:
> >> > Well, I posted a patch. I'd have applied it too (after addressing your
>
On Mon, Apr 25, 2016 at 4:57 PM, Andres Freund wrote:
> On 2016-04-25 16:29:36 -0400, Robert Haas wrote:
>> On Mon, Apr 25, 2016 at 2:05 PM, Andres Freund wrote:
>> > Well, I posted a patch. I'd have applied it too (after addressing your
>> > comments obviously), except that there's some interdep
On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky wrote:
> Sure. I'd consider sending in a patch, but as this is a protocol-changing
> feature it seems like working on this before the team "officially" starts
> working on a new protocol might be a waste of time. Once there's critical
> mass for a ne
Robert Haas writes:
> My proposed fix for this issue is attached. Review is welcome;
> otherwise, I'll just commit this. The output looks like what I
> suggested upthread:
I haven't read the patch, but the sample output looks sane.
regards, tom lane
--
Sent via pgsql
On Mon, Apr 25, 2016 at 1:03 PM, Robert Haas wrote:
> Yeah, I'd be happy to have more people chime in. I think your example
> is interesting, but it doesn't persuade me, because the rule has
> always been that EXPLAIN shows the output *columns*, not the output
> *rows*. The disappearance of some
Alvaro Herrera wrote:
> Noah Misch wrote:
>
> > The above-described topic is currently a PostgreSQL 9.6 open item. Alvaro,
> > since you committed the patch believed to have created it, you own this open
> > item. If that responsibility lies elsewhere, please let us know whose
> > responsibility
Craig Ringer wrote:
> The reason the new src/test/recovery/ tests don't notice this is that using
> pg_recvlogical from the TAP tests is currently pretty awkward.
> pg_recvlogical has no way to specify a stop-point or return when there's no
> immediately pending data like the SQL interface does. S
On 2016-04-26 17:22:49 -0300, Alvaro Herrera wrote:
> > - /* oldest LSN that might be required by this replication slot */
> > + /*
> > +* oldest LSN that might be required by this replication slot.
> > +*
> > +* Points to the LSN of the most recent xl_running_xacts record where
> >
Craig Ringer wrote:
> - /* oldest LSN that the client has acked receipt for */
> + /*
> + * oldest LSN that the client has acked receipt for
> + *
> + * Decoding will start calling output plugin callbacks for commits
> + * after this LSN unless a different start point i
On Fri, Apr 22, 2016 at 11:44 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
>> > Would you agree that it'd be helpful to have for making the st_union()
>> > work better in parallel?
>>
>> For our part
On Sun, Apr 24, 2016 at 8:16 PM, Andrew Dunstan wrote:
> Note that the json type, unlike jsonb, preserves exactly the white space and
> key order of its input. In fact, the input is exactly what it stores.
That is true, but the json serialization functions (to_json etc)
really out to have the sam
* Christian Ullrich wrote:
wrong even without considering the debug/release split. If we load a
compiled extension built with a CRT we have not seen yet, _after_ the
first call to pgwin32_putenv(), that module's CRT's view of its
environment will be frozen because we will never attempt to update
There are some previously unnoticed errors in docs (master branch), this patch
fixes them.
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers maili
Check my reasoning: In version 4 I added a remebering of tail of pending
list into blknoFinish variable. And when we read page which was a tail on
cleanup start then we sets cleanupFinish variable and after cleaning that
page we will stop further cleanup. Any insert caused during cleanup will be
p
* Ryan Pedela (rped...@datalanche.com) wrote:
> On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni wrote:
> > The default text representation of jsonb adds whitespace in between
> > key/value pairs (after the colon ":") and after successive properties
> > (after the comma ","):
[...]
> > It'd be n
On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni wrote:
> Hi,
>
> The default text representation of jsonb adds whitespace in between
> key/value pairs (after the colon ":") and after successive properties
> (after the comma ","):
>
> postgres=# SELECT '{"b":2,"a":1}'::jsonb::text;
>text
On 04/26/2016 11:26 AM, Tom Lane wrote:
> OK, I've pushed a change along these lines. Peter, would you see whether
> HEAD fixes it for you?
Yeah, it passes now. Nobody touch anything! ;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On 26 April 2016 at 16:26, Tom Lane wrote:
> The next time somebody proposes that we can get exact results out of
> floating-point arithmetic, I'm going to run away screaming.
>
Yeah, I think I will have the same reaction.
Thanks for all your hard work getting this to work.
Regards,
Dean
--
On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> I still think
>> max_parallel_workers is confusingly similar to max_worker_processes,
>> but nothing's going to make everyone completely happy here.
>
> Well, what was suggested upthread was to change all of these to follo
On Tue, Apr 26, 2016 at 11:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
>>> The next time somebody proposes that we can get exact results out of
>>> floating-point arithmetic, I'm going to run away screaming.
>
>> And you wonder why I avoid fl
Robert Haas writes:
> I still think
> max_parallel_workers is confusingly similar to max_worker_processes,
> but nothing's going to make everyone completely happy here.
Well, what was suggested upthread was to change all of these to follow
the pattern max_foo_workers or max_foo_worker_processes,
On Tue, Apr 26, 2016 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
>> wrote:
>>> I think the word "degree" is largely seen as a bad idea: it would become
>>> a somewhat better idea only if we change how it works so that it matches
>>> what
Robert Haas writes:
> On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
>> The next time somebody proposes that we can get exact results out of
>> floating-point arithmetic, I'm going to run away screaming.
> And you wonder why I avoid floating point variables like the plague...!
Float variable
Robert Haas writes:
> On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
> wrote:
>> I think the word "degree" is largely seen as a bad idea: it would become
>> a somewhat better idea only if we change how it works so that it matches
>> what other DBMSs do, but you oppose that. Hence my proposal t
On Tue, Apr 26, 2016 at 11:26 AM, Tom Lane wrote:
> The next time somebody proposes that we can get exact results out of
> floating-point arithmetic, I'm going to run away screaming.
And you wonder why I avoid floating point variables like the plague...!
--
Robert Haas
EnterpriseDB: http://www.
On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
>> wrote:
>
>> > What about calling it something even simpler, such as "max_parallelism"?
>> > This avoids such cargo cult, and there's no implication that it's
>> > per
Dean Rasheed writes:
> On 26 April 2016 at 04:25, Tom Lane wrote:
>> In short, these tests suggest that we need a coding pattern like
>> this:
>> volatile float8 asin_x = asin(x);
>> return (asin_x / asin_0_5) * 30.0;
> Agreed. That looks like the least hacky way of solving the problem. I
> thin
On Mon, Apr 25, 2016 at 2:10 PM, Andres Freund wrote:
> Afaics the problem described below was introduced in b4e07417, do you
> have a different/better proposal than
> s/CacheInvalidateSmgr/CacheInvalidateRelcache/? Doing that doesn't feel
> quite right either, because it only makes the file exten
Robert Haas wrote:
> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
> wrote:
> > What about calling it something even simpler, such as "max_parallelism"?
> > This avoids such cargo cult, and there's no implication that it's
> > per-query.
>
> So what would we call the "parallel_degree" member o
On Mon, Apr 25, 2016 at 11:06:11PM -0700, 陈天舟 wrote:
> I am interested in adding Protocol Buffer support for Postgres. Protocol
> Buffer occupies less space than JSON. More importantly, it has schema and
> is forward/backward compatible. All these make it a very good format for
> persistency.
Than
2016-04-25 19:40 GMT+02:00 Bruce Momjian :
>
> Good summary. Is there a TODO item here?
>
no, it is not
Regars
Pavel
>
> ---
>
> On Tue, Mar 15, 2016 at 08:17:07PM -0400, Tom Lane wrote:
> > Pavel Stehule writes:
> > >>
On 26 April 2016 at 04:48, Andres Freund wrote:
> No, I think we got to do this in all branches. I was just wondering
> about how to fix vm_extend(). Which I do think we got to fix, even in
> the back-branches.
>
I think replacing CacheInvalidateSmgr() with CacheInvalidateRelcache()
in vm_extend(
On Tue, Apr 26, 2016 at 6:40 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 26 April 2016 at 14:06, 陈天舟 wrote:
>>> (1) Since each protocol buffer column requires a schema. I am not sure
>>> where is the best place to store that schema info. Should it be in a
>>> CONSTRAINT (but I am not able t
Craig Ringer writes:
> On 26 April 2016 at 14:06, é天è wrote:
>> (1) Since each protocol buffer column requires a schema. I am not sure
>> where is the best place to store that schema info. Should it be in a
>> CONSTRAINT (but I am not able to find the doc referring any custom
>> constraint)
While working with postgres code, I found that for gist index number of
amsupport procs are defined two times. First in src/include/access/gist.h
#define GISTNProcs 9
and second in src/backend/access/gist/gist.c
amroutine->amsupport = 9;
I think this number should be
On my system, "build DEBUG" takes ~2.75 minutes. When I tell MSBuild to
build in parallel by passing it the /m flag, that goes down to 1.5 minutes.
The first patch passes the value of the MSBFLAGS environment variable to
msbuild's command line.
The output of parallel and sequential builds has
On 2016/04/26 12:52, Robert Haas wrote:
On Mon, Apr 25, 2016 at 2:54 AM, Ashutosh Bapat
wrote:
Thinking loudly:
This error is hard to interpret for a user who doesn't know about ctid. Till
we find a solution, we can at least fail gracefully with an error something
like "DMLs are not supported
Hi,
While re-reviewing the fix, I noticed that since PQcancel we added to
pgfdw_xact_callback to cancel a DML pushdown query isn't followed by a
ROLLBACK, the connection to the remote server will be discarded at the
end of the while loop in that function, which will cause a FATAL error
of "co
On 04/26/2016 08:06 AM, 陈天舟 wrote:
I am interested in adding Protocol Buffer support for Postgres.
Protocol Buffer occupies less space than JSON. More importantly, it
has schema and is forward/backward compatible. All these make it a
very good format for persistency.
Have you investigated JSO
On 26 April 2016 at 04:25, Tom Lane wrote:
> In short, these tests suggest that we need a coding pattern like
> this:
>
> volatile float8 asin_x = asin(x);
> return (asin_x / asin_0_5) * 30.0;
>
> We could drop the "volatile" by adopting -ffloat-store, but that
> doesn't seem like
Hi,
Knowing that pg_basebackup always creates an empty directory for
pg_stat_tmp and pg_replslot in backup location, even i think it would be
better to handle these directories in such a way that pg_basebackup
generates an empty directory for pg_replslot and pg_stat_tmp if they are
symbolic link.
On 2016-04-15 04:35, Amit Langote wrote:
A quick test with:
0001-Add-syntax-to-specify-partition-key-v3.patch
0002-Infrastructure-for-creation-of-partitioned-tables-v3.patch
0003-Add-syntax-to-create-partitions-v3.patch
0004-Infrastructure-for-partition-metadata-storage-and-ma-v3.patch
0005-Int
On Tue, Apr 26, 2016 at 10:34 AM, Daniel Gustafsson wrote:
> Theres a tiny typo in the EXAMPLE section of the documentation in
> execProcnode.c:
>
> - * their work to the appopriate node support routines which may
> + * their work to the appropriate node support routines which may
>
Applied,
Theres a tiny typo in the EXAMPLE section of the documentation in
execProcnode.c:
- * their work to the appopriate node support routines which may
+ * their work to the appropriate node support routines which may
cheers ./daniel
execProcnode-type.diff
Description: Binary data
--
Sent via
On Apr 26, 2016 4:41 AM, "Tom Lane" wrote:
>
> Andreas Karlsson writes:
> > On 04/17/2016 09:28 PM, Bill Moran wrote:
> >> What I believe is happening, is that the pg connection libs
> >> first try to connect via ssl and get a password failed error,
> >> then fallback to trying to connect without
81 matches
Mail list logo
