Hi
sorry, I am sending missing attachment
Regards
Pavel
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index f9eea76..bfba459
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 1821,1826
--- 1821,1843
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.
> >>
> >> 1. Change page layout(PG_PAGE_LAYOUT_VERSION) to 5. pg_upgrade detects
> >> it and then converts
On Wed, Feb 10, 2016 at 4:11 PM, Amit Kapila
wrote:
> On Wed, Feb 10, 2016 at 12:16 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 10, 2016 at 12:41 PM, Amit Kapila
>> wrote:
>> > On Wed, Feb 10, 2016 at 7:17 AM, Michael Paquier <
>> michael.paqu...@gmail.com>
>
On Wed, Feb 10, 2016 at 12:16 PM, Michael Paquier wrote:
>
>
> On Wed, Feb 10, 2016 at 12:41 PM, Amit Kapila
> wrote:
> > On Wed, Feb 10, 2016 at 7:17 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >>
> >
> > Consider below code:
> >
> > /*
> > + * Get progress before acquiring
On Mon, Feb 08, 2016 at 10:55:24PM -0500, Tom Lane wrote:
> 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 f
Sorry for the trouble. Thanks Robert for fixing it.
On Wed, Feb 10, 2016 at 2:12 AM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 3:10 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> postgres_fdw: Push down joins to remote servers.
> >
> > The buildfarm is not very impressed with this patch.
>
On Wed, Feb 10, 2016 at 12:41 PM, Amit Kapila
wrote:
> On Wed, Feb 10, 2016 at 7:17 AM, Michael Paquier <
michael.paqu...@gmail.com>
> wrote:
>>
>> On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote:
>> > On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote:
>> >> Well, the idea is to improve the
Yay, finally!
Thanks.
On Wed, Feb 10, 2016 at 12:46 AM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat
> wrote:
> > Thanks Jeevan for your review and comments. PFA the patch which fixes
> those.
>
> Committed with a couple more small adjustments.
>
> Woohoo, finally!
>
> -
On Tue, Feb 9, 2016 at 11:16 AM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat
> wrote:
>> Thanks Jeevan for your review and comments. PFA the patch which fixes those.
>
> Committed with a couple more small adjustments.
I'm getting a compiler warning which I think is coming
On Tue, Feb 9, 2016 at 11:05 PM, Robert Haas wrote:
>
> On Tue, Feb 9, 2016 at 7:53 AM, Amit Kapila
wrote:
> > On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas
wrote:
> >> I think we ought to move the buffer mapping, lock manager, and
> >> predicate lock manager locks into their own tranches also, pe
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Monday, February 08, 2016 11:59 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Andres Freund; Amit Kapila; pgsql-hackers
> Subject: ##freemail## Re: CustomScan in a larger structure (RE: [HACKERS]
> CustomScan support on r
On Wed, Feb 10, 2016 at 3:13 PM, Michael Paquier
wrote:
> On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
> wrote:
> I am personally fine with () and [] as you mention, we could even consider
> {}, each one of them has a different meaning mathematically..
>
> I am not entered into a detailed re
On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
wrote:
> Yes, I will implement regression test patch and documentation patch as
well.
Cool, now that we have a clear picture of where we want to move, that would
be an excellent thing to have. Having the docs in the place is clearly
mandatory.
>
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 the default. If you are
interested in key-stretching, the de
On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund wrote:
> Frequently when reading postgres logs to do some post mortem analysis
> I'm left wondering what process emitted an error/log message. After the
> fact it's often hard to know wether an error message was emitted by a
> user backend or by somet
On Wed, Feb 10, 2016 at 3:45 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Your patch looks right to me, so I will commit, barring objections... with
>> backpatch. Likely to 9.0, AFAICS.
>
> 9.0 is out of support and should not be patched anymore.
>
> I agree that the patch is basically correct, t
On Fri, Feb 5, 2016 at 4:50 PM, Amit Kapila wrote:
> > Could you also measure how this behaves for an INSERT instead of a COPY
> > workload?
>
>
I think such a test will be useful.
>
I have measured the performance with insert to see the behavior when it
don't use strategy. I have tested multipl
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 but without stdbool.h like C++).
> I don't understand why the patc
On 02/09/2016 10:27 PM, Tom Lane wrote:
Noah Misch writes:
On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote:
I wonder if it's worth sticking some instrumentation into stats
collector shutdown?
I wouldn't be surprised if the collector got backlogged during the main phase
of testing a
On Tue, Feb 9, 2016 at 7:26 PM, Thom Brown wrote:
>
> On 7 January 2016 at 05:24, Amit Kapila wrote:
> > On Fri, Dec 25, 2015 at 6:36 AM, Robert Haas
wrote:
> >>
> >> On Wed, Dec 23, 2015 at 1:16 AM, Amit Kapila
> >> wrote:
> >> >> >
> >> >> > Here procArrayGroupXid sounds like Xid at group lev
On Wed, Feb 10, 2016 at 7:17 AM, Michael Paquier
wrote:
>
> On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote:
> > On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote:
> >> Well, the idea is to improve the system responsiveness. Imagine that
> >> the call to GetProgressRecPtr() is done within t
Hello,
At Wed, 10 Feb 2016 11:25:49 +0900, Masahiko Sawada
wrote in
> On Wed, Feb 10, 2016 at 9:18 AM, Michael Paquier
> wrote:
> > On Wed, Feb 10, 2016 at 2:57 AM, Fujii Masao wrote:
> >> On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada
> >> wrote:
> >>> Attached first version dedicated la
Noah Misch writes:
> On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote:
>> I wonder if it's worth sticking some instrumentation into stats
>> collector shutdown?
> I wouldn't be surprised if the collector got backlogged during the main phase
> of testing and took awhile to chew through its
Hello,
At Wed, 10 Feb 2016 02:57:54 +0900, Fujii Masao wrote
in
> On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada
> wrote:
> > On Tue, Feb 9, 2016 at 10:32 PM, Michael Paquier
> > wrote:
> >> On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote:
> >>> Also, to be frank, I think we ought to be
On 2/9/16 8:40 AM, Daniel Verite wrote:
Alvaro Herrera wrote:
While I understand that you may think that "silence is consent",
what I am afraid of is that some committer will look at this two
months from now and say "I hate this Hcol+ stuff, -1 from me" and
send the patch back for synta
Jim Nasby writes:
> On 2/8/16 2:45 PM, Tom Lane wrote:
>> I had in mind to just "git revert" the patch when we're done with it.
> It's already difficult enough for DBAs to debug some performance issues,
> so getting rid of logging is a step backwards. I realize it's unlikely
> that you could ru
On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote:
> Still, it seems clear that the bulk of the shutdown time is indeed the
> stats collector taking its time about shutting down, which is doubly
> weird because the ecpg tests shouldn't have created very many tables,
> so why would there be a
Andrew Dunstan writes:
> anyway, we got a failure pretty quickly:
> pg_ctl: server does not shut down at 2016-02-09 21:10:11.914 EST
> ...
> LOG: received fast shutdown request at 2016-02-09 21:09:11.824 EST
> ...
> LOG: checkpointer dead at 2016-02-09 21:09:14.683 EST
> LOG: all children d
On 2/8/16 2:45 PM, Tom Lane wrote:
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
On 02/09/2016 08:49 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/09/2016 07:49 PM, Tom Lane wrote:
However, I'd already noted from some other digging in the buildfarm
logs that axolotl's speed seems to vary tremendously. I do not
know what else you typically run on that hardware, but pu
On Wed, Feb 10, 2016 at 9:18 AM, Michael Paquier
wrote:
> On Wed, Feb 10, 2016 at 2:57 AM, Fujii Masao wrote:
>> On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada
>> wrote:
>>> Attached first version dedicated language patch (document patch is not yet.)
>>
>> Thanks for the patch! Will review it
Andrew Dunstan writes:
> On 02/09/2016 07:49 PM, Tom Lane wrote:
>> However, I'd already noted from some other digging in the buildfarm
>> logs that axolotl's speed seems to vary tremendously. I do not
>> know what else you typically run on that hardware, but putting it
>> under full load might h
On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote:
> On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote:
>> Well, the idea is to improve the system responsiveness. Imagine that
>> the call to GetProgressRecPtr() is done within the exclusive lock
>> portion, but that while scanning the WAL inser
On 02/09/2016 07:49 PM, Tom Lane wrote:
Andrew Dunstan writes:
So running it's not running with fsync off or using the ramdisk for
stats_temp_directory. Of course, that doesn't explain why we're not
seeing it on branches earlier than 9.5, but it could explain why we're
only seeing it on the e
On Wed, Feb 10, 2016 at 2:23 AM, Fujii Masao wrote:
> On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote:
>> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
>> wrote:
>>> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
Thanks for updating the patch!
Attached is the updated version
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 = strchr(p, '/');
+ /* delimiter changed from '/' to ':' in 9.6 */
On 01/19/2016 07:04 PM, Michael Paquier wrote:
> On Wed, Jan 20, 2016 at 11:41 AM, Alvaro Herrera
> wrote:
>> Joe Conway wrote:
>>
>>> The attached includes Bruce's change, plus I found two additional sites
>>> that appear to need the same change. The xlog.c change is just a DEBUG
>>> message, so
Andrew Dunstan writes:
> So running it's not running with fsync off or using the ramdisk for
> stats_temp_directory. Of course, that doesn't explain why we're not
> seeing it on branches earlier than 9.5, but it could explain why we're
> only seeing it on the ecpg tests.
BTW, the evidence we a
Hello,
At Tue, 9 Feb 2016 13:31:46 +0900, Michael Paquier
wrote in
> On Tue, Feb 9, 2016 at 1:16 PM, Kyotaro HORIGUCHI
> >> > Anyway that's not a small project, and perhaps I am over-complicating
> >> > the whole thing.
> >> >
> >> > Thoughts?
> >>
> >> I agree that we would need something like
I wrote:
> Anyway, I think I should push this additional instrumentation so you
> can use it on axolotl.
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Andrew Dunstan writes:
> Incidentally, as I noted earlier, the ecpg tests don't honour
> TEMP_CONFIG, and in axolotl's case this could well make a difference, as
> it it set up like this:
> ...
> So running it's not running with fsync off or using the ramdisk for
> stats_temp_directory.
Oooohh
On Wed, Feb 10, 2016 at 2:57 AM, Fujii Masao wrote:
> On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada
> wrote:
>> Attached first version dedicated language patch (document patch is not yet.)
>
> Thanks for the patch! Will review it.
>
> I think that it's time to write the documentation patch.
>
On 02/09/2016 06:46 PM, Andrew Dunstan wrote:
On 02/09/2016 05:53 PM, Tom Lane wrote:
Andrew, I wonder if I could prevail on you to make axolotl run "make
check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can
see if the logging I added tells anything useful about this.
On 02/09/2016 05:53 PM, Tom Lane wrote:
Andrew, I wonder if I could prevail on you to make axolotl run "make
check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can
see if the logging I added tells anything useful about this.
Will do.
cheers
andre
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Wednesday, February 10, 2016 1:58 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Jim Nasby; pgsql-hackers@postgresql.org; Amit Langote
> Subject: ##freemail## Re: [HACKERS] Way to check whether a particular block is
> on t
Shulgin, Oleksandr wrote:
> Most importantly, I'd like to learn of better options than storing the
> whole last_result in psql's pset structure.
I guess that you could, each time a query fails, gather silently the
result of \errverbose, store it in a buffer, discard the PGresult,
and in c
I wrote:
> ... However, there is something else happening
> on axolotl. Looking at the HEAD and 9.5 branches, there are three very
> similar failures in the ECPG step within the past 60 days:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2016-02-08%2014%3A49%3A23
> http://bui
I wrote:
> I'm not sure whether there's anything to be gained by leaving the tracing
> code in there till we see actual buildfarm fails. There might be another
> slowdown mechanism somewhere, but I rather doubt it. Thoughts?
Hmmm ... I take that back. AFAICT, the failures on Noah's AIX zoo are
On 2/9/16 4:13 PM, Corey Huinker wrote:
We're not going to get source compatibility without implementing
packages, and there's no enthusiasm for that. It's been stated a few
times before by some that the only value they see in packages is the
package/session variables. Pavel's idea gives us that
On 2/8/16 10:02 AM, Pavel Stehule wrote:
I think it would make sense to implement the interface in at least
one of our other supported PLs. I'm not entirely clear how well this
will match up with, say, plperl, but I'd be interested to see.
The minimalistic interface can be based on
Currently, pl/tcl is implemented through nothing but string
manipulation. In other words, the C code is effectively creating a giant
string that the tcl interpreter must re-parse every time the function is
executed. Additionally, all arguments are treated as raw strings,
instead of the far more
On Tue, Feb 9, 2016 at 2:55 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how long the values in the variables
On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane wrote:
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.
+1.
> In particular, the co
On 02/09/2016 01:22 PM, Tom Lane wrote:
> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet. But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that mak
* Joe Conway (m...@joeconway.com) wrote:
> On 02/09/2016 01:22 PM, Tom Lane wrote:
> > Maybe we need to restrict that somehow, or maybe some better solution
> > exists that we've not thought of yet. But in its current state, RLS
> > is at least as much a security hazard as it is a security aid.
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > Personally I don't buy that the current situation is a good thing. I
> > know that the "ship has sailed" and regret not having participated in
> > the earlier discussions, but I agree with JD here -- the unprivileged
> > user sh
Joe Conway writes:
> Personally I don't buy that the current situation is a good thing. I
> know that the "ship has sailed" and regret not having participated in
> the earlier discussions, but I agree with JD here -- the unprivileged
> user should not have to even think about whether RLS exists, t
On 9 February 2016 at 19:47, Robert Haas wrote:
> I think you're dismissing Tom's concerns far too lightly. The
> row_security=off mode, which is the default, becomes unusable for
> non-superusers under this proposal. That's bad. And if you switch to
> the other mode, then you might accidentall
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 February 2016 at 19:47, Robert Haas wrote:
> > I think you're dismissing Tom's concerns far too lightly. The
> > row_security=off mode, which is the default, becomes unusable for
> > non-superusers under this proposal. That's bad. And if y
On 02/09/2016 12:47 PM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote:
>> JD,
>>
>> * Joshua D. Drake (j...@commandprompt.com) wrote:
>>> pg_dump -U $non-super_user
>>>
>>> Should just work, period.
>>
>> That ship has sailed already, where you're running a pg_dump again
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake (j...@commandprompt.com) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed already, where you're running a pg_dump against
>
On 02/09/2016 12:28 PM, Stephen Frost wrote:
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
pg_dump -U $non-super_user
Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Just to be
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> > To the extent that untrusted code execution is an issue (and my
> > experience with environments which would deploy RLS tells me that it
> > isn't a practical concern), an option could be create
On 02/09/2016 03:05 PM, Tom Lane wrote:
I wrote:
In any case, we should proceed with fixing things so that buildfarm owners
can specify a higher shutdown timeout for especially slow critters.
I looked into doing this as I suggested yesterday, namely modifying the
buildfarm scripts, and soon d
On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote:
> JD,
>
> * Joshua D. Drake (j...@commandprompt.com) wrote:
>> pg_dump -U $non-super_user
>>
>> Should just work, period.
>
> That ship has sailed already, where you're running a pg_dump against
> objects you don't own and which have RLS enabled
On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> Arbitrary code execution is quite a different concern from the prior
> concern regarding incomplete dumps.
I've had both concerns all along, and I think I've mentioned them before.
> To the extent that untrusted code execution is an issue (a
On Tue, Feb 9, 2016 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> postgres_fdw: Push down joins to remote servers.
>
> The buildfarm is not very impressed with this patch.
Well, I guess that's why we have regression tests. It looks like that
test case introduces a dependency on particula
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> pg_dump -U $non-super_user
>
> Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Thanks!
Stephen
signature.asc
Description: Digital s
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> > On 02/09/2016 11:47 AM, Robert Haas wrote:
> >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
> Whereupon you'd have no certainty that what you got represented a
> comp
On 02/09/2016 12:05 PM, Robert Haas wrote:
That's true. But I should also have an expectation that running
pg_dump won't trigger arbitrary code execution, which is why by
default, pg_dump sets row_security to OFF. That way, if a row
security policy applies, I get an error rather than an incomp
Josh Kupershmidt writes:
> On Tue, Feb 9, 2016 at 2:16 PM, Filip RembiaÅkowski
> wrote:
>> But then it becomes disputable if SQL syntax change makes sense.
>>
>> ---we had this,
>> NOTIFY channel [ , payload ]
>> ---and in this patch we have this
>> NOTIFY [ ALL | DISTINCT ] channel [ , payload
On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski
wrote:
> But then it becomes disputable if SQL syntax change makes sense.
>
> ---we had this,
> NOTIFY channel [ , payload ]
> ---and in this patch we have this
> NOTIFY [ ALL | DISTINCT ] channel [ , payload ]
> --- but maybe we should have t
I wrote:
> In any case, we should proceed with fixing things so that buildfarm owners
> can specify a higher shutdown timeout for especially slow critters.
I looked into doing this as I suggested yesterday, namely modifying the
buildfarm scripts, and soon decided that it would be a mess; there are
On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> On 02/09/2016 11:47 AM, Robert Haas wrote:
>> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
Whereupon you'd have no certainty that what you got represented a
complete dump of your own data.
>>>
>>> It would be a dump of what y
On 02/09/2016 11:47 AM, Robert Haas wrote:
> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
>>> Whereupon you'd have no certainty that what you got represented a
>>> complete dump of your own data.
>>
>> It would be a dump of what you're allowed to see, rather than an error
>> saying you c
On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
wrote:
>
> Oh, and I suggest we call them SESSION variables rather than SCHEMA
> variables, to reinforce the idea of how long the values in the variables
> live. A session variable is in a sense a 1x1 temp table, whose definition
> persists across se
On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
>> Whereupon you'd have no certainty that what you got represented a
>> complete dump of your own data.
>
> It would be a dump of what you're allowed to see, rather than an error
> saying you couldn't dump something you couldn't see, which is
Ah, so it turns out I should have used the commitfest tool. My
apologies; I will send the whole thing through that again. Please
disregard the earlier message.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
* Andreas 'ads' Scherbaum wrote:
> one of our customers approached us an
* Andreas 'ads' Scherbaum wrote:
one of our customers approached us and complained, that GET DIAGNOSTICS
row_count returns invalid results if the number of rows is > 2^31. It's
Attached patch expands the row_count to 64 bit.
diagnostics=# select testfunc_pg((2^32 + 5)::bigint);
testfun
On Tue, Feb 9, 2016 at 12:15 AM, Merlin Moncure wrote:
> I wonder if the third argument
> should be a boolean however. If we make it 'text, 'send mode',
> instead, we could leave some room for more specialization of the
> queuing behavior.
>
> For example, we've had a couple of requests over the
On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat
wrote:
> Thanks Jeevan for your review and comments. PFA the patch which fixes those.
Committed with a couple more small adjustments.
Woohoo, finally!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
I wrote:
> 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 ani
Simon Riggs writes:
> Your patch looks right to me, so I will commit, barring objections... with
> backpatch. Likely to 9.0, AFAICS.
9.0 is out of support and should not be patched anymore.
I agree that the patch is basically correct, though I'd personally
write it without bothering with the ext
On 9 February 2016 at 18:42, Jeff Janes wrote:
> While testing the crash resilience of the recent 2-part-commit
> improvements, I've run into a problem where sometimes after a crash
> the recovery process creates zeroed files in pg_subtrans until it
> exhausts all disk space.
>
Not sure which pa
On Tue, Feb 9, 2016 at 9:58 AM, Pavel Stehule
wrote:
>
>
> 2016-02-09 15:32 GMT+01:00 Marko Tiikkaja :
>
>> On 08/02/16 14:16, Pavel Stehule wrote:
>>
>>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
>>>
Yeah, and that's exactly what I don't want, because that means that
CREATE
On February 9, 2016 7:12:23 PM GMT+01:00, Robert Haas
wrote:
>On Tue, Sep 8, 2015 at 5:11 PM, Robert Haas
>wrote:
>> Here's an updated patch series with some more improvements to the
>> isolationtester code, and some better test cases.
>
>OK, here's a final set of patches that I intend to commit
On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada wrote:
> On Tue, Feb 9, 2016 at 10:32 PM, Michael Paquier
> wrote:
>> On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote:
>>> Also, to be frank, I think we ought to be putting more effort into
>>> another patch in this same area, specifically Thomas
While testing the crash resilience of the recent 2-part-commit
improvements, I've run into a problem where sometimes after a crash
the recovery process creates zeroed files in pg_subtrans until it
exhausts all disk space.
Looking at the code, it looks like it does not anticipate that the xid
might
On Thu, Feb 4, 2016 at 8:35 PM, Peter Eisentraut wrote:
> I generally use the master branch psql for normal work, and this change
> has caused massive breakage for me. It's straightforward to fix, but in
> some cases the breakage is silent, for example if you do
> something=$(psql -c ...) and the
On Tue, Feb 9, 2016 at 7:53 AM, Amit Kapila wrote:
> On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>> I think we ought to move the buffer mapping, lock manager, and
>> predicate lock manager locks into their own tranches also, perhaps
>> using this new named-tranche facility.
>
> Makes sense
Tom Lane wrote:
> I do not think we want any client-side sorting in this feature at all,
> because the minute you have any such thing, you are going to have an
> absolutely never-ending stream of demands for more sorting features:
> multi column, numeric vs text, ASC vs DESC, locale-aware,
On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote:
> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
> wrote:
>> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
>>> Thanks for updating the patch!
>>> Attached is the updated version of the patch.
>>> I removed unnecessary assertion check and
On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
wrote:
> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
>> Thanks for updating the patch!
>> Attached is the updated version of the patch.
>> I removed unnecessary assertion check and change of source code
>> that you added, and improved the sou
Artur Zakirov writes:
>> I think the NIImportOOAffixes() in spell.c should be corrected to avoid
>> this bug.
> I have attached a patch. It adds new functions parse_ooaffentry() and
> get_nextentry() and fixes a couple comments.
I do not like this patch much. It is basically "let's stop using
On Sun, Feb 7, 2016 at 9:49 PM, Kouhei Kaigai wrote:
> On the other hands, it also became clear we have to guarantee OS buffer
> or storage block must not be updated partially during the P2P DMA.
> My motivation is a potential utilization of P2P DMA of SSD-to-GPU to
> filter out unnecessary rows a
I haven't been paying attention to this thread ... but it is sure
> sounding like this feature has gotten totally out of hand. Suggest
> reconsidering your design goals.
>
> > Or said otherwise, having the [+/-] colV sorting is a way to
> > avoid the question:
> > "we can sort the horizontal heade
On Tue, Feb 9, 2016 at 10:32 PM, Michael Paquier
wrote:
> On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote:
>> Also, to be frank, I think we ought to be putting more effort into
>> another patch in this same area, specifically Thomas Munro's causal
>> reads patch. I think a lot of people today a
Hi
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.
>
> 1
> Following query is okay:
> # select * from parse_ident(E'"Some \r Schema".someTable');
>
"Daniel Verite" writes:
> Dean Rasheed wrote:
>> I don't think we should allow sorting colV values client-side,
>> overriding a server-side ORDER BY clause in the query.
> I shared that opinion until (IIRC) the v8 or v9 of the patch.
> Most of the evolution of this patch has been to go
> fr
1 - 100 of 128 matches
Mail list logo
