Peter Eisentraut 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 build is one
Peter Eisentraut 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
>> a
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas 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 stage; in pa
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut 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 tha
Amit kapila 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 no bearing on what l
Hi,
On Wednesday, September 05, 2012 06:00:18 PM Tom Lane wrote:
> "anara...@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 without loopi
Andrew Dunstan writes:
> On 09/09/2012 03:29 AM, Tom Lane wrote:
>> Peter Eisentraut 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
.
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
tha
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 Pete
Andrew Dunstan 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 seems like a
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
> cha
I noticed a sentence in sepgsql says 180-degree opposite at:
When DROP command is executed, drop will be
checked on the object being removed for each object types. Permissions
"will not be" checked for objects dropped indirectly via CASCADE.
This should be "will also be", as our implementa
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 b
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 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 defined. (The problem
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 sou
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 20
Andrew Dunstan 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 worth trying to
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
>> wrote:
>>>
>>> A complete run of this process takes less than 15 minutes. And as I have
>>> pointed out elsewhere that could be reduced substantial
On Sunday, September 09, 2012 08:40:38 PM Tom Lane wrote:
> Andres Freund 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
>
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
On Sun, 2012-09-09 at 14:57 -0400, Tom Lane wrote:
> Andrew Dunstan 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,
Peter Eisentraut 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 fix
>> to
Peter Eisentraut 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 practical for pack
On 09/09/2012 05:00 PM, Tom Lane wrote:
Peter Eisentraut 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 p
> From: Robert Haas [mailto:robertmh...@gmail.com]
> 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 you. Sorry for th
On Sunday, September 09, 2012 8:46 PM Tom Lane wrote:
Amit kapila 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
27 matches
Mail list logo
