On Fri, Sep 7, 2012 at 11:40 AM, Gezeala M. Bacuño II geze...@gmail.com wrote:
adding pgsql-bugs list in case OP posts back.
On Fri, Sep 7, 2012 at 11:29 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
(Adding -hackers. Did not realize it got dropped)
On Fri, Sep 7, 2012 at 11:25 PM,
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.NOTPARALLEL in ecpg/Makefile,
I'd hate that, because the ecpg
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-08 at 19:18 -0400, Tom Lane wrote:
To give you an idea of what unreasonably painful means, attached is
the specfile diff needed to make this happen. I will not comment on
the fragility of this beyond observing that the touch -r commands
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
I've not done anything yet about the potential security issues
associated with untrusted libpq connection strings. I think this
is still at the proof-of-concept
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.NOTPARALLEL in
Amit kapila amit.kap...@huawei.com writes:
1. does this follow the behavior that admin users will not be allowed to
invoke postgres child process?
That's an interesting question. I'm not sure if we'd want to disable
the no-root check on the Unix side, but it might make sense to. But
this has
Hi,
On Wednesday, September 05, 2012 06:00:18 PM Tom Lane wrote:
anara...@anarazel.de and...@anarazel.de writes:
I am not saying its bad that it is slower, that's absolutely OK. Just
that it will take a variable amount of time till you can run pgdump
again and its not easily detectable
Andrew Dunstan and...@dunslane.net writes:
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need
Hi Alvaro,
Thanks for the review!
On Thursday, September 06, 2012 06:09:35 PM Alvaro Herrera wrote:
Here's a prettified version of this stuff. I found one bug in the macro
ilist_s_head: the test was reversed.
Oh, good catch. I had only used the _unchecked version because my code checked
that
On 09/09/2012 11:31 AM, Tom Lane wrote:
Yeah. I am going to add a config parameter to the buildfarm to allow
parallelism for the make and make contrib stages, but I'm not going
to release it until this is fixed.
Well, why don't we stick .NOTPARALLEL in there for the moment, and then
if Peter
Andrew Dunstan and...@dunslane.net writes:
On 09/09/2012 11:31 AM, Tom Lane wrote:
I assume we need this for all active branches, if the buildfarm is
going to be stressing it?
I can restrict it to only modern branches. Didn't we supposedly improve
support for this during the 9.1 cycle? That
Hi Alvaro, hi all,
On Tuesday, September 04, 2012 09:33:54 PM Alvaro Herrera wrote:
Excerpts from Andres Freund's message of jue jul 19 06:29:03 -0400 2012:
Hi,
Attached is v2 of the patch.
Hello,
I gave this code a quick read some days ago. Here's the stuff I would
change:
*
I noticed a sentence in sepgsql says 180-degree opposite at:
When literalDROP/ command is executed, literaldrop/ will be
checked on the object being removed for each object types. Permissions
will not be checked for objects dropped indirectly via literalCASCADE/.
This should be will also
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And given that the bug report on savannah
has
On 09/09/2012 02:05 PM, Tom Lane wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, September 04, 2012 09:33:54 PM Alvaro Herrera wrote:
* There are way too many #ifdef VERBOSE_DEBUG stuff for my taste. It
might look better if you had macros such as elog_debug() that are defined
to empty if VERBOSE_DEBUG is not
On 09/06/2012 12:13 AM, Peter Eisentraut wrote:
On 8/29/12 11:52 PM, Andrew Dunstan wrote:
Why does this need to be tied into the build farm? Someone can surely
set up a script that just runs the docs build at every check-in, like it
used to work. What's being proposed now just sounds like a
On 09/06/2012 03:43 AM, Bruce Momjian wrote:
On Wed, Sep 5, 2012 at 09:33:35PM -0400, Andrew Dunstan wrote:
On 09/05/2012 09:25 PM, Bruce Momjian wrote:
On Wed, Sep 5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012:
Andrew
Andrew Dunstan and...@dunslane.net writes:
On 09/09/2012 02:05 PM, Tom Lane wrote:
And the answer is ... it's a gmake bug.
Thanks for pursuing this. Whether or not it masks the underlying
problem, it's still something we should do, no? In fact, it seems to me
like this makes it even less
On 09/07/2012 06:50 PM, Andrew Dunstan wrote:
On 09/07/2012 09:57 AM, Magnus Hagander wrote:
On Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net
wrote:
A complete run of this process takes less than 15 minutes. And as I have
pointed out elsewhere that could be reduced
On Sunday, September 09, 2012 08:40:38 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, September 04, 2012 09:33:54 PM Alvaro Herrera wrote:
* There are way too many #ifdef VERBOSE_DEBUG stuff for my taste. It
might look better if you had macros such as
On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's
On Sun, 2012-09-09 at 14:57 -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 09/09/2012 02:05 PM, Tom Lane wrote:
And the answer is ... it's a gmake bug.
Thanks for pursuing this. Whether or not it masks the underlying
problem, it's still something we should do, no?
Peter Eisentraut pete...@gmx.net writes:
On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And given that the bug report on savannah
has been ignored for two years, we should not hold our breath for a
Peter Eisentraut pete...@gmx.net writes:
But then the answer could be, if you want to use parallel make, use a
version that's not broken.
That's not a terribly practical answer for people who use the make
supplied by their OS vendor, which is approximately 99.9% of people.
It's even less
On 09/09/2012 05:00 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
But then the answer could be, if you want to use parallel make, use a
version that's not broken.
That's not a terribly practical answer for people who use the make
supplied by their OS vendor, which is
From: Robert Haas [mailto:robertmh...@gmail.com]
fujita.ets...@lab.ntt.co.jp wrote:
I noticed the syntax of the \copy command in the psql reference page is an
old
style. ISTM it's better to update the document. Please find attached a
patch.
Seems reasonable to me. Committed.
Thank
On Sunday, September 09, 2012 8:46 PM Tom Lane wrote:
Amit kapila amit.kap...@huawei.com writes:
1. does this follow the behavior that admin users will not be allowed to
invoke postgres child process?
That's an interesting question. I'm not sure if we'd want to disable
the no-root check on
28 matches
Mail list logo
