Robert Haas writes:
> On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Is there any way that we could get *rid* of custom_variable_classes?
>> Well, we could just drop it and say you can set any dotted-name GUC
>> you feel like.
> ...and the fact that we've made the
On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 15, 2011 at 8:02 PM, Tom Lane wrote:
>>> 2. Tentatively apply the new custom_variable_classes setting if any.
>
>> Is there any way that we could get *rid* of custom_variable_classes?
>> The idea of using a GU
On Sat, Jul 16, 2011 at 10:04 PM, Bruce Momjian wrote:
> This mostly revoles around the problem of trying to finalize 9.1 while
> applying 9.2 patches --- no surprise we don't have enough cycles to do
> that.
Well, sorta. The fact that Josh got his head bitten off for
suggesting that we weren't
Tatsuo Ishii writes:
>> Remember that what will happens is probably:
>>
>> ERROR: aborting due to exceeding temp file limit. Current usage 8000kB,
>> requested size 8008kB, thus it will exceed temp file limit 8kB.
> Could you please elaborate why "Current usage 8000kB" can bigger than
> "temp f
Mark Kirkwood writes:
> This version moves the check *before* we write the new buffer, so
> should take care of issues about really large write buffers, plugins
> etc.
This logic seems pretty obviously wrong:
+ if (temp_file_limit >= 0 && VfdCache[file].fdstate & FD_TEMPORARY)
+ {
+
On Jul 16, 2011, at 7:16 PM, Robert Haas wrote:
> But what happens when and if we add global temporary tables? Now we
> might very well decide to set the faux-relistemp to true for temporary
> and global temporary tables (they do have "temporary" in the name,
> after all!) and false for unlogged
On Fri, Jul 15, 2011 at 8:17 PM, Jim Nasby wrote:
> On Jul 13, 2011, at 2:23 PM, David E. Wheeler wrote:
>> Wasn't newsysviews supposed to deal with these sorts of issues? Why were
>> they rejected?
>
> Unless they recently came up again and got rejected again; the original
> complaint was that
Robert Haas writes:
> On Fri, Jul 15, 2011 at 8:02 PM, Tom Lane wrote:
>> 2. Tentatively apply the new custom_variable_classes setting if any.
> Is there any way that we could get *rid* of custom_variable_classes?
> The idea of using a GUC to define the set of valid GUCs seems
> intrinsically pr
Robert Haas wrote:
> On Fri, Jul 15, 2011 at 5:37 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Alvaro,
> >>
> >> > It seems that by mentioning some people but not all, you offended both
> >> > the people you mentioned (at least some of them, because they are
> >> > already actively helping
On Fri, Jul 15, 2011 at 5:37 PM, Žiga Kranjec wrote:
> Recently we have upgraded our debian system (sid),
> which has since started crashing mysteriously.
> We are still looking into that. It runs on 3ware RAID.
> Postgres package is 8.4.8-2.
>
> The database came back up apparently ok, except
> f
On Sat, Jul 16, 2011 at 12:49 PM, Tom Lane wrote:
> I wrote:
>> Josh Kupershmidt writes:
>>> What's the Description displayed in that table?
>
>> What it ought to be is the comment (if any) attached to the index's
>> column. Up through 8.4 this worked as expected, but in 9.0 and up
>> somebody s
On Fri, Jul 15, 2011 at 8:02 PM, Tom Lane wrote:
> 2. Tentatively apply the new custom_variable_classes setting if any.
Is there any way that we could get *rid* of custom_variable_classes?
The idea of using a GUC to define the set of valid GUCs seems
intrinsically problematic.
--
Robert Haas
En
On Fri, Jul 15, 2011 at 5:37 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Alvaro,
>>
>> > It seems that by mentioning some people but not all, you offended both
>> > the people you mentioned (at least some of them, because they are
>> > already actively helping) and those that you didn't (at l
>> I modeled the original message on what happens when statement timeout is
>> exceeded, which doesn't state its limit in the error message at all -
>> actually I did wonder if there is was informal standard for *not* stating
>> the value of the limit that is being exceeded! However, I agree with y
On Jul16, 2011, at 22:55 , Tom Lane wrote:
> Florian Pflug writes:
>> Btw, if we touch that, I think we should think about providing some way
>> to detect when a backend fails to apply a value.
>
> Hm, maybe, but keep in mind that there are valid reasons for a backend
> to ignore a postgresql.con
Florian Pflug writes:
> Btw, if we touch that, I think we should think about providing some way
> to detect when a backend fails to apply a value.
Hm, maybe, but keep in mind that there are valid reasons for a backend
to ignore a postgresql.conf setting --- in particular, it might have a
local ov
On Jul16, 2011, at 21:23 , Tom Lane wrote:
> Florian Pflug writes:
>> On the downside, the current behaviour prevents problems if someone changes
>> two interrelated GUCs, but makes a mistake at one of them. For example,
>> someone might drastically lower bgwriter_delay but might botch the matchi
Florian Pflug writes:
> On the downside, the current behaviour prevents problems if someone changes
> two interrelated GUCs, but makes a mistake at one of them. For example,
> someone might drastically lower bgwriter_delay but might botch the matching
> adjustment of bgwriter_lru_maxpages.
That's
On Jul16, 2011, at 20:55 , Tom Lane wrote:
>> The original argument for the current behavior was to avoid applying
>> settings from a thoroughly munged config file, but I think that the
>> checks involved in steps 1-3 would be sufficient to reject files that
>> had major problems. It's possible th
Heikki Linnakangas writes:
> I think I would prefer something like this:
> ERROR: could not serialize access due to read/write dependencies among
> transactions
> DETAIL: Reason code: %s
> HINT: The transaction might succeed if retried.
> That's my 2c, anyway. I see you committed this already
I wrote:
> I think that it might be sensible to have the following behavior:
> 1. Parse the file, where "parse" means collect all the name = value
> pairs. Bail out if we find any syntax errors at that level of detail.
> (With this patch, we could report some or all of the syntax errors
> first.)
On 16.07.2011 03:14, Tom Lane wrote:
"Kevin Grittner" writes:
OK, after getting distracted by test failures caused by an unrelated
commit, I've confirmed that this passes my usual tests. I don't
know anything about the tools used for extracting the text for the
translators, so if that needs an
On Sat, Jul 16, 2011 at 01:03:31PM -0500, Kevin Grittner wrote:
> Noah Misch wrote:
>
> > With this patch in its final form, I have completed 180+ suite runs
> > without a failure.
>
> The attached patch allows the tests to pass when
> default_transaction_isolation is stricter than 'read com
"Kevin Grittner" writes:
> Tom Lane wrote:
>> You did miss some places that ought to be updated (mumble
>> sources.sgml mumble)
> Sorry I missed that; sources.sgml covered with the attached.
Oh, I'd already fixed that locally, but thanks. Patch is committed now.
regar
Tom Lane wrote:
> "Kevin Grittner" writes:
>> OK, after getting distracted by test failures caused by an
>> unrelated commit, I've confirmed that this passes my usual tests.
>> I don't know anything about the tools used for extracting the text
>> for the translators, so if that needs any correspo
Noah Misch wrote:
> With this patch in its final form, I have completed 180+ suite runs
> without a failure.
The attached patch allows the tests to pass when
default_transaction_isolation is stricter than 'read committed'.
This is a slight change from the previously posted version of the
fi
On Sat, Jul 16, 2011 at 05:50:45PM +0200, Rémi Zara wrote:
> Isolation tests seem to deadlock on buildfarm member coypu (NetBSD/powerpc
> 5.1).
Thanks for the report and detailed analysis. I believe the patch here will fix
the problem:
http://archives.postgresql.org/message-id/20110716171121.gb2
On Fri, Jul 15, 2011 at 07:01:26PM -0400, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of mié jul 13 01:34:10 -0400 2011:
>
> > coypu failed during the run of the test due to a different session being
> > chosen
> > as the deadlock victim. We can now vary deadlock_timeout to preven
Rémi Zara wrote:
> Isolation tests seem to deadlock on buildfarm member coypu
> (NetBSD/powerpc 5.1).
It looks to me like both the extreme logging of "waiting" messages
and the days-long unrecognized deadlocks are coming from the new "fk"
tests added to the isolation testing schedule.
-Kevin
I wrote:
> Josh Kupershmidt writes:
>> What's the Description displayed in that table?
> What it ought to be is the comment (if any) attached to the index's
> column. Up through 8.4 this worked as expected, but in 9.0 and up
> somebody seems to have disallowed comments on index columns. Not
> s
Josh Kupershmidt writes:
> So, if you look at \d+ newtbl, the right-most column named Description
> should display any comments attached to newtbl's columns. You should
> see "bcol column comment" as the Description for column bcol. That
> works OK.
Right.
> Now, try this:
> test=# \d+ newtbl_i
Hi all,
The psql output for \d+ on indexes, sequences, and views is rather
bogus. Examples below from the SQL at bottom.
So, if you look at \d+ newtbl, the right-most column named Description
should display any comments attached to newtbl's columns. You should
see "bcol column comment" as the Des
On Jul15, 2011, at 23:05 , Josh Berkus wrote:
> * Bugfix for XPATH() if expression returns a scalar value
Well, Peter Eisentraut seemed to disagree with my approach initially,
and seemed to prefer a separate function for XPATH expressions which
return a scalar value.
http://archives.postgresql.
Hi,
Isolation tests seem to deadlock on buildfarm member coypu (NetBSD/powerpc 5.1).
Here are the process for one deadlock (several days) :
pgbuildfarm 2405 0.0 1.2 26948 7916 ? Is Wed02AM0:00.25 postgres:
pgbuildfarm isolationtest [local] INSERT waiting
pgbuildfarm 6559 0.0 0
On Fri, Jul 15, 2011 at 11:37:54PM +0200, Žiga Kranjec wrote:
> Hello!
>
> Recently we have upgraded our debian system (sid),
> which has since started crashing mysteriously.
> We are still looking into that. It runs on 3ware RAID.
> Postgres package is 8.4.8-2.
>
> The database came back up appa
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So, I
From: "Tom Lane"
"MauMau" writes:
I re-submitted a patch and added a comment on the page below. I chose
"patch" from the comment type drop-down box, but the patch status does
not
change from "waiting on author". I expected the patch status would become
"needs review".
No, adding a comment
37 matches
Mail list logo
