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
On Tue, Jan 20, 2015 at 11:29 AM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jan 19, 2015 at 5:59 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
You did notice that bowerbird isn't building, right?
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 Tue, Jan 20, 2015 at 6:54 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 19, 2015 at 10:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander
On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund and...@2ndquadrant.com 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
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
On Tue, Jan 20, 2015 at 1:56 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund and...@2ndquadrant.com
wrote:
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
On Mon, Jan 19, 2015 at 12:05:01PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund and...@2ndquadrant.com
wrote:
Sure, but the log isn't invisible. As mentioned one paragraph above, I
don't think it's likely to ever be
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?
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 need
On Tue, Jan 20, 2015 at 9:09 AM, Amit Kapila amit.kapil...@gmail.com
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
On Mon, Jan 19, 2015 at 9:35 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila amit.kapil...@gmail.com
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
On Mon, Jan 19, 2015 at 5:43 PM, Peter Geoghegan p...@heroku.com 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
On Mon, Jan 19, 2015 at 7:47 PM, Michael Paquier
michael.paqu...@gmail.com 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 string.h. */
On 17-01-2015 AM 02:34, Robert Haas wrote:
On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
* It has been repeatedly pointed out that we may want to decouple
partitioning from inheritance because implementing partitioning as an
extension of inheritance
On Mon, Jan 19, 2015 at 5:59 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
You did notice that bowerbird isn't building, right?
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./
On Tue, Jan 20, 2015 at 12:06 AM, Cédric Villemain
ced...@2ndquadrant.com 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
On Mon, Jan 19, 2015 at 11:06 PM, Joe Conway m...@joeconway.com 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
On Wed, Jan 14, 2015 at 1:52 PM, Tomas Vondra
tomas.von...@2ndquadrant.com 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
On Mon, Jan 19, 2015 at 5:33 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
You did notice that bowerbird isn't building, right?
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbirddt=2015-01-19%2023%3A54%3A46
Yeah. Looks like strxfrm_l() isn't available on the animal, for
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
On 10 January 2015 at 15:12, Stephen Frost sfr...@snowman.net 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
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund and...@2ndquadrant.com 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
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 ... */
+
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 @@
2015-01-19 4:54 GMT+01:00 Robert Haas robertmh...@gmail.com:
On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule pavel.steh...@gmail.com
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
On Tue, Jan 20, 2015 at 4:31 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-20 11:05:43 +0900, Michael Paquier wrote:
On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
On 2015-01-19 21:57:20 +0100, Magnus Hagander wrote:
The new site has been
On 2015-01-20 11:05:43 +0900, Michael Paquier wrote:
On Tue, Jan 20, 2015 at 10:09 AM, Andres Freund and...@2ndquadrant.com
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
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
langote_amit...@lab.ntt.co.jp wrote:
* It is desirable to treat partitions as pg_class relations with perhaps
a new relkind(s). We may want to choose an
On Tue, Jan 20, 2015 at 8:47 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Jan 19, 2015 at 11:06 PM, Joe Conway m...@joeconway.com 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
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
On Sun, Dec 28, 2014 at 11:53 PM, Jeff Davis pg...@j-davis.com 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
On Mon, Jan 19, 2015 at 10:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander mag...@hagander.net
wrote:
The new site has been deployed and should now be usable.
On Thu, Jan 15, 2015 at 8:23 PM, Amit Langote
langote_amit...@lab.ntt.co.jp 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
On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com 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
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 one.
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Jan 15, 2015 at 6:03 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
* ONLINE_BACKUP - allows role to perform backup operations
- originally proposed as BACKUP - due to concern for the use of that term
in relation
On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After looking at the code, the minimum-change alternative would be more or
less as attached:
On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
aekorot...@gmail.com 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
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 work to use
On Mon, Jan 19, 2015 at 2:24 AM, Amit Kapila amit.kapil...@gmail.com 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
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 considered under #1
On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com 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
+
On Thu, Jan 15, 2015 at 6:03 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com 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
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
-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
2015-01-19 14:30 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
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
On Mon, Jan 19, 2015 at 5:46 PM, Cédric Villemain ced...@2ndquadrant.com
wrote:
Le lundi 19 janvier 2015 08:24:08 Robert Haas a écrit :
On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
I already wrote quite detailed explanation of subject. Let mel try
Le lundi 19 janvier 2015 08:24:08 Robert Haas a écrit :
On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
aekorot...@gmail.com 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
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
Timmer, Marius marius.tim...@uni-muenster.de 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
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
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 3 November 2014 at 17:08, Stephen Frost sfr...@snowman.net 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
On Mon, Jan 19, 2015 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
On 3 November 2014 at 17:08, Stephen Frost sfr...@snowman.net 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
On 01/19/2015 09:53 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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 of
2015-01-19 14:27 GMT+01:00 Robert Haas robertmh...@gmail.com:
On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com
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,
Le samedi 17 janvier 2015 08:23:44 Michael Paquier a écrit :
On Sat, Jan 17, 2015 at 2:40 AM, Robert Haas
robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund and...@2ndquadrant.com 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,
On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us 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
On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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
On Mon, Jan 19, 2015 at 4:00 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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
* 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 -
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 sfr...@snowman.net
Date: Mon, 12 Jan 2015 17:04:11 -0500
On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund and...@2ndquadrant.com
wrote:
Not this patch's fault, but I'm getting a bit tired seeing the above open
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund and...@2ndquadrant.com
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
On Mon, Jan 19, 2015 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On Fri, Jan 16, 2015 at 10:59 AM, Andres Freund and...@2ndquadrant.com 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 Mon, Jan 19, 2015 at 10:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander mag...@hagander.net
wrote:
The new site has been deployed and should now be usable.
The old site is still available in readonly mode at
On Mon, Jan 19, 2015 at 4:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander mag...@hagander.net 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
On Wed, Dec 31, 2014 at 9:44 AM, Fabien COELHO coe...@cri.ensmp.fr 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
On Mon, Jan 19, 2015 at 3:57 PM, Magnus Hagander mag...@hagander.net 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
On 01/16/2015 07:05 PM, Heikki Linnakangas wrote:
On 01/16/2015 04:17 PM, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@iki.fi 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
On Tue, Dec 2, 2014 at 8:28 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Dec 2, 2014 at 2:16 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Dec 2, 2014 at 2:07 PM, Robert Haas robertmh...@gmail.com wrote:
Well, maybe you should make the updates we've agreed on and I can take
another
On Mon, Jan 19, 2015 at 3:33 PM, Robert Haas robertmh...@gmail.com 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
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
89 matches
Mail list logo
