Hi
2016-02-12 2:28 GMT+01:00 Vitaly Burovoy :
> Hello!
>
> On 2/11/16, Pavel Stehule wrote:
> > Hi
> >
> > assigned https://commitfest.postgresql.org/9/514/
> >
> > Regards
> > Pavel
>
>
> This patch was almost done by the end of the previous CF(2016-01):
> there was few little flaws which are s
On Thu, Feb 11, 2016 at 8:02 PM, Robert Haas wrote:
>
> On the substantive part of the patch, this doesn't look safe:
>
> +/*
> + * Add ourselves to the list of processes needing a group XID status
> + * update.
> + */
> +proc->clogGroupMember = true;
> +proc->clogGroupMemb
We're not out of the woods on this :-( ... jaguarundi, which is the first
of the CLOBBER_CACHE_ALWAYS animals to run these tests, didn't like them
at all. I think I fixed the deadlock-soft-2 failure, but its take on
deadlock-hard is:
*** 17,25
step s6a7: LOCK TABLE a7;
step s7a8: LOCK T
On Fri, Feb 12, 2016 at 12:39 AM, Robert Haas wrote:
>
> On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila
wrote:
> > Okay, changed as per suggestion.
>
> Looks good to me; committed.
>
Thanks!
Attached patch changes the name of some of the existing tranches
as suggested by you upthread.
With Re
On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-02-11 13:37:17 -0500, Tom Lane wrote:
>>> Absolutely; they don't work safely for testing bits that aren't in the
>>> rightmost byte of a flag word, for instance. I'm on board with making
>>> these fixes, I'm just
On Wed, Feb 10, 2016 at 10:55:10AM -0500, Tom Lane wrote:
> Interestingly, we seem to have managed to greatly reduce the "other"
> time (which I presume is basically mdpostchkpt unlinking) since 9.2.
> The worst case observed in HEAD is about 100s:
>
> regression=# select ts,write,sync,total-write
> On Tue, Feb 9, 2016 at 6:35 PM, Kouhei Kaigai wrote:
> > Unfortunately, it was not sufficient.
> >
> > Due to the assumption, the buffer page to be suspended does not exist
> > when a backend process issues a series P2P DMA command. (If block would
> > be already loaded to the shared buffer, it
On Fri, Feb 12, 2016 at 3:56 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>> On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote:
>>> - The GSSAPI authentication code has been moved without modification.
>>> In doing so, the temptation to modify it (flags, error checking, that
>>> b
Hello!
On 2/11/16, Pavel Stehule wrote:
> Hi
>
> assigned https://commitfest.postgresql.org/9/514/
>
> Regards
> Pavel
This patch was almost done by the end of the previous CF(2016-01):
there was few little flaws which are solved by now.
I have reviewed this patch.
It applies cleanly at the to
On Fri, Feb 12, 2016 at 2:41 AM, Fabien COELHO wrote:
>
> Hello Michaël,
>
>> +/* the argument list has been built in reverse order, it is fixed
>> here */
>> +expr->u.function.args = reverse_elist(args);
>> Hm. I may be missing something, but why is that necessary? This is
>> basically do
On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote:
> On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote:
>> On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote:
>> > I'll commit the attached tomorrow if there are no other concerns voiced.
>>
>> Just a nitpick regarding this block:
>
On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote:
> On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote:
> > I'll commit the attached tomorrow if there are no other concerns voiced.
>
> Just a nitpick regarding this block:
> + if (strchr(p, '/') != NULL)
> + p
On Fri, Feb 12, 2016 at 2:46 AM, Robert Haas wrote:
> On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes wrote:
>> I did not bump the extension version. I realized the migration file
>> would be empty, as there no change to SQL-level functionality (the new
>> s2k-count is parsed out of a string down i
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Thursday, February 11, 2016 1:26 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Andres Freund; Amit Kapila; pgsql-hackers
> Subject: Re: CustomScan in a larger
David Rowley writes:
> [ prune_group_by_clause_ab4f491_2016-01-23.patch ]
> [ check_functional_grouping_refactor.patch ]
I've committed this with mostly-cosmetic revisions (principally, rewriting
a lot of the comments, which seemed on the sloppy side).
>> * Both of the loops iterating over the g
On Fri, Feb 12, 2016 at 2:56 AM, Robert Haas wrote:
> On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier
> wrote:
>> So, here are some thoughts to make that more user-friendly. I think
>> that the critical issue here is to properly flatten the meta data in
>> the custom language and represent it pro
On Thu, Feb 11, 2016 at 10:53 AM, Pavel Stehule
wrote:
> > most recent error in verbose mode, without making a permanent session
>
>> > state change. Something like
>> >
>> > regression=# insert into bar values(1);
>> > ERROR: insert or update on table "bar" violates foreign key constraint
>> "
Hi hackers,
What do you think about improving cache replacement clock-sweep algorithm in
PostgreSQL with adaptive version proposed in this article:
http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf
Are there some well known drawbacks of this approach or it will be interesting
to adopt t
On Thu, Feb 11, 2016 at 9:53 AM, Robert Haas wrote:
> The fact that InitLocks() doesn't do this has been discussed before
> and there's no consensus on changing it. It is, at any rate, a
> separate issue. I'll go through the rest of this patch again now.
I did a little bit of cleanup on this pa
On Wed, Feb 3, 2016 at 12:32 PM, Masahiko Sawada wrote:
> I've divided the main patch into two patches; add frozen bit patch and
> pg_upgrade support patch.
> 000 patch is almost same as previous code. (includes small fix)
> 001 patch provides rewriting visibility map as a pageConverter routine.
On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila wrote:
> Okay, changed as per suggestion.
Looks good to me; committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Thu, Feb 11, 2016 at 1:44 PM, Andres Freund wrote:
> On 2016-02-04 16:54:58 +0100, Andres Freund wrote:
>> Fabien asked me to post a new version of the checkpoint flushing patch
>> series. While this isn't entirely ready for commit, I think we're
>> getting closer.
>>
>> I don't want to post a
Michael Paquier writes:
> On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote:
>>
>> - The GSSAPI authentication code has been moved without modification.
>> In doing so, the temptation to modify it (flags, error checking, that
>> big comment at the top about things from Athena, etc.) is
Andres Freund writes:
> On 2016-02-11 13:37:17 -0500, Tom Lane wrote:
>> Absolutely; they don't work safely for testing bits that aren't in the
>> rightmost byte of a flag word, for instance. I'm on board with making
>> these fixes, I'm just unconvinced that stdbool is a good reason for it.
> Oh
On Thu, Feb 11, 2016 at 1:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote:
>>> Well, I can't do anything about that right now. I won't have the time to
>>> whip up the new/more complex API we discussed upthread in the next few
>>> days. So ei
On 2016-02-04 16:54:58 +0100, Andres Freund wrote:
> Fabien asked me to post a new version of the checkpoint flushing patch
> series. While this isn't entirely ready for commit, I think we're
> getting closer.
>
> I don't want to post a full series right now, but my working state is
> available on
Robert Haas writes:
> On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote:
>> Well, I can't do anything about that right now. I won't have the time to
>> whip up the new/more complex API we discussed upthread in the next few
>> days. So either we go with a simpler API (e.g. pretty much a cleane
On 2016-02-11 13:37:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And anyway, these macros are a potential issue even without stdbool.h
> > style booleans.
>
> Absolutely; they don't work safely for testing bits that aren't in the
> rightmost byte of a flag word, for instance. I'm on boa
Andres Freund writes:
> And anyway, these macros are a potential issue even without stdbool.h
> style booleans.
Absolutely; they don't work safely for testing bits that aren't in the
rightmost byte of a flag word, for instance. I'm on board with making
these fixes, I'm just unconvinced that stdb
On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote:
>> > Putting it on the open items list sounds good to me.
>>
>> Well, OK, I've done that then. I don't really agree that it's not a
>> problem; the OP said he saw a 3x regression, and some of my colleagues
>> doing benchmarking are complaining
On 2016-02-11 13:09:27 -0500, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 12:53 PM, Andres Freund wrote:
> >> One problem is that it makes for misleading results if you try to
> >> benchmark 9.5 against 9.6.
> >
> > You need a really beefy box to show the problem. On a large/new 2 socket
> > mach
On 2016-02-11 13:06:14 -0500, Tom Lane wrote:
> But I'm unconvinced that we need to make our .c files prepared for
> stdbool.h to be #included in them.
The fixes, besides two stylistic edits around !! use, are all in
headers. The issue is that we return things meant to be used in a
boolean context
On Thu, Feb 11, 2016 at 8:42 AM, Michael Paquier
wrote:
> + * Portions Copyright (c) 2015-2016, Red Hat, Inc.
> + * Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
> I think that this part may be a problem... Not sure the feeling of the
> others regarding additional copyright
On Thu, Feb 11, 2016 at 12:53 PM, Andres Freund wrote:
>> One problem is that it makes for misleading results if you try to
>> benchmark 9.5 against 9.6.
>
> You need a really beefy box to show the problem. On a large/new 2 socket
> machine the performance regression in in the 1-3% range for a pgb
Andres Freund writes:
> On 2016-02-11 09:51:26 -0500, Robert Haas wrote:
>> I have never been quite clear on what you think is going to cause
>> stdbool.h inclusions to become more common.
> Primarily because it's finally starting to be supported across the
> board, thanks to MS finally catching
On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier
wrote:
> So, here are some thoughts to make that more user-friendly. I think
> that the critical issue here is to properly flatten the meta data in
> the custom language and represent it properly in a new catalog,
> without messing up too much with t
> most recent error in verbose mode, without making a permanent session
> > state change. Something like
> >
> > regression=# insert into bar values(1);
> > ERROR: insert or update on table "bar" violates foreign key constraint
> "bar_f1_fkey"
> > DETAIL: Key (f1)=(1) is not present in table "f
On 2016-02-11 12:50:58 -0500, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 12:48 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I think we should either get this fixed RSN or revert the problematic
> >> commit until we get it fixed. I'd be rather disappointed about the
> >> latter because I th
On Thu, Feb 11, 2016 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think we should either get this fixed RSN or revert the problematic
>> commit until we get it fixed. I'd be rather disappointed about the
>> latter because I think this was a very good thing on the merits, but
>> probab
On Tue, Jan 5, 2016 at 10:16 PM, Tom Lane wrote:
> Jim Nasby writes:
>> FWIW, I suspect very few people know about the verbosity setting (I
>> didn't until a few months ago...) Maybe psql should hint about it the
>> first time an error is reported in a session.
>
> Actually, what'd be really hand
Robert Haas wrote:
So, is it being pulled in indirectly by some other #include?
I can double-check it tomorrow.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Robert Haas writes:
> I think we should either get this fixed RSN or revert the problematic
> commit until we get it fixed. I'd be rather disappointed about the
> latter because I think this was a very good thing on the merits, but
> probably not good enough to justify taking the performance hit
On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes wrote:
> pgcrypto supports s2k-mode for key-stretching during symmetric
> encryption, and even defaults to s2k-mode=3, which means configurable
> iterations. But it doesn't support s2k-count to actually set those
> iterations to be anything other than
Hi Magnus,
thanks for working on this topic.
What it does is very similar to what Barman's pgespresso extension does and I'd
like to see it implemented soon in the core.
I've added myself as reviewer for the patch on commitfest site.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
Post
2016-02-11 18:29 GMT+01:00 Magnus Hagander :
> Most of the pl/pgsql functions and variables are prefixed plpgsql_, so
> they don't risk conflicting with other shared libraries loaded.
>
> There are a couple that are not prefixed. Attached patch fixes that. It's
> mostly a cleanup, but I think it's
Hello Michaël,
+/* the argument list has been built in reverse order, it is fixed here */
+expr->u.function.args = reverse_elist(args);
Hm. I may be missing something, but why is that necessary? This is
basically doing a double-reversion to put all the arguments in the
correct order whe
On Thu, Feb 11, 2016 at 9:54 AM, Andres Freund wrote:
> On 2016-02-11 09:51:26 -0500, Robert Haas wrote:
>> I have never been quite clear on what you think is going to cause
>> stdbool.h inclusions to become more common.
>
> Primarily because it's finally starting to be supported across the
> boar
Most of the pl/pgsql functions and variables are prefixed plpgsql_, so they
don't risk conflicting with other shared libraries loaded.
There are a couple that are not prefixed. Attached patch fixes that. It's
mostly a cleanup, but I think it's something we should do since it's only 2
variables and
On Thu, Jan 14, 2016 at 12:28 PM, Tom Lane wrote:
> Andres Freund writes:
>> This brings me to something related: I'm wondering if we shouldn't merge
>> unix/win32_latch.c.
>
> Well, it's duplicated code on the one hand versus maze-of-ifdefs on the
> other. Feel free to try it and see, but I'm u
On Thu, Feb 11, 2016 at 12:04 PM, Tom Lane wrote:
> I wrote:
>> No, because the machines that are failing are showing a ""
>> annotation that your reference output *doesn't* have. I think what is
>> actually happening is that these machines are seeing the process as
>> waiting and reporting it, w
On Thu, Feb 11, 2016 at 6:45 PM, Robert Haas wrote:
>
> On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila
wrote:
> > Sounds sensible, however after changes, CreateLWLocks() started
> > looking unreadable, so moved initialization and registration of tranches
> > to separate functions.
>
> Seems good.
>
I wrote:
> No, because the machines that are failing are showing a ""
> annotation that your reference output *doesn't* have. I think what is
> actually happening is that these machines are seeing the process as
> waiting and reporting it, whereas on your machine the backend detects
> the deadlock
02.02.2016 15:50, Anastasia Lubennikova:
31.01.2016 11:04, David Rowley:
On 27 January 2016 at 03:35, Anastasia Lubennikova
wrote:
including_columns_3.0 is the latest version of patch.
And changes regarding the previous version are attached in a
separate patch.
Just to ease the review and de
On 02/11/2016 07:55 AM, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs wrote:
>> If you make max_worker_processes USERSET won't everybody just set it to
>> max_worker_processes?
>
> I think that you meant for the first instance of max_worker_processes
> in that sentence to be
On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs wrote:
> A few questions and thoughts to help decide...
>
> Does it take into account the parallel degree during planning?
> Does it take into account the actual parallel degree during planning?
max_worker_processes is a query planner GUC, just like w
Robert Haas writes:
>> That would be great. Taking a look at what happened, I have a feeling
>> this may be a race condition of some kind in the isolation tester. It
>> seems to have failed to recognize that a1 started waiting, and that
>> caused the "deadlock detected" message to reported diffe
On 11 February 2016 at 12:40, Thom Brown wrote:
> Hi all,
>
> As it currently stands, max_parallel_degree is set to a superuser
> context, but we probably want to discuss whether we want to keep it
> this way prior to releasing 9.6. Might we want to reduce its level so
> that users can adjust it
Thank you, committed
Jim Nasby wrote:
On 1/2/16 5:57 PM, Jim Nasby wrote:
Attached patch clarifies that %-related error messages with hints as
well as (IMHO) improving the clarity of the message:
Sorry, forgot to update regression tests. New patch attached.
--
Teodor Sigaev
On 11 February 2016 at 13:18, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote:
>> As it currently stands, max_parallel_degree is set to a superuser
>> context
>
> I don't have a clue why it's like that. It seems like it should be
> PGC_USERSSET just like, say, work_mem. I
1 - sml_limit to similarity_limit. sml_threshold is difficult to write I think,
similarity_limit is more simple.
It seems to me that threshold is right word by meaning. sml_threshold is my
choice.
2 - subword_similarity() to word_similarity().
Agree, according to Mike Rylander opinion in this
On 2016-02-11 09:51:26 -0500, Robert Haas wrote:
> I have never been quite clear on what you think is going to cause
> stdbool.h inclusions to become more common.
Primarily because it's finally starting to be supported across the
board, thanks to MS finally catching up.
Then there's uglyness like
On Thu, Feb 11, 2016 at 9:11 AM, Aleksander Alekseev
wrote:
>> Thanks, this looks way better. Some more comments:
>>
>> - I don't think there's any good reason for this patch to change the
>> calling convention for ShmemInitHash(). Maybe that's a good idea and
>> maybe it isn't, but it's a separ
On Thu, Feb 11, 2016 at 9:15 AM, Andres Freund wrote:
> On 2016-02-11 08:50:41 -0500, Robert Haas wrote:
>> Are we thinking to back-patch this? I would be disinclined to
>> back-patch widespread changes like this. If there's a specific
>> instance related to Gin where this is causing a tangible
Thank you for reviewing this patch!
On Wed, Feb 10, 2016 at 4:39 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 4 Feb 2016 02:32:29 +0900, Masahiko Sawada
> wrote in
>> On Tue, Feb 2, 2016 at 7:22 PM, Alvaro Herrera
>> wrote:
>> > Masahiko Sawada wrote:
>> >> I think we have two options.
On Thu, Feb 11, 2016 at 9:36 AM, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 9:29 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Add some isolation tests for deadlock detection and resolution.
>>
>> Buildfarm says this needs work ...
>>
>> dromedary is one of mine, do you need me to look into w
Thom Brown writes:
> At the moment, if we try to set up a configuration parameter for a
> user which doesn't make sense in that context, we get an error message
> that doesn't really tell us that we're not allowed to set it for
> users:
> # ALTER ROLE moo SET log_line_prefix = '%s';
> ERROR: para
On Thu, Feb 11, 2016 at 9:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> Add some isolation tests for deadlock detection and resolution.
>
> Buildfarm says this needs work ...
>
> dromedary is one of mine, do you need me to look into what is
> happening?
That would be great. Taking a look at w
On Thu, Feb 11, 2016 at 9:04 AM, Robert Haas wrote:
>> Is there anything, I can do to move this forward?
>
> Well, looking at this again, I think I'm OK to go with your names.
> That doesn't seem like the thing to hold up the patch for. So I'll go
> ahead and push the renaming patch now.
On the
On 2016-02-11 08:50:41 -0500, Robert Haas wrote:
> Are we thinking to back-patch this? I would be disinclined to
> back-patch widespread changes like this. If there's a specific
> instance related to Gin where this is causing a tangible problem, we
> could back-patch just that part, with a clear
Hello, Robert
> Thanks, this looks way better. Some more comments:
>
> - I don't think there's any good reason for this patch to change the
> calling convention for ShmemInitHash(). Maybe that's a good idea and
> maybe it isn't, but it's a separate issue from what this patch is
> doing, and if
On Tue, Feb 9, 2016 at 11:14 PM, Amit Kapila wrote:
>> Patches still apply 1 month later.
>
> Thanks for verification!
>
>>
>> I don't really have an opinion on the variable naming. I guess they
>> only need making longer if there's going to be some confusion about
>> what they're for,
>
> makes
On Tue, Feb 9, 2016 at 11:53 PM, Michael Paquier
wrote:
> On Wed, Feb 10, 2016 at 1:17 AM, Yury Zhuravlev
> wrote:
>> I've just run into a problem with these macro. Function ginStepRight breaks
>> completely when compiled using the MSVC2013 and MSVC2015 (since these
>> releases use C99's bools bu
On 11.02.2016 16:35, Mike Rylander wrote:
On Thu, Feb 11, 2016 at 8:11 AM, Teodor Sigaev wrote:
I have attached a new version of the patch. It fixes error of operators
<->> and
%>:
- operator <->> did not pass the regression test in CentOS 32 bit (gcc
4.4.7
20120313).
- operator %> did not pass
On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote:
> For your consideration, here is a new version of GSSAPI encryption
> support. For those who prefer, it's also available on my github:
> https://github.com/frozencemetery/postgres/commit/c92275b6605d7929cda5551de47a4c60aab7179e
Yeah! Glad t
On 11.02.2016 16:11, Teodor Sigaev wrote:
I have attached a new version of the patch. It fixes error of
operators <->> and
%>:
- operator <->> did not pass the regression test in CentOS 32 bit (gcc
4.4.7
20120313).
- operator %> did not pass the regression test in FreeBSD 32 bit (gcc
4.2.1
200708
On Thu, Feb 11, 2016 at 8:11 AM, Teodor Sigaev wrote:
>> I have attached a new version of the patch. It fixes error of operators
>> <->> and
>> %>:
>> - operator <->> did not pass the regression test in CentOS 32 bit (gcc
>> 4.4.7
>> 20120313).
>> - operator %> did not pass the regression test in
On Thu, Feb 11, 2016 at 12:37 AM, Fabien COELHO wrote:
> v26 attached implements these changes.
+/* the argument list has been built in reverse order, it is fixed here */
+expr->u.function.args = reverse_elist(args);
Hm. I may be missing something, but why is that necessary? This is
basic
W dniu 11.02.2016 o 14:06, Rich Jones pisze:
> Hello, team!
>
> I am writing on behalf of the BPGSQL Project [1] to request a code audit
> from a core PGSQL team member.
>
> The current maintainer is worried about the security of the code, and is
> considering closing the project unless it can be
Hi,
At the moment, if we try to set up a configuration parameter for a
user which doesn't make sense in that context, we get an error message
that doesn't really tell us that we're not allowed to set it for
users:
# ALTER ROLE moo SET log_line_prefix = '%s';
ERROR: parameter "log_line_prefix" ca
On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote:
> As it currently stands, max_parallel_degree is set to a superuser
> context, but we probably want to discuss whether we want to keep it
> this way prior to releasing 9.6. Might we want to reduce its level so
> that users can adjust it according
On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila wrote:
> Sounds sensible, however after changes, CreateLWLocks() started
> looking unreadable, so moved initialization and registration of tranches
> to separate functions.
Seems good.
> Increased number of tranches allocated in LWLockTrancheArray, as
I have attached a new version of the patch. It fixes error of operators <->> and
%>:
- operator <->> did not pass the regression test in CentOS 32 bit (gcc 4.4.7
20120313).
- operator %> did not pass the regression test in FreeBSD 32 bit (gcc 4.2.1
20070831).
It was because of variable optimizati
Hello, team!
I am writing on behalf of the BPGSQL Project [1] to request a code audit
from a core PGSQL team member.
The current maintainer is worried about the security of the code, and is
considering closing the project unless it can be properly reviewed [2]. As
a project living downstream[3] o
Hi all,
As it currently stands, max_parallel_degree is set to a superuser
context, but we probably want to discuss whether we want to keep it
this way prior to releasing 9.6. Might we want to reduce its level so
that users can adjust it accordingly? They'd still be limited by
max_worker_processe
The behavior of this function is surprising to me.
select substring_similarity('dog' , 'hotdogpound') ;
substring_similarity
--
0.25
Substring search was desined to search similar word in string:
contrib_regression=# select substring_similarity('dog' ,
Thinking about this some more though, perhaps *sorting* the columns is
> the wrong way to be thinking about it. Perhaps a better approach would
> be to allow the columns to be *listed* (optionally, using a separate
> query). Something like the following (don't get too hung up on the
> syntax):
>
>
On 11 February 2016 at 08:43, Andres Freund wrote:
> On 2016-02-09 09:27:04 +, Dean Rasheed wrote:
>> Looking at this patch, I have mixed feelings about it. On the one hand
>> I really like the look of the output, and I can see that the non-fixed
>> nature of the output columns makes this hard
Thank you for the review.
On 10.02.2016 19:46, Teodor Sigaev wrote:
I duplicate the patch here.
it's very good thing to update disctionaries to support modern versions.
And thank you for improving documentation. Also I've impressed by long
description in spell.c header.
Som notices about co
Hi
2016-02-11 7:44 GMT+01:00 Vitaly Burovoy :
> On 2/10/16, Pavel Stehule wrote:
> > Hi Vitaly,
> >
> > please, can you send your version of this patch, how we talked about it
> in
> > Moscow?
> >
> > Thank you
> >
> > Pavel
>
> Hello, Pavel!
>
> Please find attached my version of the patch (it
Hi
assigned https://commitfest.postgresql.org/9/514/
Regards
Pavel
This is last incarnation of my patch (cleaned and refactored by Vitaly Burovoy)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2016-02-11 7:44 GMT+01:00 Vitaly Burovoy :
> On 2/10/16, Pavel Stehule wrote:
> > Hi Vitaly,
> >
> > please, can you send your version of this patch, how we talked about it
> in
> > Moscow?
> >
> > Thank you
> >
> > Pavel
>
> Hello, Pavel!
>
> Please find attached my version of the patch (it appl
On Thu, Feb 11, 2016 at 5:20 PM, Andres Freund wrote:
> On 2016-02-11 09:25:30 +0530, Amit Kapila wrote:
>> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier
>> wrote:
>> >
>> > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila
>> wrote:
>> > > Okay, but isn't it better that we remove the snapshot tak
On 2016-02-09 09:27:04 +, Dean Rasheed wrote:
> Looking at this patch, I have mixed feelings about it. On the one hand
> I really like the look of the output, and I can see that the non-fixed
> nature of the output columns makes this hard to achieve server-side.
> But on the other hand, this s
On 2016-02-11 09:25:30 +0530, Amit Kapila wrote:
> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier
> wrote:
> >
> > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila
> wrote:
> > > Okay, but isn't it better that we remove the snapshot taken
> > > at checkpoint time in the main branch or till where th
On Wed, Feb 10, 2016 at 8:51 PM, Robert Haas wrote:
>
> On Wed, Feb 10, 2016 at 1:32 AM, Amit Kapila
wrote:
> > The reason for using centralized way is that we need to request
> > named tranches before initialization of shared memory and as far as
> > I can see, currently there is no way in the s
On 11.02.2016 03:33, Tom Lane wrote:
Artur Zakirov writes:
[ tsearch_aff_parse_v1.patch ]
I've pushed this with some corrections --- notably, I did not like the
lack of buffer-overrun prevention, and it did the wrong thing if a line
had more than one trailing space character.
We still need
On 11.02.2016 01:19, Tom Lane wrote:
I wrote:
Artur Zakirov writes:
I think this is not a bug. It is a normal behavior. In Mac OS sscanf()
with the %s format reads the string one character at a time. The size of
letter 'Ñ…' is 2. And sscanf() separate it into two wrong characters.
That argu
98 matches
Mail list logo
