Hi David,
On 02.04.2013 22:58, David Gould wrote:
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janes 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 attachment may not be there an
like to mark the patch "ready for
committer".
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618.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 Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas 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. Thanks!
>
> Did you ev
Hi,
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas 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:
>
> http://www.postgresql.org/message-id/CA+TgmobguVO+qHnHvxBA2TFkDhw67Y=4bp405fvabec_eto
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund wrote:
>
> 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 a few comments a
On Sat, Jun 15, 2013 at 1:30 PM, Jeff Davis 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 avoid buildin
On 17 June 2013 20:53, Kevin Grittner wrote:
> Simon Riggs wrote:
>> On 9 June 2013 12:58, Craig Ringer 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, if we did do this, would be to have a
>> number
On 17 June 2013 23:30, Craig Ringer 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 mailing list (pgsql-ha
On 18.06.2013 10:52, David Gould wrote:
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas 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 TAS_SPIN macro
really need
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 > tupleD
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund wrote:
>
> >
> > 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,
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 i
On Tue, Jun 18, 2013 at 6:01 PM, Andres Freund 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 src/backend/acces
On Tue, 18 Jun 2013 11:01:28 +0200
Andres Freund 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 columns
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
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 *dbin
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 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 m
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
wrote:
On Monday, May 27, 2013 4:17 PM Amit Kapila wrote:
On Wednesday, A
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 Kapila
On 18 June 2013 02:33, Robins Tharakan 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 wrote:
>
>> On 26 May 2013 19:56, Robins Tharakan wrote:
>>
>>> Hi,
>>>
>>> Please f
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)
On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut 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 all
On 17 June 2013 06:33, David Fetter 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 useful new featur
On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote:
> On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut 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'
On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz 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 by creating a co
On 18 June 2013 13:10, Michael Paquier wrote:
> On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz 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 tha
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, bu
On Tue, 18 Jun 2013 11:41:06 +0300
Heikki Linnakangas 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: Intel(R) Xeon(R) CPU E5-
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 s
ad. Could you review the
> patch? If you have no objection, I'd like to mark the patch "ready for
> committer".
Sorry, I've had a cleanup of the patch. Please find attached the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618-2.patch
Description
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 th
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 test_to
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 he
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 comm
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
> >
> >
> > wrote:
> > > On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
> > > On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila
> > >
On 18 June 2013 17:29, Kevin Grittner wrote:
> Szymon Guz 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 com
On Tue, Jun 18, 2013 at 10:53 AM, Michael Paquier
wrote:
> An updated patch for the toast part is attached.
>
> On Tue, Jun 18, 2013 at 3:26 AM, Fujii Masao wrote:
>> Here are the review comments of the removal_of_reltoastidxid patch.
>> I've not completed the review yet, but I'd like to post the
On Tue, Jun 18, 2013 at 9:54 PM, Andres Freund 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 was:
>
> CREATE
Szymon Guz 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.
It sounded lik
Ian Link 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 review, ple
On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes 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 version, attached.
Kevin Grittner 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 wait a few days
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
--- /home/bf/bfr/root/upgrade/HEAD/origin-
Hi Etsuro!
On Tue, Jun 18, 2013 at 4:15 PM, Etsuro Fujita
wrote:
> 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 referenced by OR
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 --en
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 t
Andres Freund 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 wrote:
>> > > /*
>> > > * return true if attnum is out of range according to the tupdesc
>> > > */
>> > > if (attnum > tupleDesc->natts)
>> > > return true;
>> >
>
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
> On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund >wrote:
> >
> > >
> > > Here's the updated version. It shouldn't contain any obvious WIP pieces
> > > anymore, although I think it needs s
On Tue, 18 Jun 2013 11:38:45 +0200
Andres Freund 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
> except that
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 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 co
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 integ
>> 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 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 describes the
two lines t
On 18 June 2013 17:10, Fujii Masao wrote:
> On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes 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
> 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 p
On 18 June 2013 18:45, Josh Berkus 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' only...
>
>
On 2013-06-18 10:13:39 -0700, Hitoshi Harada wrote:
> On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
>
> > On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund > >wrote:
> > >
> > > >
> > > > Here's the updated version. It shouldn't conta
D'Arcy J.M. Cain
> 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 passes `make
chec
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 increas
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
Svenne Krap 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 Company
--
Sent
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) 4.7.
-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 post
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 don'
Svenne Krap 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 code an
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 sh
-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 fo
-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
On Tue, Jun 18, 2013 at 11:20 AM, Svenne Krap 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 x86_64-pc-linux-gnu
Thanks for the review Pavel.
On Tue, Jun 18, 2013 at 3:01 PM, Pavel Stehule wrote:
> 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:
Jeff Janes escribió:
> On Tue, Jun 18, 2013 at 11:20 AM, Svenne Krap 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 expected resul
Svenne Krap 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 I suspect the l
-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
-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 curre
Svenne Krap 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 dupindexcols where f1 li
On Tue, Jun 18, 2013 at 12:51 PM, Svenne Krap 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
> d6d5f67b5b98b168
Jeff Janes 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 there being a product
On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov wrote:
> On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov > wrote:
>
>> Revised version of patch for additional information storage in GIN is
>> attached. Changes are mostly bug fixes.
>>
>
> New version of patch is attached with some more r
On Mon, Jun 17, 2013 at 5:09 PM, Heikki Linnakangas wrote:
> On 17.06.2013 15:55, Alexander Korotkov wrote:
>
>> On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkov
>> **wrote:
>>
>> attached patch implementing "fast scan" technique for GIN. This is second
>>> patch of GIN improvements, see the
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 Korotkov
>> **wrote:
>>
>> This patch introduces new interface method of GIN which takes same
>>> arguments as co
On Wed, Jun 19, 2013 at 2:40 AM, Simon Riggs wrote:
> On 18 June 2013 17:10, Fujii Masao wrote:
>> On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes 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
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
itse
From: "Heikki Linnakangas"
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 with negative
catcach
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 wrote:
> From: "Heikki Linnakangas"
>
>> 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.
>>>
>>
>>
On Wed, Jun 19, 2013 at 12:36 AM, Fujii Masao wrote:
> On Tue, Jun 18, 2013 at 10:53 AM, Michael Paquier
> wrote:
>> An updated patch for the toast part is attached.
>>
>> On Tue, Jun 18, 2013 at 3:26 AM, Fujii Masao wrote:
>>> Here are the review comments of the removal_of_reltoastidxid patch.
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 (b
On Mon, 2013-05-06 at 17:17 +0200, Dimitri Fontaine wrote:
> Peter Eisentraut 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 documentation.
>
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 r
On Jun 3, 2013, at 6:45 PM, Craig Ringer wrote:
> On 06/04/2013 05:27 AM, Peter Geoghegan wrote:
>> On Mon, Jun 3, 2013 at 5:03 AM, Craig Ringer wrote:
>>> I've seen cases on Stack Overflow and elsewhere in which disk merge
>>> sorts perform vastly better than in-memory quicksort, so the user
>>>
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
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 n
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 depen
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 (pgsql-hacker
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? A
On Mon, Jun 17, 2013 at 12:36 AM, Robins Tharakan wrote:
> 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] https://commitfest.postgresql.org/action/patch_view
1 - 100 of 107 matches
Mail list logo
