2014-06-30 8:17 GMT+02:00 Rajeev rastogi :
> On 26 June 2014 11:53, Samrat Revagade Wrote:
>
>
>
> >> I am sending updated patch - buggy statement is printed via more
> logical psql_error function instead printf
>
>
>
> >Thank you for updating patch, I really appreciate your efforts.
>
>
>
> >Now
At 2014-06-30 12:05:06 +0530, a...@2ndquadrant.com wrote:
>
> It may be that the best thing to do would be to avoid using
> optional_argument altogether, and have separate --stats and
> --stats-per-record options. Thoughts?
That's what I've done in the attached patch, except I've called the new
op
At 2014-06-30 05:19:10 +, dilip.ku...@huawei.com wrote:
>
> I have started reviewing the patch..
Thanks.
> 1. Patch applied to git head cleanly.
> 2. Compiled in Linux -- Some warnings same as mentioned by furuyao
I've attached an updated version of the patch which should fix the
warnings
On 26 June 2014 11:53, Samrat Revagade Wrote:
>> I am sending updated patch - buggy statement is printed via more logical
>> psql_error function instead printf
>Thank you for updating patch, I really appreciate your efforts.
>Now, everything is good from my side.
>* it apply cleanly to the curr
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund
wrote:
> On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
> > On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
> > I think it is better to have some discussion about it. Apart from this,
> > today I noticed atomic read/write doesn't use any barrier sem
On 13 June 2014 13:01, Abhijit Menon-Sen Wrote
>
> I've changed this to use %zu at Álvaro's suggestion. I'll post an
> updated patch after I've finished some (unrelated) refactoring.
I have started reviewing the patch..
1. Patch applied to git head cleanly.
2. Compiled in Linux -- Some warning
At 2014-06-30 13:55:59 +0900, horiguchi.kyot...@lab.ntt.co.jp wrote:
>
> > So we should mark this patch as "Rejected Patches"?
>
> I think so.
Done.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Hello,
> > misunderstanding, but all these patches are totally useless.
>
> So we should mark this patch as "Rejected Patches"?
I think so.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
At 2014-06-29 21:55:24 +0300, e...@hasegeli.com wrote:
>
> I will update the patch as returned with feedback
I don't think it's fair to mark this as returned with feedback without a
more detailed review (I think of returned with feedback as providing a
concrete direction to follow). I've set it ba
Hi.
We're two weeks into the CommitFest now, and things are moving along
quite nicely.
Fourteen patches have been committed, and twelve more are marked ready
for committer. But most importantly, many patches have been reviewed,
and only nine patches still lack a reviewer (and most of those have
s
On Mon, Jun 30, 2014 at 12:49 PM, Kyotaro HORIGUCHI
wrote:
> Mmm. This patch is found that useless, from the first.
>
>> Thanks for the patch! But when I read the source code of pg_resetxlog,
>> I found that it has already reset the backup locations. Please see
>> RewriteControlFile() which does t
Mmm. This patch is found that useless, from the first.
> Thanks for the patch! But when I read the source code of pg_resetxlog,
> I found that it has already reset the backup locations. Please see
> RewriteControlFile() which does that. So I wonder if we need nothing
> at least in HEAD for the pur
On Sun, Jun 29, 2014 at 9:25 PM, Andres Freund wrote:
> On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
>> On 29 June 2014 10:55, Andres Freund wrote:
>> > So, I'd looked at it with an eye towards committing it and found some
>> > more things. I've now
>> > * added the restriction that the clus
On 2014-06-29 21:12:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Why aren't we delaying allocations in e.g. AtStart_Inval(),
> >>> AfterTriggerBeginXact() to when the data structures are acutally used?
> >>
>
On 2014-06-29 19:51:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Note that we're *inside* recv() here.
>
> Well, actually, the recv() has probably failed with an EINTR at this
> point, or else it will when/if control returns.
Well, the point is that we'll be reentering ssl when sending
Andres Freund writes:
> On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Why aren't we delaying allocations in e.g. AtStart_Inval(),
>>> AfterTriggerBeginXact() to when the data structures are acutally used?
>>
>> Aren't we? Neither of those would be doing much work ce
On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Why aren't we delaying allocations in e.g. AtStart_Inval(),
> > AfterTriggerBeginXact() to when the data structures are acutally used?
>
> Aren't we? Neither of those would be doing much work certainly.
They are perhaps n
Andres Freund writes:
> Why aren't we delaying allocations in e.g. AtStart_Inval(),
> AfterTriggerBeginXact() to when the data structures are acutally used?
Aren't we? Neither of those would be doing much work certainly.
regards, tom lane
--
Sent via pgsql-hackers mai
Andres Freund writes:
> Note that we're *inside* recv() here.
Well, actually, the recv() has probably failed with an EINTR at this
point, or else it will when/if control returns.
>> Uh, no, that would pretty much destroy the point of trying to report
>> an error message at all.
> I only mean th
On 2014-06-29 19:13:55 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
> >> I do not think it is: specifically, the notion
> >> that we will call ereport(FATAL) directly from a signal handler
> >> does not fill me with warm fuzzies.
>
> > Aren't we
On 26.6.2014 23:48, Tomas Vondra wrote:
> On 26.6.2014 20:43, Tomas Vondra wrote:
>> Attached is v2 of the patch, with some cleanups / minor improvements:
>>
>> * there's a single FIXME, related to counting tuples in the
>
> Meh, I couldn't resist resolving this FIXME, so attached is v3 of the
> p
Hi,
In workloads with mostly simple statements, memory allocations are the
primary bottleneck. Some of the allocations are unlikely to be avoidable
without major work, but others seem superflous in many scenarios.
Why aren't we delaying allocations in e.g. AtStart_Inval(),
AfterTriggerBeginXact()
Andres Freund writes:
> On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
>> I do not think it is: specifically, the notion
>> that we will call ereport(FATAL) directly from a signal handler
>> does not fill me with warm fuzzies.
> Aren't we already pretty much doing that for
> SIGTERM/pg_terminate_b
On 2014-06-29 17:28:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
> >> Robert Haas writes:
> >>> Yeah, I think someone should do some analysis of whether this is
> >>> adding gettimeofday() calls, and how many, and what the performance
> >>> i
On Sat, Jun 28, 2014 at 07:35:10AM -0700, Kevin Grittner wrote:
> David Fetter wrote:
> > On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
>
> >> Here is v2.
>
> > I've taken the liberty of making an extension that uses this.
> > Preliminary tests indicate a 10x performance improv
On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
> I do not think it is: specifically, the notion
> that we will call ereport(FATAL) directly from a signal handler
> does not fill me with warm fuzzies.
Aren't we already pretty much doing that for
SIGTERM/pg_terminate_backend() and recovery conflict i
Andres Freund writes:
> On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> Yeah, I think someone should do some analysis of whether this is
>>> adding gettimeofday() calls, and how many, and what the performance
>>> implications are.
>> I believe that as the patch stands, w
On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote:
> >> I propose to push this as it stands except for the postgres_fdw
> >> part. The default is easy enough to change if we reach consensus,
> >> and expanding the scope
Abhijit Menon-Sen writes:
>> 3) This is such a simple change with no new infrastructure code
>> (PLyObject_ToComposite already exists). Can you think of a reason
>> why this wasn't done until now? Was it a simple miss or purposefully
>> excluded?
> This is not an authoritative answer: I think the
On 29 June 2014 10:01, Thomas Munro wrote:
> Would anyone who is interested in a SKIP LOCKED feature and
> attending the CHAR(14)/PGDay UK conference next week be
> interested in a birds-of-a-feather discussion?
Sounds like a plan. I'll check my schedule.
--
Simon Riggs http
2014-06-29 15:24 GMT+02:00 Abhijit Menon-Sen :
> At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
> >
> > Thanks, I marked it as ready for committer. I hope Fujii san or
> > another committer will commit this, refining English expression if
> > necessary.
>
> Since it was just a matter of
Robert Haas writes:
> On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote:
>> I propose to push this as it stands except for the postgres_fdw
>> part. The default is easy enough to change if we reach consensus,
>> and expanding the scope can be a new patch in a new CF.
>> Objections?
> Yeah,
Robert, Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 26 June 2014 18:04, Robert Haas wrote:
> >> ALTER TABLE t1 SET POLICY p1 ON SELECT TO t1_p1_sel_quals;
> >> GRANT SELECT ON TABLE t1 TO role1 USING p1;
> >
> > As I see it, the downside of this is that it gets a lot more complex.
Dave McGuire writes:
> On 06/29/2014 10:24 AM, Tom Lane wrote:
>> Hey, right up the river from here!
> Come on up and hack! There's always something neat going on around
> here. Ever run a PDP-11? B-)
There were so many PDP-11s around CMU when I was an undergrad that
I remember seeing spare
Vik Fearing writes:
> On 06/21/2014 10:11 PM, Pavel Stehule wrote:
>> Is any reason or is acceptable incompatible change CONNECTION_LIMIT
>> instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough
>> for breaking compatibility?
> How is compatibility broken? The grammar still ac
On June 29, 2014 9:01:27 PM CEST, Dave McGuire wrote:
>On 06/29/2014 02:58 PM, Patrick Finnegan wrote:
>> Last I checked, NetBSD doesn't support any sort of multiprocessor
>VAX.
>> Multiprocessor VAXes exist, but you're stuck with either Ultrix or
>VMS
>> on them.
>
> Hi Pat, it's good to see yo
Joshua Yanovski :
> Proof of concept initial patch for enabling index only scans for
> partial indices even when an attribute is not in the target list, as
> long as it is only used in restriction clauses that can be proved by
> the index predicate. This also works for index quals, though they
> s
On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote:
>>> Moreover, there would be no way to implement a timeout like that without
>>> adding a gettimeofday() call after every packet receipt, which is overhead
>>> we do not need and cannot afford. I don't think this feature should add
>>> *
Dave McGuire writes:
> On 06/29/2014 10:54 AM, Andres Freund wrote:
>> Maybe I'm just not playful enough, but keeping a platform alive so we
>> can run postgres in simulator seems a bit, well, pointless.
> On the "in a simulator" matter: It's important to keep in mind that
> there are more VAXe
Hi Vaishnavi.
In addition to Jaime's comments about the functionality, here are are
some comments about the code.
Well, they were supposed to be comments about the code, but it turns out
I have comments about the feature as well. We need to figure out what to
do about the database and user column
Kevin Grittner writes:
> I propose to push this as it stands except for the postgres_fdw
> part. The default is easy enough to change if we reach consensus,
> and expanding the scope can be a new patch in a new CF.
> Objections?
There's been enough noise about the external definition that I thi
Robert Haas wrote:
> On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> Why is IIT timeout turned on only when send_ready_for_query is true?
>>> I was thinking it should be turned on every time a message is received.
>>> Imagine the case where the session is in idl
Kevin Grittner writes:
> Gurjeet Singh wrote:
>> Besides, there's already a throttle built in using the
>> PGSTAT_STAT_INTERVAL limit.
> This is a key point; neither the original patch nor my proposed
> alternative bypasses that throttling.
That's a fair point that probably obviates my objectio
On 2014-06-29 12:20:02 -0400, Tom Lane wrote:
> I wrote:
> > BTW, it sure looks like the part of ACX_PTHREAD beginning with
> > # Various other checks:
> > if test "x$acx_pthread_ok" = xyes; then
> > (lines 163..210 in HEAD's acx_pthread.m4) is dead code.
>
> On closer inspection, this h
I wrote:
> BTW, it sure looks like the part of ACX_PTHREAD beginning with
> # Various other checks:
> if test "x$acx_pthread_ok" = xyes; then
> (lines 163..210 in HEAD's acx_pthread.m4) is dead code.
On closer inspection, this has been broken since commit
e48322a6d6cfce1ec52ab303441df329
I have reviewed this patch, and think we should do what the patch
is trying to do, but I don't think the submitted patch would
actually work. I have attached a suggested patch which I think
would work. Gurjeet, could you take a look at it?
My comments on prior discussion embedded below.
Gurjeet
[ trimming the cc list since this isn't VAX-specific ]
I wrote:
> Yeah. We'd need to look at the relevant part of config.log to be sure,
> but my guess is that configure tried that switch, failed to recognize
> that it wasn't actually working, and seized on it as what to use.
> Maybe the test-for
Andres Freund writes:
> Hm? I think we're misunderstanding each other - I was thinking of tacking
> ALTER TABLE .. SET (AUTOVACUUM_ENABLED = false) to the tables created in
> test_decoding/sql/, not to something outside.
Ah, got it. Yeah, seems like an OK workaround.
reg
On 2014-06-29 11:08:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
> >> You mean disable autovac only in the contrib/test_decoding check run,
> >> right? That's probably OK since it's tested in the main regression
> >> runs.
>
> > Actually I'd
Andres Freund writes:
> On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
>> You mean disable autovac only in the contrib/test_decoding check run,
>> right? That's probably OK since it's tested in the main regression
>> runs.
> Actually I'd not even though of that, but just of disabling it on
> rela
Andres Freund writes:
> Maybe I'm just not playful enough, but keeping a platform alive so we
> can run postgres in simulator seems a bit, well, pointless.
True --- an actual machine would be more useful, even if slower. Some
of the existing buildfarm critters are pretty slow already, so that's
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
> Dave McGuire writes:
> > On 06/25/2014 01:57 PM, Tom Lane wrote:
> >> Is there anyone in the NetBSD/VAX community who would be willing to
> >> host a PG buildfarm member?
>
> > I could put together a simh-based machine (i.e., fast) on a vm, if
> >
On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Solution I)
> > Change ReorderBufferCommit() to not call the begin()/commit() callbacks
> > if no change() callback has been called. Technically that's trivial, but
> > I don't think that'd end up being a better behaviour.
>
Andres Freund writes:
> Solution I)
> Change ReorderBufferCommit() to not call the begin()/commit() callbacks
> if no change() callback has been called. Technically that's trivial, but
> I don't think that'd end up being a better behaviour.
> Solution II)
> Disable autovacuum/analyze for the tabl
Abhijit Menon-Sen writes:
> So, what's the status of this patch?
> There's been quite a lot of discussion (though only about the approach;
> no formal code/usage review has yet been posted), but as far as I can
> tell, it just tapered off without any particular consensus.
AFAICT, people generally
Hi,
As shown by the CLOBBER_CACHE_ALWAYS animal test_decoding's tests fail
if they take very long. The failures aren't bugs, but diffs like:
BEGIN
+ COMMIT
+ BEGIN
table public.tr_sub: INSERT: id[integer]:1 path[text]:'1-top-#1'
The added transaction is an analyze started by autovacuum.
S
Dave McGuire writes:
> On 06/25/2014 01:57 PM, Tom Lane wrote:
>> Is there anyone in the NetBSD/VAX community who would be willing to
>> host a PG buildfarm member?
> I could put together a simh-based machine (i.e., fast) on a vm, if
> nobody else has stepped up for this.
No other volunteers h
So, what's the status of this patch?
There's been quite a lot of discussion (though only about the approach;
no formal code/usage review has yet been posted), but as far as I can
tell, it just tapered off without any particular consensus.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsq
On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote:
> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
> >
> > Also based on Alvaro's comment, I replaced the scanf parsing code with
> > strtoul(l) function.
>
> As far as I can tell (from the thread and a quick look at the patch),
> you
At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
>
> Also based on Alvaro's comment, I replaced the scanf parsing code with
> strtoul(l) function.
As far as I can tell (from the thread and a quick look at the patch),
your latest version of the patch addresses all the review comments.
Sho
Abhijit Menon-Sen writes:
> I had another look now, and I think removing the comment is fine. It
> actually made no sense to me in context, so I went digging a little.
> ...
> Note that the first argument was actually NULL, so the comment made
> sense when it was written. But the code was subseque
At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
>
> Thanks, I marked it as ready for committer. I hope Fujii san or
> another committer will commit this, refining English expression if
> necessary.
Since it was just a matter of editing, I went through the patch and
corrected various mino
2014-06-29 13:35 GMT+02:00 MauMau :
> Thanks, I marked it as ready for committer. I hope Fujii san or another
> committer will commit this, refining English expression if necessary.
>
sure
Thank you very much
Regards
Pavel
>
> Regards
> MauMau
>
>
At 2014-06-29 18:08:53 +0530, a...@2ndquadrant.com wrote:
>
> I think the patch is ready for committer.
That's based on my earlier quick look and the current archaeology. But
I'm not a PL/Python user, and Ronan signed up to review the patch, so I
haven't changed the status.
Ronan, did you get a c
Hi.
When this patch was first added to a CF, I had a quick look at it, but
left it for a proper review by someone more familiar with PL/Python
internals for precisely this reason:
> 2) You removed the comment:
> - /*
> - * We don't support arrays of row ty
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
> On 29 June 2014 10:55, Andres Freund wrote:
> > So, I'd looked at it with an eye towards committing it and found some
> > more things. I've now
> > * added the restriction that the cluster name can only be ASCII. It's
> > shown from several clu
Hi,
Thanks a lot for the review and comments. Here is an updated patch.
On 6/25/2014 8:20 AM, Abhijit Menon-Sen wrote:
Your patch should definitely add a test case or two to
sql/unaccent.sql and expected/unaccent.out showing the behaviour that
didn't work before the change.
That would require
Hi.
I've attached a patch to contrib/unaccent as outlined in my review the
other day. I'm familiar with multiple languages in which modifiers are
separate characters (but not Arabic), so I decided to try a quick test
because I was curious.
I added a line containing only U+0940 (DEVANAGARI VOWEL S
Thanks, I marked it as ready for committer. I hope Fujii san or another
committer will commit this, refining English expression if necessary.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Fri, Jun 27, 2014 at 6:14 AM, Tom Lane wrote:
> David Rowley writes:
> > If there's no way to tell that the target entry comes from a left join,
> > then would it be a bit too quirky to just do the NOT NULL checking when
> > list_length(query->rtable) == 1 ? or maybe even loop over query->rta
On 29 June 2014 10:55, Andres Freund wrote:
> So, I'd looked at it with an eye towards committing it and found some
> more things. I've now
> * added the restriction that the cluster name can only be ASCII. It's
> shown from several clusters with differing encodings, and it's shown
> in proces
On 2014-06-28 19:36:39 +0300, Heikki Linnakangas wrote:
> On 06/27/2014 08:15 PM, Robert Haas wrote:
> >On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund
> >wrote:
> >>I don't really see usecases where it's not related data that's being
> >>touched, but: The point is that the fastpath (not using a s
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
> On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
> > Two things:
> > a) compare_exchange is a read/write operator and so far I've defined it
> >to have full barrier semantics (documented in atomics.h). I'd be
> >happy to discuss which semant
73 matches
Mail list logo
