On 9 February 2016 at 05:24, Pavel Stehule wrote:
> I have not a feeling so we did some with Daniel privately. All work was
> public (I checked my mailbox) - but what is unhappy - in more mailing list
> threads (not sure how it is possible, because subjects looks same). The
> discus about the desi
I'm seeing an issue with ALTER EXTENSION DROP FUNCTION
not fully unregistering the dependency of the function
on the extension. Commands to reproduce described here:
https://trac.osgeo.org/postgis/ticket/3450#comment:23
Basically I'm getting:
ERROR: cannot drop function pgis_twkb_accum_finalfn(
On Tue, Feb 09, 2016 at 10:33:42AM +0100, Sandro Santilli wrote:
> https://trac.osgeo.org/postgis/ticket/3450#comment:23
>
> Basically I'm getting:
>
> ERROR: cannot drop function pgis_twkb_accum_finalfn(internal) because other
> objects depend on it
> DETAIL: extension postgis depends on f
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.
Ok, so the patch would only onclude the checkpointer stuff.
I'll look at this
Hi
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 seems to be going way beyond the normal
> level
On February 9, 2016 10:46:34 AM GMT+01:00, 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
On 9 February 2016 at 10:09, Pavel Stehule wrote:
> The sorting on client side is necessary - minimally in one direction,
> because you cannot to create perfect sorting for both dimensions.
> Possibility to order in second dimension is just pretty comfortable -
> because you don't need to think tw
> >
> > SELECT name, to_char(date, 'mon') AS month, extract(month from date) AS
> > month_order, sum(amount) AS amount FROM invoices GROUP BY 1,2,3;
> >
> > and crosstabview command (per Daniel proposal)
> >
> > \crosstabview +name +month:month_order amount
> >
> > But if I don't need column heade
Hi,
I have reviewed the patch and it looks good to me.
make/make install/make check is fine (when done without -Wall -Werror).
Here are few comments:
1.
With -Wall -Werror, I see couple of warnings:
postgres_fdw.c: In function ‘estimate_path_cost_size’:
postgres_fdw.c:2248:13: error: ‘run_cost’
On 9 February 2016 at 11:06, Pavel Stehule wrote:
> + respect SQL clauses ordering, allows pretty complex ORDER BY clause
That, to me is the key point. SQL already allows very powerful
sorting, so psql should not just throw away the query's sort order and
replace it with something much more bas
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 source comment.
> Barring objection, I'll commit this patch.
So,
On Mon, Feb 8, 2016 at 5:24 PM, Daniel Verite
wrote:
> 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
On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila wrote:
> Do you see any benefit in allowing checkpoints for such cases considering
> bgwriter will anyway take care of logging standby snapshot for such
> cases?
Well, the idea is to improve the system responsiveness. Imagine that
the call to GetProgres
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 and attached patch implements it using new named
tran
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 are trying to use
> synchronous replication to build load-balan
On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier
wrote:
>
> On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila
wrote:
> > Do you see any benefit in allowing checkpoints for such cases
considering
> > bgwriter will anyway take care of logging standby snapshot for such
> > cases?
>
> Well, the idea is to i
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 level, how about
>> >> > procArrayGroupMemberXid?
>> >> > Find the pat
Alvaro Herrera wrote:
> So please can we have that wiki page so that the syntax can be hammered
> out a bit more.
Sure, I'm on it.
> I'm closing this as returned-with-feedback for now.
Well, the feedback it got during months was incorporated into
the patch in the form of significant im
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
SCHEMA VARIABLE suddenly breaks existing code.
theoretically yes, but this conflict can be 100% detected - so no quiet bug
is possibl
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 syntax rework. IMO it's better to have
On Wed, Dec 30, 2015 at 08:16:28PM +1300, David Rowley wrote:
> On [1] I suggested an idea to make improvements to the planner around the
> Equivalence Class code. Later in [2] Tom raised concerns with this adding
> too many planning cycles for a perhaps not common enough situation. I
> don't want
Alvaro Herrera wrote:
> Also, what about the business of putting "x" if there's no third column?
> Three months from now some Czech psql hacker will say "we should use
> Unicode chars for this" and we will be forever stuck with \pset
> unicode_crosstab_marker to change the character to a ☑
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
>>> SCHEMA VARIABLE suddenly breaks existing code.
>>>
>>>
>> theoretical
Sandro Santilli writes:
> On Tue, Feb 09, 2016 at 10:33:42AM +0100, Sandro Santilli wrote:
>> https://trac.osgeo.org/postgis/ticket/3450#comment:23
>>
>> Basically I'm getting:
>> ERROR: cannot drop function pgis_twkb_accum_finalfn(internal) because other
>> objects depend on it
>> DETAIL: ext
On 02/08/2016 10:55 PM, 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 fishy.
It has been affecting only
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
from no client-side sorting option
On вторник, 29 сентября 2015 г. 19:02:59 MSK, Alvaro Herrera wrote:
Andres Freund wrote:
I went through all headers in src/include and checked for macros
containing [^&]&[^&] and checked whether they have this hazard. Found a
fair number.
That patch also changes !! tests into != 0 style.
I d
Dean Rasheed wrote:
> Note that I might also want to pass additional sort options, such as
> "ORDER BY name NULLS LAST", which the existing syntax doesn't allow.
> In the new syntax, such sort options could be trivially supported in
> both the server- and client-side sorts:
Note that NULL
"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
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');
>
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
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 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
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 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
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
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 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
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
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 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
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 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 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
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
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
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
--
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
* 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
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
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
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
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 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 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
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 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
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 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
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
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
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
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: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 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
* 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 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
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
>
* 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
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
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
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 (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.
>
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
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 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
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 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
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
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
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
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
> -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
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
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 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.
>
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
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
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
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
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
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 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 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 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
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 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
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 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
1 - 100 of 128 matches
Mail list logo
