On 09/02/16 07:15, Andrew Borodin wrote:
Hi, hackers!
I want to propose improvement of GiST page layout.
GiST is optimized to reduce disk operations on search queries, for
example, windows search queries in case of R-tree.
I expect that more complicated page layout will help to tradeoff some
o
On Thu, Jan 28, 2016 at 1:01 AM, Masahiko Sawada wrote:
> On Wed, Jan 27, 2016 at 4:42 PM, Fujii Masao wrote:
>> On Tue, Jan 26, 2016 at 9:33 PM, Masahiko Sawada
>> wrote:
>>> Hi all,
>>>
>>> In concurrently refreshing materialized view, we check whether that
>>> materialized view has suitable
Hi Michaël,
Attached 19-d and 19-e.
+/* return builtin script "name", or fail if not found */
builtin does not sound like correct English to me, but built-in is.
I notice that "man bash" uses "builtin" extensively, so I think it is okay
like that, but I would be fine as well with "built-in
On Tue, Feb 9, 2016 at 5:37 AM, Michael Paquier
wrote:
>
> On Mon, Feb 8, 2016 at 11:24 PM, Amit Kapila
wrote:
> > On Mon, Feb 8, 2016 at 12:28 PM, Michael Paquier <
michael.paqu...@gmail.com>
> > wrote:
> >>
> >>
> >> >> /*
> >> >> + * Fetch the progress position before taking any WAL
Hi
> I just rechecked the thread. In my reading, lots of people argued
> whether it should be called \rotate or \pivot or \crosstab; it seems the
> \crosstabview proposal was determined to be best. I can support that
> decision. But once the details were discussed, it was only you and
> Daniel
Hi, hackers!
I want to propose improvement of GiST page layout.
GiST is optimized to reduce disk operations on search queries, for
example, windows search queries in case of R-tree.
I expect that more complicated page layout will help to tradeoff some
of CPU efficiency for disk efficiency.
GiST
Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid), which
is returned as is in UserMapping object. I confused InvalidOid with -1.
Sorry for the confusion.
On Tue, Feb 9, 2016 at 10:21 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Sorry to come to this late.
> > The userid b
On Tue, Feb 9, 2016 at 4:22 AM, Fabien COELHO wrote:
>> + /* compute total_weight */
>> + for (i = 0; i < num_scripts; i++)
>> + {
>> + total_weight += sql_script[i].weight;
>> +
>> + /* detect overflow... */
>> If let as int64, you may want to remove
Ashutosh Bapat writes:
> Sorry to come to this late.
> The userid being printed is from UserMapping. The new API
> GetUserMappingById() allows an FDW to get user mapping by its OID. This API
> is intended to be used by FDWs to fetch the user mapping inferred by the
> core for given join between fo
On Tue, Feb 9, 2016 at 1:22 PM, Ashutosh Bapat
wrote:
> The userid being printed is from UserMapping. The new API
> GetUserMappingById() allows an FDW to get user mapping by its OID. This API
> is intended to be used by FDWs to fetch the user mapping inferred by the
> core for given join between f
On Tue, Feb 9, 2016 at 1:16 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 9 Feb 2016 00:48:57 +0900, Fujii Masao wrote
> in
>> On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
>> > wrote:
>> >> On Thu, Feb 4, 2016 at 10:49 PM,
Sorry to come to this late.
The userid being printed is from UserMapping. The new API
GetUserMappingById() allows an FDW to get user mapping by its OID. This API
is intended to be used by FDWs to fetch the user mapping inferred by the
core for given join between foreign relations. In such user map
Hi Suraj,
On 2016/02/09 12:16, kharagesuraj wrote:
> Hello,
>
>
>>> I agree with first version, and attached the updated patch which are
>>> modified so that it supports simple multiple sync replication you
>>> suggested.
>>> (but test cases are not included yet.)
>
> I have tried for some bas
Hello,
At Tue, 9 Feb 2016 00:48:57 +0900, Fujii Masao wrote in
> On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
> wrote:
> > On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
> > wrote:
> >> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
> >> wrote:
> >>> On Thu, Feb 4, 2016 at 10:40 PM, R
On Tue, Feb 9, 2016 at 12:16 PM, kharagesuraj
wrote:
> Hello,
>
>
>
>
>
> >> I agree with first version, and attached the updated *patch* which are
> >> modified so that it supports simple multiple sync replication you
> >>suggested.
> >> (but test cases are not included yet.)
>
>
>
> I have trie
On Mon, Feb 8, 2016 at 8:16 PM, Andres Freund wrote:
>
> On 2016-02-08 10:38:55 +0530, Amit Kapila wrote:
> > I think deciding it automatically without user require to configure it,
> > certainly has merits, but what about some cases where user can get
> > benefits by configuring themselves like t
Noah Misch writes:
> On Mon, Feb 08, 2016 at 02:15:48PM -0500, Tom Lane wrote:
>> We've seen variants
>> on this theme on half a dozen machines just in the past week --- and it
>> seems to mostly happen in 9.5 and HEAD, which is fishy.
> It has been affecting only the four AIX animals, which do s
On Mon, Feb 8, 2016 at 8:11 PM, Robert Haas wrote:
>
> On Mon, Feb 8, 2016 at 12:08 AM, Amit Kapila
wrote:
> > I think deciding it automatically without user require to configure it,
> > certainly has merits, but what about some cases where user can get
> > benefits by configuring themselves like
On Mon, Feb 08, 2016 at 02:15:48PM -0500, Tom Lane wrote:
> Of late, by far the majority of the random-noise failures we see in the
> buildfarm have come from failure to shut down the postmaster in a
> reasonable timeframe.
> We've seen variants
> on this theme on half a dozen machines just in the
Hello,
>> I agree with first version, and attached the updated patch which are
>> modified so that it supports simple multiple sync replication you
>>suggested.
>> (but test cases are not included yet.)
I have tried for some basic in-built test cases for multisync rep.
I have created one patch o
On 2016/02/09 6:46, Magnus Hagander wrote:
> On Mon, Feb 8, 2016 at 10:19 PM, Alvaro Herrera
> wrote:
>
>> Hi everybody,
>>
>> I just closed the last few remaining items in the commitfest. This is
>> the final summary:
>>
>> Committed: 32.
>> Moved to next CF: 32.
>> Rejected: 2.
>> Returned
On Mon, Feb 8, 2016 at 11:24 PM, Amit Kapila wrote:
> On Mon, Feb 8, 2016 at 12:28 PM, Michael Paquier
> wrote:
>>
>>
>> >> /*
>> >> + * Fetch the progress position before taking any WAL insert lock.
>> >> This
>> >> + * is normally an operation that does not take long, but leavin
Hi!
Thanks for the answer. Sounds good.
On 2016-02-08 18:47:18 -0500, Robert Haas wrote:
> and if I'd gone out of my way to say "hey, everybody, here's a patch
> that you might want to object to" I'm sure I could have found some
> volunteers to do just that. But, you know, that's not really what
On Mon, Feb 8, 2016 at 5:27 PM, Andres Freund wrote:
>> > contentious issue, a few days after the initial post. Hm. Not sure how
>> > you'd react if you weren't the author.
>>
>> Probably not very well. Do you want me to revert it?
>
> No. I want(ed) to express that I am not comfortable with how
On Mon, Feb 8, 2016 at 2:33 PM, Filip Rembiałkowski
wrote:
> Here is my next try, after suggestions from -perf and -hackers list:
>
> * no GUC
>
> * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT
>
> * corresponding, 3-argument version of pg_notify(text,text,bool)
This is all sounding pret
>
> I think that's an argument to enable it till at least beta1. Let's
>> change the default, and add an item to the open items list to reconsider
>> then.
>>
>>
>
+1 during the beta, +0.95 for default thereafter.
I think that most databases in the past have defaulted to single-core
unless otherwi
On 2/8/16 4:19 PM, Alvaro Herrera wrote:
>
> I'm closing this commitfest now. We even have three weeks before the
> next one starts, so everybody can take a break for once! Yay!
Many thanks, Álvaro!
By the way, I would be happy to manage the next commitfest. I've been
watching the process for
On Mon, Feb 8, 2016 at 2:35 PM, Andres Freund wrote:
> I think having a public git tree, that contains the current state, is
> greatly helpful for that. Just announce that you're going to screw
> wildly with history, and that you're not going to be terribly careful
> about commit messages. That m
On 2016-02-08 15:18:13 -0500, Robert Haas wrote:
> I agree that you had to be pretty deeply involved in that thread to
> follow everything that was going on. But it's not entirely fair to
> say that it was impossible for anyone else to get involved. Both
> Amit and I, mostly Amit, posted directi
Hi Robert,
On 2016-02-08 13:45:37 -0500, Robert Haas wrote:
> > I realize that this stuff has all been brewing long, and that there's
> > still a lot to do. So you gotta keep moving. And I'm not sure that
> > there's anything wrong or if there's any actually better approach. But
> > pushing an unr
On Mon, Feb 8, 2016 at 4:54 PM, Peter Geoghegan wrote:
> On Mon, Feb 8, 2016 at 1:45 PM, Robert Haas wrote:
>> Far from the negligence that you seem to be implying, I think Amit was
>> remarkably diligent about providing these kinds of updates.
>
> I don't think I remotely implied negligence. Tha
Alvaro Herrera writes:
> I'm closing this commitfest now. We even have three weeks before the
> next one starts, so everybody can take a break for once! Yay!
Yay! And thanks for running this one --- I know it's a mighty
tedious and thankless task.
regards, tom lane
-
On Mon, Feb 8, 2016 at 1:45 PM, Robert Haas wrote:
> Far from the negligence that you seem to be implying, I think Amit was
> remarkably diligent about providing these kinds of updates.
I don't think I remotely implied negligence. That word has very severe
connotations (think "criminal negligence
On Monday, February 8, 2016, Andres Freund wrote:
> Hi,
>
> On 2016-02-08 16:07:05 -0500, Robert Haas wrote:
> > One of the questions I have about parallel query is whether it should
> > be enabled by default. That is, should we make the default value of
> > max_parallel_degree to a value higher
On Mon, Feb 8, 2016 at 10:19 PM, Alvaro Herrera
wrote:
> Hi everybody,
>
> I just closed the last few remaining items in the commitfest. This is
> the final summary:
>
> Committed: 32.
> Moved to next CF: 32.
> Rejected: 2.
> Returned with Feedback: 33.
> Total: 99.
>
> I think we did a fair
On Mon, Feb 8, 2016 at 4:11 PM, Peter Geoghegan wrote:
> All that I wanted to do was look at EXPLAIN ANALYZE output that showed
> a parallel seq scan on my laptop, simply because I wanted to see a
> cool thing happen. I had to complain about it [1] to get clarification
> from you [2].
>
> I accept
Pavel Stehule wrote:
> > FWIW I think the general idea of this feature (client-side resultset
> > "pivoting") is a good one, but I don't really have an opinion regarding
> > your specific proposal. I think you should first seek some more
> > consensus about the proposed design; in your original t
On Mon, Feb 8, 2016 at 1:24 PM, Andres Freund wrote:
> I think that's an argument to enable it till at least beta1. Let's
> change the default, and add an item to the open items list to reconsider
> then.
+1.
Reminds me of what happened with the num_xloginsert_locks GUC (it was
eventually replac
Robert Haas writes:
> One of the questions I have about parallel query is whether it should
> be enabled by default. That is, should we make the default value of
> max_parallel_degree to a value higher than 0? Perhaps 1, say?
I'm not sure I'm on board with that as a releaseable default, but the
On 02/08/2016 01:11 PM, Peter Geoghegan wrote:
On Mon, Feb 8, 2016 at 12:18 PM, Robert Haas wrote:
I accept that this might have been a somewhat isolated incident (that
I couldn't easily get *at least* a little instant gratification), but
it still should be avoided. You've accused me of buryi
On Tue, Feb 9, 2016 at 9:26 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Would num_values be a better name than num_nonnulls?
>
> If "value" is a term that excludes null values, it's news to me.
Ah, right, I was thinking of null as the absence of a value. But in
fact it is a special value that
Hi,
On 2016-02-08 16:07:05 -0500, Robert Haas wrote:
> One of the questions I have about parallel query is whether it should
> be enabled by default. That is, should we make the default value of
> max_parallel_degree to a value higher than 0? Perhaps 1, say?
>
> There are some good reasons why
Hi
> FWIW I think the general idea of this feature (client-side resultset
> "pivoting") is a good one, but I don't really have an opinion regarding
> your specific proposal. I think you should first seek some more
> consensus about the proposed design; in your original thread [1] several
> guys
Hi everybody,
I just closed the last few remaining items in the commitfest. This is
the final summary:
Committed: 32.
Moved to next CF: 32.
Rejected: 2.
Returned with Feedback: 33.
Total: 99.
I think we did a fairly decent job this time around: we only passed a
third of the patches to the
On 02/08/2016 01:07 PM, Robert Haas wrote:
Hi,
One of the questions I have about parallel query is whether it should
be enabled by default. That is, should we make the default value of
max_parallel_degree to a value higher than 0? Perhaps 1, say?
O.k. after some googling where I found your f
On Mon, Feb 8, 2016 at 12:18 PM, Robert Haas wrote:
> So, there may be a person who knows how to do all of that
> work and get it done in a reasonable time frame and also knows how to
> make sure that everybody has the opportunity to be as involved in the
> process as they want to be and that ther
Hi,
One of the questions I have about parallel query is whether it should
be enabled by default. That is, should we make the default value of
max_parallel_degree to a value higher than 0? Perhaps 1, say?
There are some good reasons why this might be a bad idea, such as:
- As discussed on a nea
Pavel Stehule wrote:
> I am looking on it
Thanks, closing as returned-with-feedback.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Daniel Verite wrote:
> Teodor Sigaev wrote:
>
> > Interesting feature, but it's not very obvious how to use it. I'd like to
> > see some example(s) in documentation.
>
> I'm thinking of making a wiki page, because examples pretty much
> require showing resultsets, and I'm not sure this wou
On 02/08/2016 02:15 PM, Tom Lane wrote:
Of late, by far the majority of the random-noise failures we see in the
buildfarm have come from failure to shut down the postmaster in a
reasonable timeframe. An example is this current failure on hornet:
http://buildfarm.postgresql.org/cgi-bin/show_st
On 02/08/2016 09:33 PM, Filip Rembiałkowski wrote:
> Here is my next try, after suggestions from -perf and -hackers list:
>
> * no GUC
>
> * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT
>
> * corresponding, 3-argument version of pg_notify(text,text,bool)
>
> * updated the docs to inclu
Joe Conway wrote:
> On 01/06/2016 10:36 AM, Tom Lane wrote:
> > I think a design that was actually somewhat robust would require two
> > hooks, one at check_role and one at assign_role, wherein the first one
> > would do any potentially-failing work and package all required info into
> > a blob tha
Alvaro Herrera writes:
> Tom Lane wrote:
>> What I'd like to do to investigate this is put in a temporary HEAD-only
>> patch that makes ShutdownXLOG() and its subroutines much chattier about
>> how far they've gotten and what time it is, and also makes pg_ctl print
>> out the current time if it gi
Thomas,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Tue, Feb 9, 2016 at 5:30 AM, Joe Conway wrote:
> > On 02/08/2016 06:24 AM, Andres Freund wrote:
> >> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
> >>> Now that there is a setting to give a cluster a "name", it would be nice
Tom Lane wrote:
> Of late, by far the majority of the random-noise failures we see in the
> buildfarm have come from failure to shut down the postmaster in a
> reasonable timeframe.
I noticed that.
> An example is this current failure on hornet:
>
> http://buildfarm.postgresql.org/cgi-bin/show_s
On Tue, Feb 9, 2016 at 5:30 AM, Joe Conway wrote:
> On 02/08/2016 06:24 AM, Andres Freund wrote:
>> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
>>> Now that there is a setting to give a cluster a "name", it would be nice to
>>> have an escape sequence in the log_line_prefix setting that could
On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer wrote:
> Would it be correct to say that if ALL is specified then a message is queued
> no matter what. If DISTINCT is specified then it is only queued if no
> message with the same channel and argument is already queued for delivery.
Yes, exactly.
>
Thomas Munro writes:
> Would num_values be a better name than num_nonnulls?
If "value" is a term that excludes null values, it's news to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Peter Geoghegan writes:
> On Sun, Feb 7, 2016 at 7:47 AM, Tom Lane wrote:
>> Works for me.
> Attached patch is what I came up with. It required only minimal
> additional changes for consistency.
I'd already run into some trouble with pgindent messing up on "string",
so I went ahead and pushed t
On Mon, Feb 8, 2016 at 2:48 PM, Peter Geoghegan wrote:
> FWIW, I appreciate your candor. However, I think that you could have
> done a better job of making things easier for reviewers, even if that
> might not have made an enormous difference. I suspect I would have not
> been able to get UPSERT d
On Fri, Feb 5, 2016 at 5:06 PM, Tom Lane wrote:
> I wrote:
>> Pavel Stehule writes:
>>> [ num_nulls_v6.patch ]
>
>> I started looking through this. It seems generally okay, but I'm not
>> very pleased with the function name "num_notnulls". I think it would
>> be better as "num_nonnulls", as I s
Robert Haas wrote:
> Oh: another thing that I would like to do is commit the isolation
> tests I wrote for the deadlock detector a while back, which nobody has
> reviewed either, though Tom and Alvaro seemed reasonably positive
> about the concept. Right now, the deadlock.c part of this patch isn
Fabien COELHO wrote:
>
> Hello,
>
> >>v23 attached, which does not change the message but does the other fixes.
> >
> >This doesn't apply anymore
>
> Indeed, but the latest version was really v25.
>
> >-- please rebase and submit to the next CF.
>
> I already provided it as v25 on Feb 1st.
>
On 2016-02-08 19:52:30 +0100, Fabien COELHO wrote:
> I think I would appreciate comments to understand why/how the ringbuffer is
> used, and more comments in general, so it is fine if you improve this part.
I'd suggest to leave out the ringbuffer/new bgwriter parts. I think
they'd be committed sep
I'm closing this as returned-with-feedback; AFAICS even the last version
submitted is still in research stage. Please resubmit once you make
further progress.
Thanks,
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servic
On Sun, Feb 7, 2016 at 7:47 AM, Tom Lane wrote:
> Works for me.
Attached patch is what I came up with. It required only minimal
additional changes for consistency.
--
Peter Geoghegan
From 01d8cb278cecb995ecc30cda0125d10c98f4d05c Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Sun, 7 Feb 2
On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake wrote:
> I have no problem running any test cases you wish on a branch in a loop for
> the next week and reporting back any errors.
>
> Where this gets tricky is the tooling itself. For me to be able to do so
> (and others really) I need to be able t
On Mon, Feb 8, 2016 at 10:45 AM, Robert Haas wrote:
> And, by the way, the patch, aside from the deadlock.c portion, was
> posted back in October, admittedly without much fanfare, but nobody
> reviewed that or any other patch on this thread. If I'd waited for
> those reviews to come in, parallel
Hello,
v23 attached, which does not change the message but does the other fixes.
This doesn't apply anymore
Indeed, but the latest version was really v25.
-- please rebase and submit to the next CF.
I already provided it as v25 on Feb 1st.
I closed it here as returned with feedback.
I've closed this as returned-with-feedback.
--
Á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.
On 02/08/2016 11:24 AM, Robert Haas wrote:
On Mon, Feb 8, 2016 at 2:00 PM, Joshua D. Drake wrote:
If I am off base, please feel free to yell Latin at me again but isn't this
exactly what different trees are for in Git? Would it be possible to say:
Robert says, "Hey pull XYZ, run ABC tests. The
Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
> > Removing one of "archive" or "hot standby" will just cause confusion and
> > breakage, so neither is a good choice for removal.
> >
> > What we should do is
> > 1. Map "archive" and "hot_standby" to one level with a new name th
Robert Haas writes:
> Oh: another thing that I would like to do is commit the isolation
> tests I wrote for the deadlock detector a while back, which nobody has
> reviewed either, though Tom and Alvaro seemed reasonably positive
> about the concept.
Possibly the reason that wasn't reviewed is tha
I've closed this as returned-with-feedback. Please resubmit once you
have found answers to the questions posed; from the submitted benchmark
numbers this looks very exciting, but it needs a bit more work. You
don't necessarily have to agree with everything Robert says, but you
need to have well r
On Mon, Feb 8, 2016 at 2:00 PM, Joshua D. Drake wrote:
> If I am off base, please feel free to yell Latin at me again but isn't this
> exactly what different trees are for in Git? Would it be possible to say:
>
> Robert says, "Hey pull XYZ, run ABC tests. They are what the parallelism
> fixes do"?
Hello Michaël,
+ /* compute total_weight */
+ for (i = 0; i < num_scripts; i++)
+ {
+ total_weight += sql_script[i].weight;
+
+ /* detect overflow... */
If let as int64, you may want to remove this overflow check, or keep
it as int32.
I'd rather k
Of late, by far the majority of the random-noise failures we see in the
buildfarm have come from failure to shut down the postmaster in a
reasonable timeframe. An example is this current failure on hornet:
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hornet&dt=2016-02-08%2013%3A41
Since things are clearly still moving here, I closed it as
returned-with-feedback. Please submit to the next CF so that we don't
lose it.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hacker
I closed this one as "committed", since we pushed a bunch of parts.
Please submit the two remaining ones to the next commitfest.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing
Fabien COELHO wrote:
>
> Hello Michaël,
>
> v23 attached, which does not change the message but does the other fixes.
This doesn't apply anymore -- please rebase and submit to the next CF.
I closed it here as returned with feedback.
Thanks!
--
Álvaro Herrerahttp://www.2ndQuadr
I don't think we need to preserve absolutely all the existing behavior
to the letter. We do need to preserve the behavior for sensible cases
that people might be reasonably be using currently; and if there's
anything somewhat obscure but really useful that you currently get by
using some clever tr
On 02/08/2016 10:45 AM, Robert Haas wrote:
On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund wrote:
On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
I realize that this stuff has all been brewing long, and that there's
still a lot to do. So you gotta keep moving. And I'm not sure that
there's a
Hello Andres,
Any comments before I spend more time polishing this?
I'm running tests on various settings, I'll send a report when it is done.
Up to now the performance seems as good as with the previous version.
I'm currently updating docs and comments to actually describe the
current stat
On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund wrote:
> On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
>> group-locking-v1.patch is a vastly improved version of the group
>> locking patch that we discussed, uh, extensively last year. I realize
>> that there was a lot of doubt about this approac
Teodor Sigaev wrote:
> Interesting feature, but it's not very obvious how to use it. I'd like to
> see some example(s) in documentation.
I'm thinking of making a wiki page, because examples pretty much
require showing resultsets, and I'm not sure this would fly
with our current psql docu
On 02/08/2016 06:24 AM, Andres Freund wrote:
> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
>> Now that there is a setting to give a cluster a "name", it would be nice to
>> have an escape sequence in the log_line_prefix setting that could reference
>> the cluster_name.
>
> I've argued[1][2] f
Shulgin, Oleksandr wrote:
> Added to the Open commitfest: https://commitfest.postgresql.org/9/475/
Here's a review. Note that the patch tested and submitted
is not the initial one in the thread, so it doesn't exactly
match $subject now.
What's tested here is a client-side approach, sugge
Hi
>> I propose really basic functionality, that can be enhanced in future -
>> step by step. This proposal doesn't contain any controversial feature or
>> syntax, I hope. It is related to PLpgSQL only, but described feature can be
>> used from any PL languages with implemented interface.
>>
>
>
Etsuro Fujita writes:
> Here is a patch to use %u not %d to print umid and userid.
Pushed, thanks.
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-hac
2016-02-08 16:55 GMT+01:00 Teodor Sigaev :
> rebased, messages changes per Tom's proposal
>>
> Cool feature and sometimes I needed it a lot.
>
> But, seems, there are some bugs in error processing.
>
I am looking on it
Regards
Pavel
2016-02-08 16:45 GMT+01:00 jflack :
> On 02/08/2016 03:16 AM, Pavel Stehule wrote:
>
> > Only a owner of schema can edit functions inside schema
>
> Can't anyone granted CREATE on the schema do that? Would
> that be changed by this proposal?
>
yes, anybody with necessary rights can do it.
regard
rebased, messages changes per Tom's proposal
Cool feature and sometimes I needed it a lot.
But, seems, there are some bugs in error processing.
1
Following query is okay:
# select * from parse_ident(E'"Some \r Schema".someTable');
parse_ident
--
{"Some \r S
[resending because thunderbird helpfully defaulted my sender
address to the one that -isn't- subscribed to -hackers, sorry]
On 02/08/2016 03:16 AM, Pavel Stehule wrote:
> Only a owner of schema can edit functions inside schema
Can't anyone granted CREATE on the schema do that? Would
that be cha
On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
> wrote:
>> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
>> wrote:
>>> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
wro
Hi!
Interesting feature, but it's not very obvious how to use it. I'd like to see
some example(s) in documentation.
And I see an implementation of AVL tree in psql source code
(src/bin/psql/crosstabview.c). Postgres already has a Red-Black tree
implementation in
src/include/lib/rbtree.h and
On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
> group-locking-v1.patch is a vastly improved version of the group
> locking patch that we discussed, uh, extensively last year. I realize
> that there was a lot of doubt about this approach, but I still believe
> it's the right approach, I have put
On Sun, Feb 7, 2016 at 7:28 PM, Kouhei Kaigai wrote:
> The new callbacks of T_ExtensibleNode will replace the necessity to
> form and deform process of private values, like as:
> https://github.com/pg-strom/devel/blob/master/src/gpujoin.c#L114
Yeah.
> It transforms a bunch of internal data of
Hi Fabien,
On 2016-02-04 16:54:58 +0100, Andres Freund wrote:
> I don't want to post a full series right now, but my working state is
> available on
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/checkpoint-flush
> git://git.postgresql.org/git/users/a
On 2016-02-08 10:38:55 +0530, Amit Kapila wrote:
> I think deciding it automatically without user require to configure it,
> certainly has merits, but what about some cases where user can get
> benefits by configuring themselves like the cases where we use
> PG_O_DIRECT flag for WAL (with o_direct,
On 7/02/2016 4:14 am, "Tom Lane" wrote:
>
> David Rowley writes:
> [ timestamp_out_speedup_2015-11-05.patch ]
>
> Pushed with a bunch of cosmetic tweaks.
Great. Thanks for pushing this.
David
1 - 100 of 132 matches
Mail list logo
