Hi David,
On 02.04.2013 22:58, David Gould wrote:
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janesjeff.ja...@gmail.com wrote:
Sorry. I triple checked that the patch was there, but it seems like if you
save a draft with an attachment, when you come back later to finish and
send it, the
the same check in the planner?
I've created a patch using this approach.
I've rebased the above patch against the latest head. Could you review the
patch? If you have no objection, I'd like to mark the patch ready for
committer.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618.patch
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 02.04.2013 22:58, David Gould wrote:
I'll give the patch a try, I have a workload that is impacted by spinlocks
fairly heavily sometimes and this might help or at least give me more
information.
Hi,
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas robertmh...@gmail.com wrote:
The first patch, max-worker-processes-v1.patch, adds a new GUC
max_worker_processes, which defaults to 8. This fixes the problem
discussed here:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.comwrote:
Here's the updated version. It shouldn't contain any obvious WIP pieces
anymore, although I think it needs some more documentation. I am just
not sure where to add it yet, postgres.h seems like a bad place :/
I have
On Sat, Jun 15, 2013 at 1:30 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2013-03-24 at 20:15 -0400, Nicholas White wrote:
I've redone the leadlag function changes to use datumCopy as you
suggested. However, I've had to remove the NOT_USED #ifdef around
datumFree so I can use it to
On 17 June 2013 20:53, Kevin Grittner kgri...@ymail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
On 9 June 2013 12:58, Craig Ringer cr...@2ndquadrant.com wrote:
We don't currently have OLD and NEW relations so we're free to
define how this works pretty freely.
I think the best way,
On 17 June 2013 23:30, Craig Ringer cr...@2ndquadrant.com wrote:
INSERTED and UPDATED could just be views...
Yes, that would be my suggestion.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers
On 18.06.2013 10:52, David Gould wrote:
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangashlinnakan...@vmware.com wrote:
I repeated these pgbench tests I did earlier:
http://www.postgresql.org/message-id/5190e17b.9060...@vmware.com
I concluded in that thread that on this platform, the
Hi,
Should it be: return true if attnum is out of range according to the
tupdesc instead of return NULL if attnum is out of range according
to the tupdesc at src/backend/access/common/heaptuple.c: 1345
/*
* return true if attnum is out of range according to the tupdesc
*/
if (attnum
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.comwrote:
Here's the updated version. It shouldn't contain any obvious WIP pieces
anymore, although I think it needs some more documentation. I am just
not sure where to
Hi,
On 2013-06-18 17:56:34 +0900, Amit Langote wrote:
Should it be: return true if attnum is out of range according to the
tupdesc instead of return NULL if attnum is out of range according
to the tupdesc at src/backend/access/common/heaptuple.c: 1345
/*
* return true if attnum is out of
On Tue, Jun 18, 2013 at 6:01 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2013-06-18 17:56:34 +0900, Amit Langote wrote:
Should it be: return true if attnum is out of range according to the
tupdesc instead of return NULL if attnum is out of range according
to the tupdesc at
On Tue, 18 Jun 2013 11:01:28 +0200
Andres Freund and...@2ndquadrant.com wrote:
/*
* return true if attnum is out of range according to the tupdesc
*/
if (attnum tupleDesc-natts)
return true;
I think the comment is more meaningfull before the change since it
tells us how nonexisting
On 06/16/2013 06:02 PM, Joshua D. Drake wrote:
Instead of pushing extra info to the logs I decided that we could
without giving away extra details per policy. I wrote the error message
in a way that tells the most obvious problems, without admitting to any
of them. Please see attached:
+1 for
Hi,
On 2013-06-18 10:53:25 +0900, Michael Paquier wrote:
diff --git a/contrib/pg_upgrade/info.c b/contrib/pg_upgrade/info.c
index c381f11..3a6342c 100644
--- a/contrib/pg_upgrade/info.c
+++ b/contrib/pg_upgrade/info.c
@@ -321,12 +321,17 @@ get_rel_infos(ClusterInfo *cluster, DbInfo *dbinfo)
On 2013-06-18 05:21:15 -0400, D'Arcy J.M. Cain wrote:
On Tue, 18 Jun 2013 11:01:28 +0200
Andres Freund and...@2ndquadrant.com wrote:
/*
* return true if attnum is out of range according to the tupdesc
*/
if (attnum tupleDesc-natts)
return true;
I think the comment is more
Hi,
review below.
2013-06-13 14:35 keltezéssel, Amit Kapila írta:
On Friday, June 07, 2013 9:45 AM Amit Kapila wrote:
On Thursday, June 06, 2013 10:22 PM Robert Haas wrote:
On Wed, Jun 5, 2013 at 7:24 AM, Amit Kapila amit.kap...@huawei.com
wrote:
On Monday, May 27, 2013 4:17 PM Amit Kapila
2013-06-14 05:12 keltezéssel, Amit Kapila írta:
On Friday, June 14, 2013 3:17 AM Josh Berkus wrote:
On 06/13/2013 05:35 AM, Amit Kapila wrote:
On Friday, June 07, 2013 9:45 AM Amit Kapila wrote:
On Thursday, June 06, 2013 10:22 PM Robert Haas wrote:
On Wed, Jun 5, 2013 at 7:24 AM, Amit
On 18 June 2013 02:33, Robins Tharakan thara...@gmail.com wrote:
Thanks !
PFA the updated patch. Also remove a trailing whitespace at the end of SQL
script.
--
Robins Tharakan
On 17 June 2013 17:29, Szymon Guz mabew...@gmail.com wrote:
On 26 May 2013 19:56, Robins Tharakan
Le mardi 18 juin 2013 04:48:02, Peter Eisentraut a écrit :
On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:
Contributors,
While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all
On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:
Contributors,
While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at
On 17 June 2013 06:33, David Fetter da...@fetter.org wrote:
Next revision of the patch, now with more stability. Thanks, Andrew!
Rebased vs. git master.
Here's my review of the WITH ORDINALITY patch.
Overall I think that the patch is in good shape, and I think that this
will be a very
On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote:
On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:
Contributors,
While going through this mailing list looking for missing 9.4 patches, I
realized that we
On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz mabew...@gmail.com wrote:
Could you add me as a reviewer to commitfest website, set this patch a
reviewed and add this email to the patch history?
I cannot login to the commitfest app, there is some bug with that.
You should be able to do it yourself
On 18 June 2013 13:10, Michael Paquier michael.paqu...@gmail.com wrote:
On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz mabew...@gmail.com wrote:
Could you add me as a reviewer to commitfest website, set this patch a
reviewed and add this email to the patch history?
I cannot login to the
Hello,
I've encountered a memory leak problem when I use a PL/pgsql function which
creates and drops a temporary table. I couldn't find any similar problem in
the mailing list. I'd like to ask you whether this is a PostgreSQL's bug.
Maybe I should post this to pgsql-bugs or pgsql-general,
On Tue, 18 Jun 2013 11:41:06 +0300
Heikki Linnakangas hlinnakan...@vmware.com wrote:
Oh, interesting. What kind of hardware are you running on? To be honest,
I'm not sure what my test hardware is, it's managed by another team
across the world, but /proc/cpuinfo says:
model name:
On Tuesday, June 18, 2013 3:26 PM Boszormenyi Zoltan wrote:
Hi,
review below.
Thanks for the review.
There are 2 options to proceed for this patch for 9.4
1. Upload the SET PERSISTENT syntax patch for coming CF by fixing
existing
review comments
2. Implement new syntax ALTER SYSTEM as
attached the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618-2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18.06.2013 14:27, MauMau wrote:
The cause of the memory increase appears to be CacheMemoryContext. When
I attached to postgres with gdb and ran call
MemoryContextStats(TopMemoryContext) several times, the size of
CacheMemoryContext kept increasing.
Hmm. I could repeat this, and it seems
Hi,
On 2013-06-18 11:35:10 +0200, Andres Freund wrote:
Going to do some performance tests now.
Ok, so ran the worst case load I could think of and didn't notice
any relevant performance changes.
The test I ran was:
CREATE TABLE test_toast(id serial primary key, data text);
ALTER TABLE
I've rebased the current set of pending patches I had, to fix pgxs and added 2
new patches.
Bugfixes have already been presented and sent in another thread, except the
last one which only fix comment in pgxs.mk.
The new feature consists in a new variable to allow the installation of
contrib
2013-06-18 14:11 keltezéssel, Amit Kapila írta:
On Tuesday, June 18, 2013 3:26 PM Boszormenyi Zoltan wrote:
Hi,
review below.
Thanks for the review.
There are 2 options to proceed for this patch for 9.4
1. Upload the SET PERSISTENT syntax patch for coming CF by fixing
existing
review
On Tuesday, June 18, 2013, Amit Kapila wrote:
On Tuesday, June 18, 2013 12:18 AM Sawada Masahiko wrote:
On Sun, Jun 16, 2013 at 2:00 PM, Amit kapila
amit.kap...@huawei.comjavascript:;
wrote:
On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
On Sat, Jun 15, 2013 at 10:34
On 18 June 2013 17:29, Kevin Grittner kgri...@ymail.com wrote:
Szymon Guz mabew...@gmail.com wrote:
I've checked the patch. Applies cleanly. Tests pass this time :)
Could you add me as a reviewer to commitfest website, set this
patch a reviewed and add this email to the patch history?
On Tue, Jun 18, 2013 at 10:53 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
An updated patch for the toast part is attached.
On Tue, Jun 18, 2013 at 3:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
Here are the review comments of the removal_of_reltoastidxid patch.
I've not completed
On Tue, Jun 18, 2013 at 9:54 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2013-06-18 11:35:10 +0200, Andres Freund wrote:
Going to do some performance tests now.
Ok, so ran the worst case load I could think of and didn't notice
any relevant performance changes.
The test I ran
Szymon Guz mabew...@gmail.com wrote:
I've checked the patch. Applies cleanly. Tests pass this time :)
Could you add me as a reviewer to commitfest website, set this
patch a reviewed and add this email to the patch history?
I cannot login to the commitfest app, there is some bug with
that.
Ian Link i...@ilink.io wrote:
This patch contains a performance improvement for the fast gin
cache.
Our test queries improve from about 0.9 ms to 0.030 ms.
Impressive!
Thanks for reading and considering this patch!
Congratulations on your first PostgreSQL patch! To get it
scheduled for
On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tuesday, May 21, 2013, Simon Riggs wrote:
I worked up a small patch to support Terabyte setting for memory.
Which is OK, but it only works for 1TB, not for 2TB or above.
I've incorporated my review into a new
Kevin Grittner kgri...@ymail.com wrote:
You will need to get a community login (if you don't already have
one), but that is a quick and painless process.
Oops -- we seem to have a problem with new community logins at the
moment, which will hopefully be straightened out soon. You might
want to
As I was updating my cross version upgrade tester to include support for
the 9.3 branch, I noted this dump difference between the dump of the
original 9.3 database and the dump of the converted database, which
looks odd. Is it correct?
cheers
andrew
---
Hi Etsuro!
On Tue, Jun 18, 2013 at 4:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jpwrote:
Hi Alexander,
I wrote:
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
resjunk means that the target is not supposed to be output by the
query.
Since it's there at all, it's presumably
Hi All.
I just subscribed to RRReviewers (that should be pronounce with a nice
rolling r-r-reviewers, right?)
As part of my getting up to speed, I tried to build and run test on the
current master 073d7cb513f5de44530f4bdbaaa4b5d4cce5f984
Basically I did:
1) Clone into new dir
2) ./configure
On Thu, 2013-06-13 at 20:09 -0400, Tom Lane wrote:
What I propose we do about this is reduce backend/storage/page/checksum.c
to something like
#include postgres.h
#include storage/checksum.h
#include storage/checksum_impl.h
Attached a new diff for pg_filedump that makes use of the above
Andres Freund and...@2ndquadrant.com wrote:
On 2013-06-18 05:21:15 -0400, D'Arcy J.M. Cain wrote:
On Tue, 18 Jun 2013 11:01:28 +0200
Andres Freund and...@2ndquadrant.com wrote:
/*
* return true if attnum is out of range according to the tupdesc
*/
if (attnum tupleDesc-natts)
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
Here's the updated version. It shouldn't contain any obvious WIP pieces
On Tue, 18 Jun 2013 11:38:45 +0200
Andres Freund and...@2ndquadrant.com wrote:
How about check if attnum is out of range according to the tupdesc
instead?
I can't follow. Minus the word 'NULL' - which carries meaning - your
suggested comment pretty much is the same as the existing comment
On 2013-06-18 13:14:30 -0400, D'Arcy J.M. Cain wrote:
On Tue, 18 Jun 2013 11:38:45 +0200
Andres Freund and...@2ndquadrant.com wrote:
How about check if attnum is out of range according to the tupdesc
instead?
I can't follow. Minus the word 'NULL' - which carries meaning - your
Maybe I am misunderstanding how LATERAL is supposed to work, but my
expectation is that doing a LEFT JOIN should not remove rows from
the LHS. I would expect all of the following select queries would
return a single row, but that isn't the case:
CREATE TABLE i (n integer);
CREATE TABLE j (n
I had a quick play to see what might be involved [attached], and would like
to
hear people thoughts; good idea, bad idea, not like that! etc
I question the usefulness of allowing listen/notify to be restricted to
an entire class of users. The granularity of this seems too broad,
On Tue, 18 Jun 2013 19:19:40 +0200
Andres Freund and...@2ndquadrant.com wrote:
The NULL refers to the *meaning* of the function (remember, it's
called slot_attisnull) . Which is to test whether an attribute is
null. Not to a C NULL.
Actually, the comment is not for the function. It only
On 18 June 2013 17:10, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tuesday, May 21, 2013, Simon Riggs wrote:
I worked up a small patch to support Terabyte setting for memory.
Which is OK, but it only works for 1TB, not
In truth, I hadn't realised somebody had added this to the CF. It was
meant to be an exploration and demonstration that further work was/is
required rather than a production quality submission. AFAICS it is
still limited to '1 TB' only...
At the beginning of the CF, I do a sweep of patch
* Josh Berkus (j...@agliodbs.com) wrote:
Well, I think that someone needs to actually test doing a sort with,
say, 100GB of RAM and make sure it doesn't crash. Anyone have a machine
they can try that on?
It can be valuable to bump up work_mem well beyond the amount of system
memory actually
Amit,
I think, the decision of name, we can leave to committer with below
possibilities,
as it is very difficult to build consensus on any particular name.
Auto.conf
System.auto.conf
Postgresql.auto.conf
Persistent.auto.conf
Reasons for auto.conf as a choice above all of the previous:
On 18 June 2013 18:45, Josh Berkus j...@agliodbs.com wrote:
In truth, I hadn't realised somebody had added this to the CF. It was
meant to be an exploration and demonstration that further work was/is
required rather than a production quality submission. AFAICS it is
still limited to '1 TB'
On 2013-06-18 10:13:39 -0700, Hitoshi Harada wrote:
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
Here's the updated
D'Arcy J.M. Cain da...@druid.net
Although, the more I think about it, the more I think that the comment
is both confusing and superfluous. The code itself is much clearer.
Seriously, if there is any comment there at all, it should be a
succinct explanation for why we didn't do this (which
On 18.06.2013 15:48, Heikki Linnakangas wrote:
On 18.06.2013 14:27, MauMau wrote:
The cause of the memory increase appears to be CacheMemoryContext. When
I attached to postgres with gdb and ran call
MemoryContextStats(TopMemoryContext) several times, the size of
CacheMemoryContext kept
On 06/18/2013 10:59 AM, Simon Riggs wrote:
Thanks. Please delete the patch marked Batch API for After Triggers.
All others are submissions by me.
The CF app doesn't permit deletion of patches, so I marked it returned
with feedback.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
Svenne Krap svenne.li...@krap.dk wrote:
current master 073d7cb513f5de44530f4bdbaaa4b5d4cce5f984
I was surprised to see that an index-test failed.
It works for me. Could you paste or attach some detail?
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Hi Heikki,
I am getting conflicts applying version 22 of this patch to 9.4dev. Could
you rebase?
Does anyone know of an easy way to apply an external patch through git, so
I can get git-style merge conflict markers, rather than getting patch's
reject file?
Cheers,
Jeff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 18:40, Svenne Krap wrote:
Any ideas what might have happened?
After doing some more digging...
My laptop (which runs PostgreSQL 9.2.4 on x86_64-pc-linux-gnu, compiled
by x86_64-pc-linux-gnu-gcc (Gentoo 4.7.3 p1.0, pie-0.5.5)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 20:17, Kevin Grittner wrote:
I was surprised to see that an index-test failed.
It works for me. Could you paste or attach some detail?
Gladly, if you tell me what would be relevant to attach :)
I am brand new to the postgresql
No worries! I'll just wait until it's up again.
Thanks
Ian
Kevin Grittner
Tuesday, June 18,
2013 9:15 AM
Oops -- we seem
to have a problem with new community logins at themoment, which
will hopefully be straightened out soon. You mightwant to wait a
few days if you
Svenne Krap svenne.li...@krap.dk wrote:
On 18-06-2013 20:17, Kevin Grittner wrote:
I was surprised to see that an index-test failed.
It works for me. Could you paste or attach some detail?
Gladly, if you tell me what would be relevant to attach :)
I am brand new to the postgresql source
Hello
related to
https://commitfest.postgresql.org/action/patch_view?id=1130
http://www.postgresql.org/message-id/cabwtf4v9rsjibwe+87pk83mmm7acdrg7sz08rq-4qyme8jv...@mail.gmail.com
* motivation: remove recursive procession of AND/OR list (hangs with
10062 and more subexpressions)
* patch is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 20:48, Kevin Grittner wrote:
Apologies; I somehow missed the file attached to your initial post.
That's the sort of thing I was looking for.
Aplogy accepted... :)
Having reviewed that, the source code comments indicate it is for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:04, Svenne Krap wrote:
(sk@[local]:5432) [sk] \l
List of databases
Name | Owner | Encoding | Collate | Ctype| Access
privileges
-
Arghh... crappy mailer... I have
On Tue, Jun 18, 2013 at 11:20 AM, Svenne Krap svenne.li...@krap.dk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 18:40, Svenne Krap wrote:
Any ideas what might have happened?
After doing some more digging...
My laptop (which runs PostgreSQL 9.2.4 on
Thanks for the review Pavel.
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
related to
https://commitfest.postgresql.org/action/patch_view?id=1130
http://www.postgresql.org/message-id/cabwtf4v9rsjibwe+87pk83mmm7acdrg7sz08rq-4qyme8jv...@mail.gmail.com
Jeff Janes escribió:
On Tue, Jun 18, 2013 at 11:20 AM, Svenne Krap svenne.li...@krap.dk wrote:
As I have no real idea of what ~~ is for an operator (I have looked
it up as scalarltjoinsel), but I cannot find any semantics for it in the
docs*... So I have no way of manually checking the
Svenne Krap svenne.li...@krap.dk wrote:
I have the information attached here instead...
I find it suspicious that the test is using an index which sorts
first by the f1 column, then later by f1 text_pattern_ops
column. I'm not 100% sure whether the test is bad or you have
found a bug, although
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:14, Jeff Janes wrote:
But 9.2.4 does pass make check, and only fails if you reproduce
those things manually?
No, I was lazy and used the (distribution-installed) 9.2
I have tried make check on REL_9_2_4 and that fails to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:41, Svenne Krap wrote:
I will dig futher and get back...
The regression test was added in 9.2, the earliest interesting commit is
d6d5f67b5b98b1685f9158e9d00a726afb2ae789,
where Tom Lane changes the definition to the current.
Svenne Krap svenne.li...@krap.dk wrote:
I am happy to run whatever relevant tests you can dream up, but I am
fresh out of ideas :)
psql regression
begin;
drop index dupindexcols_i;
SELECT count(*) FROM dupindexcols
WHERE f1 'WA' and id 1000 and f1 ~~ 'YX';
rollback;
select f1 from
On Tue, Jun 18, 2013 at 12:51 PM, Svenne Krap svenne.li...@krap.dk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:41, Svenne Krap wrote:
I will dig futher and get back...
The regression test was added in 9.2, the earliest interesting commit is
Jeff Janes jeff.ja...@gmail.com wrote:
The problem is the f1 'WA' part of the query. In Danish,
apparently 'AA' 'WA', so two more rows show up.
Thanks -- I didn't have the right locale installed, and wasn't
quite sure what package to install to get it.
So, the test is bad, rather than
On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
Revised version of patch for additional information storage in GIN is
attached. Changes are mostly bug fixes.
New version of
On Mon, Jun 17, 2013 at 5:09 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 17.06.2013 15:55, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkovaekorot...@gmail.com
**wrote:
attached patch implementing fast scan technique for GIN. This is second
patch
On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 17.06.2013 15:56, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkovaekorot...@gmail.com
**wrote:
This patch introduces new interface method of GIN which takes same
arguments
On Wed, Jun 19, 2013 at 2:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 June 2013 17:10, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tuesday, May 21, 2013, Simon Riggs wrote:
I worked up a small patch to support
Thanks for the reviews. I've attached a revised patch that has the lexer
refactoring Alvaro mentions (arbitarily using a goto rather than a bool
flag) and uses Jeff's idea of just storing the index of the last non-null
value (if there is one) in the window function's context (and not the Datum
From: Heikki Linnakangas hlinnakan...@vmware.com
On 18.06.2013 15:48, Heikki Linnakangas wrote:
Hmm. I could repeat this, and it seems that the catcache for
pg_statistic accumulates negative cache entries. Those slowly take up
the memory.
Digging a bit deeper, this is a rather common problem
On 06/18/2013 01:52 AM, Jeremy Evans wrote:
Maybe I am misunderstanding how LATERAL is supposed to work, but my
expectation is that doing a LEFT JOIN should not remove rows from
the LHS. I would expect all of the following select queries would
return a single row, but that isn't the case:
On Tue, Jun 18, 2013 at 3:40 PM, MauMau maumau...@gmail.com wrote:
From: Heikki Linnakangas hlinnakan...@vmware.com
On 18.06.2013 15:48, Heikki Linnakangas wrote:
Hmm. I could repeat this, and it seems that the catcache for
pg_statistic accumulates negative cache entries. Those slowly take
On Wed, Jun 19, 2013 at 12:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 18, 2013 at 10:53 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
An updated patch for the toast part is attached.
On Tue, Jun 18, 2013 at 3:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
Here are
I'm still getting the same sort of pauses waiting for input with your
v11. This is a pretty frustrating problem; I've spent about two days so
far trying to narrow down how it happens. I've attached the test
program I'm using. It seems related to my picking a throttled rate
that's close to
On Mon, 2013-05-06 at 17:17 +0200, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of the example in the
Hi Alexander,
Thank you for the check! I marked the patch ready for committer.
Best regards,
Etsuro Fujita
From: Alexander Korotkov [mailto:aekorot...@gmail.com]
Sent: Wednesday, June 19, 2013 1:26 AM
To: Etsuro Fujita
Cc: Tom Lane; pgsql-hackers
Subject: Re: [HACKERS] Patch for
On Jun 3, 2013, at 6:45 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 06/04/2013 05:27 AM, Peter Geoghegan wrote:
On Mon, Jun 3, 2013 at 5:03 AM, Craig Ringer cr...@2ndquadrant.com wrote:
I've seen cases on Stack Overflow and elsewhere in which disk merge
sorts perform vastly better than
On Tue, 2013-06-18 at 12:32 +0200, Magnus Hagander wrote:
The CF app was and is specifically for dealing with CFs. Having it
deal with backpatches makes it, well, a bugtracker. It's not meant to
be that. If we want a bugtracker, then it has very different
requirements.
It's not in evidence
On Tue, 2013-06-18 at 15:52 +0200, Cédric Villemain wrote:
This allows for example to install hstore header and be able to
include them
in another extension like that:
# include contrib/hstore/hstore.h
That's not going to work. hstore's header file is included as #include
hstore.h (cf.
On Fri, 2013-06-14 at 09:32 -0400, Andrew Dunstan wrote:
I do think we need to make sure that we have at least buildfarm
coverage of pgxs module building and testing. I have some coverage of
a few extensions I have written, which exercise that, so maybe that
will suffice. If not, maybe we need
On Sun, 2013-06-16 at 18:20 +0200, Cédric Villemain wrote:
Also I suggest to remove the need to set REGRESS at all, and default
to all sql files in REGRESSDIR/sql (if REGRESSDIR is set)
I'm not so sure about that. I have some extensions where the list of
tests is composed at build time
On Mon, 2013-06-17 at 19:00 +0200, Cédric Villemain wrote:
My only grief is to loose the perfect regression tests for PGXS those
contribs are.
I think they are neither perfect nor regression tests. If we want
tests, let's write tests.
--
Sent via pgsql-hackers mailing list
On Mon, 2013-06-17 at 11:41 +0200, Dimitri Fontaine wrote:
I agree that having both cases (sections) in the Makefile is a bad
idea.
Still, why should we keep the in-tree build instructions?
Would it be possible instead to instruct PGXN to work with a non
installed server source tree? And
On Mon, Jun 17, 2013 at 12:36 AM, Robins Tharakan thara...@gmail.comwrote:
Hi,
Did some basic checks on this patch. List-wise feedback below.
[...]
Dear Robins,
Thanks for your review. I attach your considerations to Commit Fest [1].
Regards,
[1]
1 - 100 of 104 matches
Mail list logo
