2015-01-19 4:54 GMT+01:00 Robert Haas :
> On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule
> wrote:
> > two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
> >
> > Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
>
> I'm cool with that. It's possible that t
On 2015/01/16 1:24, Alvaro Herrera wrote:
Etsuro Fujita wrote:
*** 817,826 InitPlan(QueryDesc *queryDesc, int eflags)
--- 818,833
break;
case ROW_MARK_COPY:
/* there's no real table here ... */
+
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
>> Not this patch's fault, but I'm getting a bit tired seeing the above open
>> coded. How about adding a function that does the sleeping based on a
>> timestamptz and a ms interval?
>
On 10 January 2015 at 15:12, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Currently we're applying RLS CHECKs after the INSERT or UPDATE, like
>> WITH CHECK OPTIONs on views. The SQL spec says that WITH CHECK OPTIONs
>> on views have to be applied after the INSERT/UPD
Hi,
I ran into another typo in execMain.c. Patch attached.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index fcc42fa..bc910f0 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2182,7 +2182,7 @@ Ev
On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
> On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
> > After looking at the code, the minimum-change alternative would be more or
> > less as attached: first, get rid of the long-obsolete proposition that
> > autovacuum workers need fresher-than-usu
On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund wrote:
> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>> On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
>> > After looking at the code, the minimum-change alternative would be more or
>> > less as attached: first, get rid of the long-obsolete p
Haven't looked at this patch, but I wonder if it would be better to
replace the innards of connectby with a rewrite of the query to use
standard WITH queries. Maybe we can remove a couple hundred lines from
tablefunc.c?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Deve
On Mon, Jan 19, 2015 at 2:24 AM, Amit Kapila wrote:
> Okay, I think I got the idea what you want to achieve via
> prefetching. So assuming prefetch_distance = 100 and
> prefetch_increment = 50 (prefetch_distance /2), it seems to me
> that as soon as there are less than 100 blocks in prefetch quot
On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
wrote:
> I already wrote quite detailed explanation of subject. Let mel try to
> explain in shortly. GIN is two level nested btree. Thus, GIN would have
> absolutely same benefits from fillfactor as btree. Lack of tests showing it
> is, for sure,
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> At 2015-01-18 22:28:37 -0500, sfr...@snowman.net wrote:
> >
> > > 2. Set pgaudit.roles = 'r1, r2, …', which logs everything done by r1,
> > >r2, and any of their descendants.
> >
> > If these roles were the 'audit' roles as considere
On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule wrote:
>> I think you should just remove the WARNING, not change it to an error.
>> If somebody wants to quote the operator name to be able to continue
>> using it, I think that's OK.
>
> It looks so quoting doesn't help here
>
> + CREATE OPERATOR "=>
Pavel Stehule wrote:
> It looks so quoting doesn't help here
>
> + CREATE OPERATOR "=>" (
> +leftarg = int8,<--><-->-- right unary
> +procedure = numeric_fac
> + );
> + ERROR: syntax error at or near "("
> + LINE 1: CREATE OPERATOR "=>" (
> + ^
Does it w
On Thu, Jan 15, 2015 at 6:03 PM, Adam Brightwell
wrote:
> * ONLINE_BACKUP - allows role to perform backup operations
> - originally proposed as BACKUP - due to concern for the use of that term
> in relation to other potential backup related permissions this form is in
> line with the documentati
On Thu, Jan 15, 2015 at 8:23 PM, Amit Langote
wrote:
> [ patch to fix a typo ]
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold wrote:
> I attach a patch that solves the issue in pg_dump, let me know if it might
> be included in Commit Fest or if the three other solutions are a better
> choice.
I think a fix in pg_dump is appropriate, so I'd encourage you to add
this to the n
Robert,
Thanks for the feedback.
I'm slightly mystified as to how including the word "online" helps
> here. It's unlikely that there will be an offline_backup permission,
> because if the system is off-line, SQL-level permissions are
> irrelevant.
I'm certainly open to recommendations on this
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 15, 2015 at 6:03 PM, Adam Brightwell
> wrote:
> > * ONLINE_BACKUP - allows role to perform backup operations
> > - originally proposed as BACKUP - due to concern for the use of that term
> > in relation to other potential backup related
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/19/2015 08:16 AM, Alvaro Herrera wrote:
> Haven't looked at this patch, but I wonder if it would be better
> to replace the innards of connectby with a rewrite of the query to
> use standard WITH queries. Maybe we can remove a couple hundred
> l
On 01/19/2015 12:28 AM, Tom Lane wrote:
An alternative would be to remove the pgsql directory at the end of the
run and thus do a complete fresh checkout each run. As you say it would
cost some time but save some space. At least it would be doable as an
option, not sure I'd want to make it non-o
Le lundi 19 janvier 2015 08:24:08 Robert Haas a écrit :
> On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
>
> wrote:
> > I already wrote quite detailed explanation of subject. Let mel try
> > to
> > explain in shortly. GIN is two level nested btree. Thus, GIN would
> > have absolutely same ben
On Mon, Jan 19, 2015 at 5:46 PM, Cédric Villemain
wrote:
> Le lundi 19 janvier 2015 08:24:08 Robert Haas a écrit :
>
> > On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
>
> >
>
> > wrote:
>
> > > I already wrote quite detailed explanation of subject. Let mel try
>
> > > to
>
> > > explain i
Andrew Dunstan writes:
> But I'm wondering if we should look at using the tricks git-new-workdir
> uses, setting up symlinks instead of a full clone. Then we'd have one
> clone with a bunch of different work dirs. That plus a but of explicitly
> done garbage collection and possibly a periodic r
On 3 November 2014 at 17:08, Stephen Frost wrote:
> role attributes don't act like
> GRANTs anyway (there's no ADMIN option and they aren't inheirited).
I'm happy with us *not* doing this using GRANTs, as long as we spend
some love on the docs to show there is a very clear distinction
between th
Le samedi 17 janvier 2015 08:23:44 Michael Paquier a écrit :
> On Sat, Jan 17, 2015 at 2:40 AM, Robert Haas
wrote:
> > There's only value in adding a fillfactor parameter to GIN indexes
> > if
> > it improves performance. There are no benchmarks showing it does.
> > So, why are we still talking a
On 01/19/2015 09:53 AM, Tom Lane wrote:
Andrew Dunstan writes:
But I'm wondering if we should look at using the tricks git-new-workdir
uses, setting up symlinks instead of a full clone. Then we'd have one
clone with a bunch of different work dirs. That plus a but of explicitly
done garbage col
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 3 November 2014 at 17:08, Stephen Frost wrote:
> > role attributes don't act like
> > GRANTs anyway (there's no ADMIN option and they aren't inheirited).
>
> I'm happy with us *not* doing this using GRANTs, as long as we spend
> some love on the d
Robert Haas writes:
> On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund wrote:
>> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>>> I think this is too much of a good thing. I don't see any reason why
>>> autovacuum's statistics need to be fresher than normal, but I also
>>> don't see any reason
Hi Tom,
we are very happy seeing this committed.
Thank you for committing and Mike for the review!!
Your changes make sense to us, except one question:
We think, you wanted to switch to DESC behavior
(print out NULLS FIRST) in cases, where
„USING“ uses an operator which is considered to be
a DE
On Mon, Jan 19, 2015 at 10:35 AM, Tom Lane wrote:
> If that were true I'd agree with you, but it's false on its face.
> A user who is actually examining the statistics might well want to
> know if they're significantly out of date. A very relevant example
> is that I've always wondered how come,
2015-01-19 14:30 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > It looks so quoting doesn't help here
> >
> > + CREATE OPERATOR "=>" (
> > +leftarg = int8,<--><-->-- right unary
> > +procedure = numeric_fac
> > + );
> > + ERROR: syntax error at or near "("
> > + LINE 1: CREAT
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Jan 12, 2015 at 05:16:40PM -0500, Stephen Frost wrote:
> > Alright, here's an updated patch which doesn't return any detail if no
> > values are visible or if only a partial key is visible.
>
> I browsed this patch. There's been no mention
"Timmer, Marius" writes:
> We think, you wanted to switch to DESC behavior
> (print out NULLS FIRST) in cases, where
> USING uses an operator which is considered to be
> a DESC operator.
Right, because that's how addTargetToSortList() would parse it.
> But get_equality_op_for_ordering_op is c
2015-01-19 14:27 GMT+01:00 Robert Haas :
> On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule
> wrote:
> >> I think you should just remove the WARNING, not change it to an error.
> >> If somebody wants to quote the operator name to be able to continue
> >> using it, I think that's OK.
> >
> > It look
Robert Haas writes:
> Sure, but nobody who is not a developer is going to care about that.
> A typical user who sees "pgstat wait timeout", or doesn't, isn't going
> to be able to make anything at all out of that.
Possibly we need to improve the wording of that error message then.
When it was wri
On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
> Robert Haas writes:
> >> I'd be fine with changing the warning to LOG level rather than
> >> suppressing it entirely for the specific case of pgstat_vacuum_stat;
> >> but I do want to distinguish that case, wherein it's fair to conclude
> >> that obs
On Mon, Jan 19, 2015 at 11:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> Sure, but nobody who is not a developer is going to care about that.
>> A typical user who sees "pgstat wait timeout", or doesn't, isn't going
>> to be able to make anything at all out of that.
>
> Possibly we need to impr
Andres Freund writes:
> On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
>> Possibly we need to improve the wording of that error message then.
>> When it was written, we really assumed that it was a can't-happen case
>> and so didn't spend much effort on it. Perhaps it should become a
>> translatab
On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
> >> Possibly we need to improve the wording of that error message then.
> >> When it was written, we really assumed that it was a can't-happen case
> >> and so didn't spend much
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund wrote:
> On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
>> >> Possibly we need to improve the wording of that error message then.
>> >> When it was written, we really assumed
I'm confused. Why does ExecBuildSlotValueDescription() return an empty
string instead of NULL? There doesn't seem to be any value left in that
idea, and returning NULL would make the callsites slightly simpler as
well. (Also, I think the comment on top of it should be updated to
reflect the perm
Tom,
Thanks for the comments on what you ended up changing. It helps point out
the kind of things I should be looking for. I'll try to let less slip
through in the future.
Mike
__
*Mike Blackwell | Technical Analys
On Mon, Jan 19, 2015 at 4:00 AM, Etsuro Fujita
wrote:
> I ran into another typo in execMain.c. Patch attached.
Thanks, committed!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I'm confused. Why does ExecBuildSlotValueDescription() return an empty
> string instead of NULL? There doesn't seem to be any value left in that
> idea, and returning NULL would make the callsites slightly simpler as
> well. (Also, I
* Stephen Frost (sfr...@snowman.net) wrote:
> Updated patch attached.
Ugh. Hit send too quickly. Attached.
Thanks!
Stephen
From f74dcef56bd3507c6bb26b0468655fd8e408fc80 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Mon, 12 Jan 2015 17:04:11 -0500
Subject: [PATCH]
On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
> wrote:
> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
> > wrote:
> >> Not this patch's fault, but I'm getting a bit tired seeing the above open
> >> coded. How about adding a function th
Robert Haas writes:
> On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund
> wrote:
>> Sure, but the log isn't invisible. As mentioned one paragraph above, I
>> don't think it's likely to ever be noticed in the client code in the
>> cases where it happens in production.
> Yes, that is my feeling as
On Fri, Jan 16, 2015 at 10:59 AM, Andres Freund wrote:
> Just consider:
> S1: CREATE TABLE flubber(id serial primary key, data text);
> S1: CREATE FUNCTION blarg() RETURNS TRIGGER LANGUAGE plpgsql AS $$BEGIN
> RETURN NEW; END;$$;
> S1: CREATE TRIGGER flubber_blarg BEFORE INSERT ON flubber FOR EAC
>
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > Given this discussion, I have attached a patch that removes CATUPDATE for
> > review/discussion.
>
> Thanks!
I've added this patch (up-thread) to the next CommitFest (2015-02).
-Adam
--
Adam Brightwell - adam.brightw..
On 01/16/2015 07:05 PM, Heikki Linnakangas wrote:
On 01/16/2015 04:17 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Backpatch to 9.2 like the previous attempt. We haven't made a release that
includes the previous fix yet, so we don't need to worry about changing the
locale of existing cluster
On Tue, Dec 2, 2014 at 8:28 PM, Peter Geoghegan wrote:
> On Tue, Dec 2, 2014 at 2:16 PM, Peter Geoghegan wrote:
>> On Tue, Dec 2, 2014 at 2:07 PM, Robert Haas wrote:
>>> Well, maybe you should make the updates we've agreed on and I can take
>>> another look at it.
>>
>> Agreed.
>
> Attached, rev
On Mon, Jan 19, 2015 at 3:33 PM, Robert Haas wrote:
> All right, it seems Tom is with you on that point, so after some
> study, I've committed this with very minor modifications. Sorry for
> the long delay. I have not committed the 0002 patch, though, because
> I haven't studied that enough yet
Today is your last day to submit your PGCon 2015 proposal.
--
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Robert Haas (robertmh...@gmail.com) wrote:
> On the PPC64 machine I normally use for performance testing, it takes
> about 6.3 seconds to build the index with the commit just before this
> one. With this commit, it drops to 1.9 seconds. That's more than a
> 3x speedup!
>
> Now, if I change the
On Wed, Dec 31, 2014 at 9:44 AM, Fabien COELHO wrote:
> Here is a slight update so that type names are treated homogeneously between
> both added paragraphs.
>
> ITSM that this patch should be committed without further ado.
I had a look at this patch. This patch adds some text below a table
of f
On Mon, Jan 19, 2015 at 3:16 AM, Michael Paquier
wrote:
> On Tue, Jan 13, 2015 at 2:35 PM, Magnus Hagander
> wrote:
> > Further status updates to come as we start working on it...
>
> Things are looking good so far. All the information has been synced up
> between both apps for the current CF an
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander wrote:
> The new site has been deployed and should now be usable.
>
> The old site is still available in readonly mode at
> https://commitfest-old.postgresql.org/.
These links, which were originally requested by Tom and which I have
bookmarked, use
On Mon, Jan 19, 2015 at 10:01 PM, Robert Haas wrote:
> On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
> wrote:
> > The new site has been deployed and should now be usable.
> >
> > The old site is still available in readonly mode at
> > https://commitfest-old.postgresql.org/.
>
> These links, w
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander wrote:
> The new site has been deployed and should now be usable.
There are, for some reason, three copies of "Clarify need for memory
barriers in bgworkers" in the in-progress CF. I don't know why that
happened, or how to fix it.
Also, the old a
On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas wrote:
> On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander wrote:
>> The new site has been deployed and should now be usable.
>
> There are, for some reason, three copies of "Clarify need for memory
> barriers in bgworkers" in the in-progress CF. I don
On Mon, Jan 19, 2015 at 10:03 PM, Magnus Hagander
wrote:
> On Mon, Jan 19, 2015 at 10:01 PM, Robert Haas
> wrote:
>
>> On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
>> wrote:
>> > The new site has been deployed and should now be usable.
>> >
>> > The old site is still available in readonly m
On Mon, Jan 19, 2015 at 10:05 PM, Robert Haas wrote:
> On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
> wrote:
> > The new site has been deployed and should now be usable.
>
> There are, for some reason, three copies of "Clarify need for memory
> barriers in bgworkers" in the in-progress CF.
On Mon, Jan 19, 2015 at 10:10 PM, Robert Haas wrote:
> On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas
> wrote:
> > On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
> wrote:
> >> The new site has been deployed and should now be usable.
> >
> > There are, for some reason, three copies of "Clarify n
On 2015-01-18 17:48:11 -0500, Tom Lane wrote:
> One of the biggest causes of buildfarm run failures is "out of disk
> space". That's not just because people are running buildfarm critters
> on small slow machines; it's because "make check-world" is an enormous
> space hog. Some numbers from curre
On Mon, Jan 19, 2015 at 12:33 PM, Robert Haas wrote:
> All right, it seems Tom is with you on that point, so after some
> study, I've committed this with very minor modifications. Sorry for
> the long delay.
Thank you very much for your help with this! I appreciate it.
> I have not committed th
On 01/19/2015 06:14 PM, Robert Haas wrote:
On Fri, Jan 16, 2015 at 10:59 AM, Andres Freund wrote:
This will give you: The old trigger name. The new table name. The new
column name. The new function name.
Ouch. That's clearly no good. I'm struggling to understand whether
this is a problem wi
On Tue, Jan 20, 2015 at 6:54 AM, Magnus Hagander wrote:
> On Mon, Jan 19, 2015 at 10:10 PM, Robert Haas wrote:
>>
>> On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas
>> wrote:
>> > On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
>> > wrote:
>> >> The new site has been deployed and should now be us
On Tue, Jan 20, 2015 at 12:06 AM, Cédric Villemain
wrote:
> Michael, I first didn't understood how GiN can benefits from the
> patch...thus my question.
>
> There were no noise for me, and I learn some more about GiN. So I thank you
> for your work!
Kicking back the ball, I haven't done as much wo
On Mon, Jan 19, 2015 at 11:06 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/19/2015 08:16 AM, Alvaro Herrera wrote:
>> Haven't looked at this patch, but I wonder if it would be better
>> to replace the innards of connectby with a rewrite of the query to
>> use s
On Wed, Jan 14, 2015 at 1:52 PM, Tomas Vondra
wrote:
> Attached is v8 patch, with a few comments added:
>
> 1) before initArrayResult() - explaining when it's better to use a
>single memory context, and when it's more efficient to use a
>separate memory context for each array build state
>
Hello, the new app's clean looking gets my favor and the
integrated operation will do good for me:)
By the way, I got the following notice when I tried to "Add
comment" on the new app.
"Note!: This form will generate an email to the public
mailinglist pgsql-hackers, with sender set to
horiguchi
Hi all,
Here is a continuation of the thread which covered $subject for MinGW
and Cygwin:
http://www.postgresql.org/message-id/51f19059.7050...@pgexperts.com
But this time it is for MSVC.
Just a bit of background... Since commit cb4a3b04 we are installing
shared libraries in bin/ and lib/ for Cyg
Hi,
On 2015-01-19 21:57:20 +0100, Magnus Hagander wrote:
> The new site has been deployed and should now be usable.
I think this unfortunately lost the RSS feature? I found that quite
useful to see who changed what recently (it's forwared to an imap
mailbox for me...).
What I'm also missing from
On Mon, Jan 19, 2015 at 12:05:01PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund
> > wrote:
> >> Sure, but the log isn't invisible. As mentioned one paragraph above, I
> >> don't think it's likely to ever be noticed in the client code in the
> >
On Mon, Jan 19, 2015 at 5:43 PM, Peter Geoghegan wrote:
> It appears that the buildfarm animal brolga isn't happy about this
> patch. I'm not sure why, since I thought we already figured out bugs
> or other inconsistencies in various strxfrm() implementations.
Well, the first thing that comes to
Peter Geoghegan wrote:
> It appears that the buildfarm animal brolga isn't happy about this
> patch. I'm not sure why, since I thought we already figured out bugs
> or other inconsistencies in various strxfrm() implementations.
You did notice that bowerbird isn't building, right?
http://buildfarm
On 17-01-2015 AM 02:34, Robert Haas wrote:
> On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
> wrote:
>> * It has been repeatedly pointed out that we may want to decouple
>> partitioning from inheritance because implementing partitioning as an
>> extension of inheritance mechanism means that we have
On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
wrote:
> You did notice that bowerbird isn't building, right?
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2015-01-19%2023%3A54%3A46
Yeah. Looks like strxfrm_l() isn't available on the animal, for whatever reason.
--
Peter
On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund wrote:
> Hi,
>
> On 2015-01-19 21:57:20 +0100, Magnus Hagander wrote:
>> The new site has been deployed and should now be usable.
>
> I think this unfortunately lost the RSS feature? I found that quite
> useful to see who changed what recently (it's
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> > It seems that the reason for this is to be consistent with
> > BuildIndexValueDescription, which seems to do the same thing to simplify
> > the stuff going on at check_exclusion_constraint() -- by returning an
> > empty string, that code doesn't
On Mon, Jan 19, 2015 at 5:59 PM, Peter Geoghegan wrote:
> On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
> wrote:
>> You did notice that bowerbird isn't building, right?
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2015-01-19%2023%3A54%3A46
>
> Yeah. Looks like strxfrm_
On 1/19/15 1:07 PM, Andres Freund wrote:
On 2015-01-18 17:48:11 -0500, Tom Lane wrote:
One of the biggest causes of buildfarm run failures is "out of disk
space". That's not just because people are running buildfarm critters
on small slow machines; it's because "make check-world" is an enormous
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Attached is a patch to make RLS checks run before attempting to
> insert/update any data rather than afterwards.
Excellent, many thanks!
> In the end I decided not to create a new structure for RLS checks
> because most of the code that ha
On 2015/01/20 1:44, Robert Haas wrote:
On Mon, Jan 19, 2015 at 4:00 AM, Etsuro Fujita
wrote:
I ran into another typo in execMain.c. Patch attached.
Thanks, committed!
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Mon, Jan 19, 2015 at 9:35 AM, Robert Haas wrote:
>
> On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila
wrote:
> > So are you telling that whenever we read, save the settings
> > to some catalog (probably a new one)?
>
> Which process are you imagining would do this? Certainly not the
postmaster.
On Tue, Jan 20, 2015 at 9:09 AM, Amit Kapila
wrote:
>
>
> Right, but we can't completely eliminate such a possibility (as an
> example we have some default settings like max_connections,
> shared_buffers, etc). I agree with you that users should use only
> way
Sorry for incomplete sentence, I me
On Tue, Jan 20, 2015 at 11:29 AM, Peter Geoghegan wrote:
> On Mon, Jan 19, 2015 at 5:59 PM, Peter Geoghegan wrote:
>> On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
>> wrote:
>>> You did notice that bowerbird isn't building, right?
>>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowe
Was slightly optimistic that this comment in the release notes might mean
that my bug with bloat on hot tables might have been fixed in 9.4
/Make VACUUM properly report dead but not-yet-removable rows to the
statistics collector (Hari Babu)
Previously these were reported as live rows./
Unfortuna
On Tue, Jan 20, 2015 at 1:56 AM, Andres Freund wrote:
> On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
>> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
>> wrote:
>> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
>> > wrote:
>> >> Not this patch's fault, but I'm getting a bit tired se
On Mon, Jan 19, 2015 at 7:47 PM, Michael Paquier
wrote:
> On MinGW-32, not that I know of:
> $ find . -name *.h | xgrep strxfrm_l
> ./lib/gcc/mingw32/4.8.1/include/c++/mingw32/bits/c++config.h:/* Define if
> strxfr
> m_l is available in . */
> ./mingw32/lib/gcc/mingw32/4.8.1/include/c++/mingw32/b
I think its telling that varying the fetch size doubled the performance,
even on localhost. If you were to repeat this test across a network, the
performance difference would be far more drastic.
I understand the desire to keep the fetch size small by default, but I
think your results demonstrate
At 2015-01-19 08:26:59 -0500, sfr...@snowman.net wrote:
>
> I'm confused by this statement..
Let me see if I've understood your clarification:
Suppose you have pgaudit.roles set to 'r0, r1', and that you have
granted r0 to u0.
Now, if you're connected to the database as r0 or r1, then everything
On Mon, Jan 19, 2015 at 11:05:22AM -0500, Stephen Frost wrote:
> One remaining question is about single-column key violations. Should we
> special-case those and allow them to be shown or no? I can't see a
> reason not to currently but I wonder if we might have cause to act
> differently in the f
On 20-01-2015 AM 10:48, Amit Langote wrote:
> On 17-01-2015 AM 02:34, Robert Haas wrote:
>> On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
>> wrote:
>>> * It is desirable to treat partitions as pg_class relations with perhaps
>>> a new relkind(s). We may want to choose an implementation where only
On Tue, Jan 20, 2015 at 8:47 AM, Michael Paquier
wrote:
> On Mon, Jan 19, 2015 at 11:06 PM, Joe Conway wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 01/19/2015 08:16 AM, Alvaro Herrera wrote:
>>> Haven't looked at this patch, but I wonder if it would be better
>>> to replace
On Sun, Dec 28, 2014 at 11:53 PM, Jeff Davis wrote:
> On Tue, 2014-04-01 at 13:08 -0400, Tom Lane wrote:
>> I think a patch that stood a chance of getting committed would need to
>> detect whether the aggregate was being called in simple or grouped
>> contexts, and apply different behaviors in the
On 2015-01-20 11:05:43 +0900, Michael Paquier wrote:
> On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund
> wrote:
> > Hi,
> >
> > On 2015-01-19 21:57:20 +0100, Magnus Hagander wrote:
> >> The new site has been deployed and should now be usable.
> >
> > I think this unfortunately lost the RSS featur
On Tue, Jan 20, 2015 at 4:31 PM, Andres Freund wrote:
> On 2015-01-20 11:05:43 +0900, Michael Paquier wrote:
>> On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund
>> wrote:
>> > Hi,
>> >
>> > On 2015-01-19 21:57:20 +0100, Magnus Hagander wrote:
>> >> The new site has been deployed and should now be
98 matches
Mail list logo
