Hello, Mark!
On Mon, Apr 3, 2017 at 7:00 PM, Mark Rofail wrote:
> Kindly find my proposal attached to this email.
>
I'd like to ask what do you mean in research item number 3?
3. Making the full-table sequential scan GIN-indexable instead seems very
> reasonable since
On 4/4/17 22:53, Vitaly Burovoy wrote:
> The next nitpickings to the last patch. I try to get places with
> lacking of variables' initialization.
> All other things seem good for me now. I'll continue to review the
> patch while you're fixing the current notes.
Committed with your changes (see
Kevin Grittner writes:
> Note that the final proposal is here:
> https://summerofcode.withgoogle.com/serve/5874530240167936/
I'm just getting a blank page at that URL?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hello. I found dubious behavior while playing with logical
replication.
When we disable a subscription, replication worker immediately stops.
=# ALTER SUBSCRIPTION s1 DISABLE;
On the other hand even if we enable a subscription, worker
doesn't start immediately. It takes 3 minutes in the worst
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2017-04-06 3:34 GMT+02:00 Stephen Frost :
> > Having the template not require the row/column place-holders included
> > strikes me as more likely to be confusing. My initial thinking around
> > this was that users
On 5 April 2017 at 18:48, Tom Lane wrote:
> Simon Riggs writes:
>> Collect and use multi-column dependency stats
>
> The buildfarm is unhappy about the fact that this changed the API
> for clauselist_selectivity(). I am not convinced that that change
>
Hi, Alexey!
On Tue, Mar 28, 2017 at 1:54 AM, Alexey Kondratov <
kondratov.alek...@gmail.com> wrote:
> Thank you for your responses and valuable comments!
>
> I have written draft proposal https://docs.google.com/document/d/1Y4mc_
> PCvRTjLsae-_fhevYfepv4sxaqwhOo4rlxvK1c/edit
>
> It seems that
On 05.04.2017 16:06, Arthur Zakirov wrote:
I'd like to focus on "refevalfunc" and "refnestedfunc" fields as I did
earlier. I think using Oid type for them is a bad approach. "..._fetch"
and "..._assign" functions in catalog is unnecessary movement to me.
User of subscript of his type may think
On Thu, Apr 6, 2017 at 5:37 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund wrote:
>
>> On 2017-04-03 11:56:13 -0700, Andres Freund wrote:
>> > Have you done x86 benchmarking?
>>
>> I think unless such benchmarking is
On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund wrote:
> On 2017-04-03 11:56:13 -0700, Andres Freund wrote:
> >
> > > +/*
> > > + * Generic implementation of pg_atomic_fetch_mask_add_u32() via loop
> > > + * of compare & exchange.
> > > + */
> > > +static inline uint32
> > >
On Sun, Apr 2, 2017 at 12:13 AM, Arseny Sher wrote:
> Time is short, student's application deadline is on 3rd April. I decided
> to reformulate the project scope myself. Here is the proposal:
>
> https://docs.google.com/document/d/1dvBETE6IJA9AcXd11XJNPsF_
>
On Thu, Apr 6, 2017 at 8:11 AM, Alexander Korotkov
wrote:
>> https://docs.google.com/document/d/1dvBETE6IJA9AcXd11XJNPsF_VPcDhSjy7rlsxj262l8/edit?usp=sharing
> I'd love to see a comment from Andres Freund who is leading executor
> performance improvements.
Note that
On Thu, Apr 6, 2017 at 1:18 AM, Amit Langote
wrote:
> On 2017/04/06 13:08, Keith Fiske wrote:
> > On Wed, Apr 5, 2017 at 2:51 PM, Keith Fiske wrote:
> >> Only issue I see with this, and I'm not sure if it is an issue, is what
> >> happens to that default constraint
Hi Robert,
> Hmm. I don't see anything wrong with that, particularly, but it seems
> we also don't need the distinction between XLOG_BTREE_SPLIT_L and
> XLOG_BTREE_SPLIT_L_ROOT or likewise between XLOG_BTREE_SPLIT_R and
> XLOG_BTREE_SPLIT_R_ROOT -- in which case I think this patch should go
> a
On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 06 Apr 2017 17:02:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170406.170214.263553093.horiguchi.kyot...@lab.ntt.co.jp>
>> At Thu, 6 Apr
Peter,
Can you perhaps initialize the variable 'address' to suppress the warning?
Thanks.
Mark Dilger
tablecmds.c:5984:6: warning: variable 'address' is used uninitialized whenever
'if' condition is false [-Wsometimes-uninitialized]
if (generatedEl)
^~~
On 06/04/17 14:24, Kyotaro HORIGUCHI wrote:
> Hello. I found dubious behavior while playing with logical
> replication.
>
> When we disable a subscription, replication worker immediately stops.
>
> =# ALTER SUBSCRIPTION s1 DISABLE;
>
> On the other hand even if we enable a subscription, worker
mark wrote:
> m=# create table mytable (myid serial, mytext text);
> CREATE TABLE
> m=# \d mytable
> ERROR: relation "pg_catalog.pg_statistic_ext" does not exist
> LINE 8: FROM pg_catalog.pg_statistic_ext stat WHERE starelid = '163...
> ^
Ah, what happens is you're using a new
On 04/06/2017 08:13 AM, Noah Misch wrote:
If any SCRAM open item is a beta blocker, it's this one. (But SASLprep is
also in or near that status.) Post-beta wire protocol changes are bad,
considering beta is normally the time for projects like pgjdbc and npgsql to
start adapting to such
On 4/6/17 10:59, Mark Dilger wrote:
> Can you perhaps initialize the variable 'address' to suppress the warning?
> Thanks.
A potential fix for this has been pushed.
> tablecmds.c:5984:6: warning: variable 'address' is used uninitialized
> whenever 'if' condition is false
> On Apr 6, 2017, at 8:33 AM, Peter Eisentraut
> wrote:
>
> On 4/6/17 10:59, Mark Dilger wrote:
>> Can you perhaps initialize the variable 'address' to suppress the warning?
>> Thanks.
>
> A potential fix for this has been pushed.
It works for me. Thanks
Kyotaro HORIGUCHI writes:
> I noticed by the following report, PostgreSQL can share the same
> directory as tablespaces of two servers with different
> pg-versions.
> https://www.postgresql.org/message-id/2008148.rxBNyNRHPZ@peanuts2
> 8.4 checked that the
Sorry, I didn't notice that this was going to a public list. That URL
is only available to people who signed up as mentors for PostgreSQL
GSoC participation this year. Does the link to the draft work for you?
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list
Joe Conway writes:
> I'm going to push the attached in a few hours unless there is any
> additional discussion. As stated above we'll do the regression changes
> in a separate patch once that is sorted. I used Tom's approach and
> comment wording for 0001a.
Looks generally
On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote
wrote:
> It seems pg_stat_progress_vacuum is not supposed to appear in the table
> titled "Collected Statistics Views". It was added by c16dc1aca. Attached
> patch fixes that.
Instead, it should appear in the table of
On 4/6/17 03:50, Craig Ringer wrote:
> But otherwise, pending docs changes, I think it's ready for committer.
My opinion is still that this is ultimately the wrong approach. The
right fix for performance issues in PL/Python is to change PL/Python not
to materialize the list of tuples. Now with
On 4/6/17 9:04 AM, Peter Eisentraut wrote:
On 4/6/17 03:50, Craig Ringer wrote:
But otherwise, pending docs changes, I think it's ready for committer.
My opinion is still that this is ultimately the wrong approach. The
right fix for performance issues in PL/Python is to change PL/Python not
On 4/5/17 21:32, Kyotaro HORIGUCHI wrote:
> At Wed, 5 Apr 2017 11:33:51 -0400, Peter Eisentraut
> wrote in
> <5401fef6-c0c0-7e8a-d8b1-169e30cbd...@2ndquadrant.com>
>> After further thinking, I prefer the alternative approach of using
>> pq_sendcountedtext() as
David Rowley writes:
> + *indexTotalCost += 0.1 * cpu_operator_cost * estimatedRanges *
> + pagesPerRange;
> This is trying to cost up the following code in bringetbitmap()
> if (addrange)
> {
> BlockNumber pageno;
> for (pageno = heapBlk;
> pageno <= heapBlk +
On 4/4/17 10:28, Robert Haas wrote:
> So is this patch going anywhere?
Not right now. It will take some time to sort out your feedback and do
some refactoring. I will close the patch for now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
Peter Eisentraut writes:
> On 4/6/17 03:50, Craig Ringer wrote:
>> But otherwise, pending docs changes, I think it's ready for committer.
> My opinion is still that this is ultimately the wrong approach. The
> right fix for performance issues in PL/Python is to
On 04/05/2017 02:29 PM, Mike Palmiotto wrote:
> I'm going to hold the partition table regression changes for a
> separate patch and include some ORDER BY fixes. Will post tomorrow
>
> In the meantime, attached are the latest and greatest patches.
I'm going to push the attached in a few hours
On Thu, Apr 6, 2017 at 7:30 AM, Rahila Syed wrote:
> Hello,
>
> Thanks a lot for testing and reporting this. Please find attached an
> updated patch with the fix. The patch also contains a fix
> regarding operator used at the time of creating expression as default
>
On 2/1/17 22:03, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 11:38 PM, Robert Haas wrote:
>> On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut
>> wrote:
>>> On 1/19/17 12:47 PM, Andrey Borodin wrote:
4. There is some controversy
Ashutosh Bapat writes:
> In ExecEvalConvertRowtype(), if the input row doesn't require any
> conversion, we simply return that row as is.
Huh. That's been like that for a very long time.
> I tried to create a testcase where this assertion would fail without
>
Robert Haas writes:
> ... But the underlying point here is that
> the only thing you really know about the function is that it's got to
> be a strategy-3 operator in some btree opclass; if that guarantees
> strictness, then so be it -- but I wasn't able to find anything in
On 06/04/17 16:44, Masahiko Sawada wrote:
> On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI
> wrote:
>> At Thu, 06 Apr 2017 17:02:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
>> wrote in
>>
On 4/6/17 07:13, Beena Emerson wrote:
> Does the options 16, 64 and 1024 seem good.
> We can remove sizes below 16 as most have agreed and as per the
> discussion, 64MB and 1GB seems favoured. We could probably allow 32MB
> since it was an already allowed size?
I don't see the need to remove
On Thu, Apr 6, 2017 at 5:51 AM, Andres Freund wrote:
> Hi,
>
> On 2017-03-30 13:10:41 +1100, Haribabu Kommi wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index 5d58f09..a29c108 100644
>> ---
apologies if someone has already reported this.
steps to reproduce.
install PG10 rpms.
create table.
using psql 10 \d the table.
note the error below.
m=# create table mytable (myid serial, mytext text);
CREATE TABLE
m=# \d mytable
ERROR: relation "pg_catalog.pg_statistic_ext" does not
Another version attached.
I think this is now in committable state, but there's been a lot of
small changes here and there, so please have one more look over it if
you have a chance. I'm planning to push this tomorrow, after sleeping on it.
The code-organization issue with the utf8
On 06/04/17 19:05, Heikki Linnakangas wrote:
On 04/06/2017 08:13 AM, Noah Misch wrote:
If any SCRAM open item is a beta blocker, it's this one. (But
SASLprep is
also in or near that status.) Post-beta wire protocol changes are bad,
considering beta is normally the time for projects like
2017-04-06 12:30 GMT+02:00 Andrew Dunstan :
>
>
> On 04/05/2017 05:41 PM, Andres Freund wrote:
> > On 2017-04-05 17:22:34 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> I'd like some input from other committers whether we want this.
Alvaro Herrera writes:
> mark wrote:
>> m=# create table mytable (myid serial, mytext text);
>> CREATE TABLE
>> m=# \d mytable
>> ERROR: relation "pg_catalog.pg_statistic_ext" does not exist
> Ah, what happens is you're using a new psql with a pre-10 server. Yeah,
>
On 3/29/17 19:01, Petr Jelinek wrote:
>> So this CREATE SUBSCRIPTION priv actually gives you the power to cause
>> the system to open network connections to the outside world. It's not
>> something you give freely to random strangers -- should be guarded
>> moderately tight, because it could be
On 04/06/2017 08:42 PM, Heikki Linnakangas wrote:
D'oh. Here's a new version, with saslprep.h included.
And here it is for real. Sigh.
There is for example this portion in the new tables:
+static const Codepoint prohibited_output_chars[] =
+{
+ 0xD800, 0xF8FF, /* C.3, C.5 */
it would appear that it didn't restart when I thought it had with the
service command.
apologies, I'm not able to reproduce anymore after restarting things.
On Thu, Apr 6, 2017 at 11:27 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > mark wrote:
2017-04-06 14:47 GMT+02:00 Stephen Frost :
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > 2017-04-06 3:34 GMT+02:00 Stephen Frost :
> > > Having the template not require the row/column place-holders included
> > > strikes me as more
On 4/5/17 12:26, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 12:18 PM, Peter Eisentraut
> wrote:
>> On 4/5/17 09:58, Robert Haas wrote:
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?
>>> That
On 4/5/17 19:14, Andres Freund wrote:
> Hi Peter,
>
> On 2017-02-28 22:30:16 -0800, Andres Freund wrote:
>> On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote:
>>> On 1/26/17 22:46, Andres Freund wrote:
On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote:
> Yeah, I have committed a
On 4/5/17 7:29 AM, Simon Riggs wrote:
> On 5 April 2017 at 06:04, Beena Emerson wrote:
>>
>> The WALfilename - LSN mapping disruption for higher values you mean? Is
>> there anything else I have missed?
>
> I see various issues raised but not properly addressed
>
> 1.
On 4/6/17 11:47, Peter Eisentraut wrote:
> On 4/5/17 21:32, Kyotaro HORIGUCHI wrote:
>> At Wed, 5 Apr 2017 11:33:51 -0400, Peter Eisentraut
>> wrote in
>> <5401fef6-c0c0-7e8a-d8b1-169e30cbd...@2ndquadrant.com>
>>> After further thinking, I prefer the
On 3/24/17 10:49, Petr Jelinek wrote:
> On 07/03/17 06:23, Petr Jelinek wrote:
>> there has been discussion at the logical replication initial copy thread
>> [1] about making apply work with sync commit off by default for
>> performance reasons and adding option to change that per
On 04/06/2017 08:29 AM, Tom Lane wrote:
> Joe Conway writes:
>> I'm going to push the attached in a few hours unless there is any
>> additional discussion. As stated above we'll do the regression changes
>> in a separate patch once that is sorted. I used Tom's approach and
>>
On 04/06/2017 08:36 AM, Noah Misch wrote:
On Tue, Mar 07, 2017 at 02:36:13PM +0200, Heikki Linnakangas wrote:
I didn't include the last-minute changes to the way you specify this in
pg_hba.conf. So it's still just "scram". I agree in general that we should
think about how to extend that too,
Joe Conway writes:
> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
> thinking not given the lack of past complaints but it might make sense
> to do.
I think 0001a absolutely needs to be, because it is fixing what is really
an ABI violation:
On 06/04/17 22:05, Tom Lane wrote:
Simon Riggs writes:
How would we provide the list of protocols? Surely the protocol is
defined by pg_hba.conf, which makes it dependent upon username,
database and ip range. If the list were accurate, it would allow an
attacker to
On 6 April 2017 at 16:05, Tom Lane wrote:
> Perhaps we could turn this around: have the client send (in the connection
> request packet) a list of auth protocols it thinks it is able to handle.
> (I'm envisioning this as being more or less fixed for any one version of
> any
On 2017-04-06 10:00:32 +0530, Dilip Kumar wrote:
> On Tue, Apr 4, 2017 at 5:51 AM, Dilip Kumar wrote:
> > Sure I can do that, In attached patch, I only fixed the problem of not
> > executing the bitmap test. Now, I will add few cases to cover other
> > parts especially
Hi,
On 2017-04-05 22:31:15 -0700, Serge Rielau wrote:
> Andres,
> Yes, I still want to push this in. However I have not had time to get back to
> it. I’m embarrassed to say that I don’t even know where the comments that
> were issued occurred.
> Cheers Serge
You mean
David Rowley writes:
> On 2 April 2017 at 21:21, David Rowley wrote:
>> I've attached an updated patch which updates the regression test output of
>> a recent commit to include the "Unique Inner" in the expected results.
> The patch
On 4 April 2017 at 02:02, Michael Paquier wrote:
> Hi all,
>
> There is still one open item pending for SCRAM that has not been
> treated which is mentioned here:
> https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi
>
> When doing an
Simon Riggs writes:
> How would we provide the list of protocols? Surely the protocol is
> defined by pg_hba.conf, which makes it dependent upon username,
> database and ip range. If the list were accurate, it would allow an
> attacker to discover how best to attack. If the
I'm a little confused on why a SELECT policy fires against the NEW record
for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem
to have that restriction.
DROP TABLE IF EXISTS t;
CREATE USER simple;
CREATE USER split;
CREATE TABLE t(value int);
grant select, update on table
Hi,
I've been looking at this issue today, and so far I don't think it's a
bug in the foreign key estimation. It seems mostly that the 9.5
estimates were hopelessly bad, and the join estimation changes simply
pushed it a tiny bit the wrong direction.
Although maybe there is a bug (or at
Hi,
On 2017-04-03 17:11:33 -0400, Robert Haas wrote:
> On Mon, Apr 3, 2017 at 3:31 PM, Andres Freund wrote:
> >> If this is 'make check', then we should have 8 parallel workers
> >> allowed, so if we only do one of these at a time, then I think we're
> >> OK. But if somebody
On 2/15/17 11:19, Peter Eisentraut wrote:
> So I would like to have a background worker limit per user, as you
> allude to. Attached is a patch that implements a GUC setting
> max_worker_processes_per_user.
>
> Besides the uses for background sessions, but it can also be useful for
> parallel
On 22 March 2017 at 14:58, Oleg Bartunov wrote:
> Should we reject this interesting project, which based on several years of
> research work of academician group in the institute ? May be better help him
> to reformulate the scope of project and let him work ? I don't know
I wrote:
> Ashutosh Bapat writes:
>> In ExecEvalConvertRowtype(), if the input row doesn't require any
>> conversion, we simply return that row as is.
> Huh. That's been like that for a very long time.
So I imagined that this was an ancient bug, and was
Andres Freund writes:
> I guess we'll have to see. My personal conclusion is that greater
> coverage of parallelism is worth some very minor config trouble for
> people doing installcheck against clusters with non-default config.
The buildfarm seems entirely unwilling to play
On Thu, Apr 6, 2017 at 2:05 PM, Andres Freund wrote:
> I'm not sure you entirely got my point here. If tuplesort_gettupleslot
> is called with copy = true, it'll store that tuple w/
> ExecStoreMinimalTuple passing shouldFree = copy = true. If the caller
> is in a short-lived
Tom Lane wrote:
> TBH, I think that code is in the noise. It doesn't involve any disk
> access, or catalog access, or user-defined function calls. I wouldn't
> bother trying to account for it.
I removed it in the pushed version.
> What you should be accounting for is the ensuing heap page
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote:
> Pushed with very minor wording changes.
This had a typo:
+ * If copy is true, the slot receives a copied tuple that'll that will stay
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
--
Sent via
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
wrote:
> I don't see it. The message AuthenticationSASL.String could contain a
> CSV of the SCRAM protocols supported. This is specially important to support
> channel binding (which is just another protocol name for
Hi,
I personally, and I know of a bunch of other regular contributors, find
context diffs very hard to read. Besides general dislike, for things
like regression test output context diffs are just not well suited.
E.g. in
On 7 April 2017 at 00:47, Simon Riggs wrote:
> On 5 April 2017 at 18:48, Tom Lane wrote:
>> Simon Riggs writes:
>>> Collect and use multi-column dependency stats
>>
>> The buildfarm is unhappy about the fact that this changed the
On 4/6/17 5:05 PM, Tomas Vondra wrote:
> On 04/06/2017 08:33 PM, David Steele wrote:
>> On 4/5/17 7:29 AM, Simon Riggs wrote:
>>
>>> 2. It's not clear to me the advantage of being able to pick varying
>>> filesizes. I see great disadvantage in having too many options, which
>>> greatly increases
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote:
> Pushed with very minor wording changes.
Thanks Andres.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, Apr 7, 2017 at 10:31 AM, Andres Freund wrote:
> Hi,
>
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
On 04/06/2017 06:31 PM, Andres Freund wrote:
> Hi,
>
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
> E.g. in
>
On 04/06/2017 11:45 PM, David Steele wrote:
On 4/6/17 5:05 PM, Tomas Vondra wrote:
On 04/06/2017 08:33 PM, David Steele wrote:
On 4/5/17 7:29 AM, Simon Riggs wrote:
2. It's not clear to me the advantage of being able to pick varying
filesizes. I see great disadvantage in having too many
On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
>>> If you ask me, I'd just leave:
>>>
>>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>>> DEFAULT_INEQ_SEL)
>>> + {
>>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
>>> implies
On 2017-04-04 13:49:11 -0700, Peter Geoghegan wrote:
> On Tue, Apr 4, 2017 at 1:32 PM, Andres Freund wrote:
> >> static bool
> >> tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
> >> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state,
>
On 04/06/2017 08:33 PM, David Steele wrote:
On 4/5/17 7:29 AM, Simon Riggs wrote:
On 5 April 2017 at 06:04, Beena Emerson wrote:
The WALfilename - LSN mapping disruption for higher values you mean? Is
there anything else I have missed?
I see various issues raised
On 04/06/2017 12:35 PM, Tom Lane wrote:
> Joe Conway writes:
>> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
>> thinking not given the lack of past complaints but it might make sense
>> to do.
>
> I think 0001a absolutely needs to be, because it is
On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
> Per the SCRAM RFC, it is the server who advertises and the client who
> picks.
Yes, but what does the RFC say about how to handle servers with an pg_hba.conf?
How and what will we advertise?
--
Simon Riggs
On 2017-04-06 20:43:48 +, Andres Freund wrote:
> Increase parallel bitmap scan test coverage.
>
> Author: Dilip Kumar
> Discussion:
> https://postgr.es/m/20170331184603.qcp7t4md5bzxb...@alap3.anarazel.de
This turned the !linux buildfarm red, because it relies on setting
On 2017-04-06 17:33:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I guess we'll have to see. My personal conclusion is that greater
> > coverage of parallelism is worth some very minor config trouble for
> > people doing installcheck against clusters with non-default
On 2017-03-13 18:14:07 -0700, Peter Geoghegan wrote:
> On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan wrote:
> > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote:
> >> Please. You might want to hit the existing ones with a separate patch,
> >> but it
On Fri, Apr 7, 2017 at 7:29 AM, Simon Riggs wrote:
> On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
>
>> Per the SCRAM RFC, it is the server who advertises and the client who
>> picks.
>
> Yes, but what does the RFC say about how to handle
At Thu, 6 Apr 2017 13:10:48 +1200, David Rowley
wrote in
>
> That echoes my perception - so let's move this to the next CF? It's not
> like this patch has been pending for very long.
>
sure
Regards
Pavel
>
> - Andres
>
On 06/04/17 03:51, Noah Misch wrote:
> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
>>> On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
Regarding this feature, there are some loose ends. We
On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote:
> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
>> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>> >> Regarding this
On Thu, Apr 6, 2017 at 1:33 AM, Heikki Linnakangas wrote:
> Attached is a new version. Notable changes since yesterday:
>
> * Implemented the rest of the SASLPrep, mapping some characters to spaces,
> leaving out others, and checking for prohibited characters and bidirectional
>
2017-04-06 8:08 GMT+02:00 Pavel Stehule :
>
>
> 2017-04-05 23:22 GMT+02:00 Tom Lane :
>
>> Andres Freund writes:
>> > I'd like some input from other committers whether we want this. I'm
>> > somewhat doubtful, but don't have
On 05/04/17 23:22, Tom Lane wrote:
> Andres Freund writes:
>> I'd like some input from other committers whether we want this. I'm
>> somewhat doubtful, but don't have particularly strong feelings.
>
> I don't really want to expose the workings of the plancache at user level.
On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI
wrote:
> I was thinking the same.
>
> At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada
> wrote in
On 6 April 2017 at 15:38, Craig Ringer wrote:
> Notes on the docs aside, I am pretty happy with this and think it's
> reasonable to proceed with it for Pg 10.
Actually, I'm a bit hesitant about returning a static struct that you
expect callers to copy and modify. But it
On 04/06/2017 08:33 AM, Noah Misch wrote:
On Fri, Mar 17, 2017 at 10:10:59AM +0900, Michael Paquier wrote:
On Fri, Mar 17, 2017 at 2:30 AM, Jeff Janes wrote:
On Thu, Mar 9, 2017 at 4:59 AM, Michael Paquier
wrote:
On Thu, Mar 9, 2017 at 1:17
1 - 100 of 197 matches
Mail list logo