On Mon, Sep 8, 2014 at 10:39 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Jul 26, 2014 at 9:32 PM, Robert Haas robertmh...@gmail.com
wrote:
On Fri, Jul 25, 2014 at 4:16 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas
2014-09-08 6:27 GMT+02:00 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
ignore_nulls in array_to_json_pretty probably is not necessary. On second
hand, the cost is zero, and we can have it for API consistency.
I'm willing to be persuaded either way on
On 09/07/2014 05:11 PM, Костя Кузнецов wrote:
hello.
i recode vacuum for gist index.
all tests is ok.
also i test vacuum on table size 2 million rows. all is ok.
on my machine old vaccum work about 9 second. this version work about 6-7 sec .
review please.
If I'm reading this correctly, the
I wrote:
I gave it a spin and could not find any undesirable behaviour, and the
output of EXPLAIN ANALYZE looks like I'd expect.
I noticed that you use the list length of fdw_private to check if
the UPDATE or DELETE is pushed down to the remote server or not.
While this works fine, I
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/07/2014 05:11 PM, Костя Кузнецов wrote:
hello.
i recode vacuum for gist index.
all tests is ok.
also i test vacuum on table size 2 million rows. all is ok.
on my machine old vaccum work about 9
On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 09/07/2014 05:11 PM, Костя Кузнецов wrote:
hello.
i recode vacuum for gist index.
all tests is ok.
also i test vacuum on
On 09/08/2014 11:08 AM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/07/2014 05:11 PM, Костя Кузнецов wrote:
hello.
i recode vacuum for gist index.
all tests is ok.
also i test vacuum on table size 2 million rows. all is
On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
In the b-tree code, we solved that problem back in 2006, so it can be
done but
Hi,
Here is the review result.
#1. Patch compatibility
Little bit hunk, but it can patch to latest master.
#2. Functionality
No problem.
#3. Documentation
I think modulo operator explanation should put at last at the doc line.
Because the others are more frequently used.
#4. Algorithm
You
(2014/09/08 16:18), Albe Laurenz wrote:
I wrote:
I gave it a spin and could not find any undesirable behaviour, and the
output of EXPLAIN ANALYZE looks like I'd expect.
Thank you for the review!
I noticed that you use the list length of fdw_private to check if
the UPDATE or DELETE is pushed
On Wed, Sep 3, 2014 at 11:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Aug 31, 2014 at 9:45 AM, Magnus Hagander mag...@hagander.net wrote:
Do we really want those Asserts? There is not a single Assert in
bin/pg_basebackup today - as is the case for most things in bin/. We
typically
On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
Yes. I plan to push the patch this weekend. Sorry for the delay.
I'm about to push this. Is it ok to first push it to master and only
backpatch once a couple buildfarm cycles haven't complained?
Greetings,
Andres Freund
--
Andres Freund
On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas
(2014/09/02 18:55), Etsuro Fujita wrote:
(2014/09/01 20:15), Etsuro Fujita wrote:
While working on [1], I've found that postgres_fdw behaves oddly:
I've revised the patch a bit further. Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
---
On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
Yes. I plan to push the patch this weekend. Sorry for the delay.
I'm about to push this. Is it ok to first push it to master and only
backpatch once a couple
Hello Mutsumara-san,
#3. Documentation
I think modulo operator explanation should put at last at the doc line.
Because the others are more frequently used.
So I like patch3 which is simple and practical.
Ok.
If you agree or reply my comment, I will mark ready for commiter.
Please find
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
Yes. I plan to push the patch this weekend. Sorry for the delay.
I'm about to push this. Is it ok to first push it to master and only
backpatch once a couple buildfarm cycles haven't complained?
On Mon, Sep 8, 2014 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It makes for a cleaner commit history if you push concurrently into
all the branches you intend to patch. That also gives more buildfarm
runs, which seems like a good thing for this sort of patch.
That is, assuming that we
On Fri, Sep 5, 2014 at 6:18 PM, Andrew Dunstan and...@dunslane.net wrote:
On 09/05/2014 12:37 PM, Merlin Moncure wrote:
On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug f...@phlo.org wrote:
Cost of hidden IO cast is negative too. If we can change it, then we can
increase a sped.
But the
On Mon, Sep 8, 2014 at 10:08:04AM -0400, Robert Haas wrote:
On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
Yes. I plan to push the patch this weekend. Sorry for the delay.
I'm about to push this. Is it ok to
Hi Fabien-san,
Thank you for your fast work!
2014-09-08 23:08 GMT+09:00 Fabien COELHO coe...@cri.ensmp.fr:
Hello Mutsumara-san,
#3. Documentation
I think modulo operator explanation should put at last at the doc line.
Because the others are more frequently used.
So I like patch3
Robert Haas robertmh...@gmail.com writes:
But what we're talking about here is a bug fix for Sparc. And surely
we ought to back-patch that.
Ah. OK, no objection.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
The attached is seemed no problem. But I'd like to say about order of
explanation in five formulas.
Fix version is here. Please confirm, and I mark it for ready for
commiter.
I'm ok with this version.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Wed, Sep 3, 2014 at 7:34 PM, Tomas Vondra t...@fuzzy.cz wrote:
Well, I think you're certainly right that a hash table lookup is more
expensive than modulo on a 32-bit integer; so much is obvious. But if
join can increase the number of batches on the fly, but only by
doubling it, so you
Hi
I removed dynamic allocation and reduced patch size.
What I tested a old unicode style is same as new unicode style. There
nothing was changed .. some fields are specified in refresh_utf8format
function
Regards
Pavel
2014-09-08 4:44 GMT+02:00 Stephen Frost sfr...@snowman.net:
Pavel,
On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
david.g.johns...@gmail.com wrote:
The implied suggestion is that if I do find any other areas that look like
they need fixing - even in the same file - I should separate them out into a
separate patch.
Yes.
Though I have seen various while I was
On 09/08/2014 03:26 PM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Sep 8, 2014
On Sun, Aug 17, 2014 at 7:46 PM, Fujii Masao masao.fu...@gmail.com wrote:
Thanks for reviewing the patch! ISTM that I failed to make the patch from
my git repository... Attached is the rebased version.
I get some compiler warnings on v2 of this patch:
reloptions.c:219: warning: excess
On Thu, Sep 4, 2014 at 7:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Regarding to the attached three patches:
[1] custom-path and hook
It adds register_custom_path_provider() interface for registration of
custom-path entrypoint. Callbacks are invoked on set_plain_rel_pathlist
to offer
On Fri, Sep 5, 2014 at 6:47 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Client Count/Patch_Ver (tps) 8 16 32 64 128
HEAD 58614 107370 140717 104357 65010
Patch 60092 113564 165014 213848 216065
This data is median of 3 runs, detailed report is attached with mail.
I have not repeated the
On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja ma...@joh.to wrote:
Hi all,
I've updated the patch with a number of changes:
1) I've documented the current limitations of signatures
2) I've expanded section F.25.3 to add information about signatures
(though I'm not sure why this part is
On 09/05/2014 07:30 PM, Alexey Klyukin wrote:
On Thu, Sep 4, 2014 at 10:23 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. Perhaps we should use X509_NAME_get_index_by_NID + X509_NAME_get_entry
instead of X509_NAME_get_text_by_NID. You could then pass the ASN1_STRING
object to the
-debug'
'--with-perl' '--with-openssl' '--with-libxml'
'--with-extra-version=_minmax_20140908_1809_0640c1bfc091'
pgpatches/0095/minmax/20140908/minmax-18.patch
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2014-09-08 7:30 PM, Jeff Janes wrote:
On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja ma...@joh.to wrote:
I've also changed the behaviour when passing a message with a signature to
the decrypt functions which don't verify signatures. They now report
ERROR: Wrong key or corrupt data instead
Erik Rijkers wrote:
Log file says:
TRAP: BadArgument(!(((context) != ((void *)0) (const
Node*)((context)))-type) == T_AllocSetContext, File:
mcxt.c, Line: 752)
2014-09-08 19:54:46.071 CEST 30151 LOG: server process (PID 30336) was
terminated by signal 6: Aborted
2014-09-08
On Fri, Sep 5, 2014 at 9:19 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Apart from above, I think for this patch, cat version bump is required
as I have modified system catalog. However I have not done the
same in
On Fri, Sep 5, 2014 at 3:23 PM, Tomas Vondra t...@fuzzy.cz wrote:
as Heikki mentioned in his commitfest status message, this patch still
has no reviewers :-( Is there anyone willing to pick up that, together
with the 'dense allocation' patch (as those two are closely related)?
I'm looking in
On Mon, Sep 8, 2014 at 1:09 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Don't you need a PG_TRY block here to reset pq_mq_busy?
No. If shm_mq_sendv is interrupted, we can't use the shm_mq any more.
But since that should only happen if an interrupt arrives while the
queue is full, I think
On Mon, Sep 8, 2014 at 2:05 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Another point about error handling is that to execute the sql in
function pg_background_worker_main(), it starts the transaction
which I think doesn't get aborted if error occurs
For this I was just referring error
Stephen Frost wrote:
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
ALTER TABLE ALL IN TABLESPACE xyz
which AFAICS should work since ALL is already a reserved keyword.
Pushed to master and REL9_4_STABLE.
Thanks. One more tweak --- the whole reason for fiddling with this is
On Fri, Sep 5, 2014 at 2:16 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal statement due bigger
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
ALTER TABLE ALL IN TABLESPACE xyz
which AFAICS should work since ALL is already a reserved keyword.
Pushed to master and REL9_4_STABLE.
Thanks. One
On 5 September 2014 14:19, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Apart from above, I think for this patch, cat version bump is required
as I have modified system catalog. However I have not done the
same in
On 8.9.2014 22:44, Robert Haas wrote:
On Fri, Sep 5, 2014 at 3:23 PM, Tomas Vondra t...@fuzzy.cz wrote:
as Heikki mentioned in his commitfest status message, this patch
still has no reviewers :-( Is there anyone willing to pick up that,
together with the 'dense allocation' patch (as those two
On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL]
ml-node+s1045698n5818200...@n5.nabble.com wrote:
On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
[hidden email] http://user/SendEmail.jtp?type=nodenode=5818200i=0
wrote:
One of the trade-offs I mentioned...its more style than
On Mon, Sep 8, 2014 at 6:19 PM, David Johnston david.g.johns...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL]
ml-node+s1045698n5818200...@n5.nabble.com wrote:
On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
[hidden email]
On Mon, Sep 8, 2014 at 10:12 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Sep 5, 2014 at 6:47 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
Client Count/Patch_Ver (tps) 8 16 32 64 128
HEAD 58614 107370 140717 104357 65010
Patch 60092 113564 165014 213848 216065
This data is
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
I've wanted assertions in SQL enough that I often write trivial wrappers
around `raise` in PL/PgSQL
On 09/09/2014 05:20 AM, Robert Haas wrote:
I previously proposed RAISE ASSERT ... WHERE, which seems like a nice
variant of what we've already got, but perhaps this whole discussion
merely illustrates that it's hard to get more than 1 vote for any
proposal in this area.
Well, you have
49 matches
Mail list logo
