> Hackers,
>
> This patch needs a new reviewer, per Cedric. Please help!
Hi I am the new reviewer:-)
I have looked into the v6 patches. One thing I would like to suggest
is, enhancing the error message when temp_file_limit will be exceeded.
ERROR: aborting due to exceeding temp file limit
Is
On Tue, 2011-07-05 at 13:15 -0400, Robert Haas wrote:
> On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas wrote:
> > Here is an updated version of the "lazy vxid locks" patch [1], which
> > applies over the latest "reduce the overhead of frequent table
> > locks"[2] patch.
> >
> > [1] https://commitfest
On Thu, 2011-07-14 at 02:54 +0200, Florian Pflug wrote:
> On Jul14, 2011, at 02:42 , Josh Berkus wrote:
> > lazy vxid locks
> > https://commitfest.postgresql.org/action/patch_view?id=585
>
> I can try to review that. It does seems to depend on
> the fastlock patch though, and that patch seems to b
Excerpts from Florian Pflug's message of mié jul 13 20:12:28 -0400 2011:
> On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
> > One strange thing here is that you could get two such messages; say if a
> > file has 100 parse errors and there are also valid lines that contain
> > bogus settings (foo
On Wed, Jul 13, 2011 at 7:42 PM, Josh Berkus wrote:
> All,
>
> We're almost at the end of the CommitFest, and three patches have not
> yet been reviewed:
>
> lazy vxid locks
> https://commitfest.postgresql.org/action/patch_view?id=585
>
> sepgsql - userspace access vector cache
> https://commitfes
On Jul14, 2011, at 02:42 , Josh Berkus wrote:
> lazy vxid locks
> https://commitfest.postgresql.org/action/patch_view?id=585
I can try to review that. It does seems to depend on
the fastlock patch though, and that patch seems to be
somewhat of a moving target. I'm thus not sure what the
most reaso
I would like to volunteer for the last one:
> Add ability to constrain backend temporary file space
> https://commitfest.postgresql.org/action/patch_view?id=533
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-h
All,
We're almost at the end of the CommitFest, and three patches have not
yet been reviewed:
lazy vxid locks
https://commitfest.postgresql.org/action/patch_view?id=585
sepgsql - userspace access vector cache
https://commitfest.postgresql.org/action/patch_view?id=578
Allow multiple Postgres clu
On Jul13, 2011, at 22:04 , Robert Haas wrote:
> On Jul 12, 2011, at 8:10 PM, Florian Pflug wrote:
>> I wonder if clearing the waiters-present bit only upon clearing the
>> queue completely is necessary for correctness. Wouldn't it be OK
>> to clear the bit after waking up at least one locker? That
On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
> One strange thing here is that you could get two such messages; say if a
> file has 100 parse errors and there are also valid lines that contain
> bogus settings (foo = bar). I don't find this to be too problematic,
> and I think fixing it would b
On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
> - OID of the database in which the object exists, or
> - zero if the object is a shared object, or
> - null if the lock object is on a transaction ID
> + OID of the database in which the lock target exists, or
> + zero
Excerpts from Alexey Kluykin's message of mar jun 21 07:43:02 -0400 2011:
> > Another benefit of removing the check is that it reduces code complexity.
> > Maybe
> > not when measured in line counts, but it's one less outside factor that
> > changes
> > ProcessConfigFiles()'s behaviour and thus
On 14 July 2011 08:16, Robert Haas wrote:
> On Jul 13, 2011, at 4:21 PM, Brendan Jurd wrote:
>> Well, for example, how do you go about answering the question "what is
>> the day-of-month of the infinite timestamp?" The question is
>> nonsense; it doesn't have a defined day of month, so I think w
On Jul 13, 2011, at 4:21 PM, Brendan Jurd wrote:
> On 14 July 2011 06:58, Alvaro Herrera wrote:
>> I don't find the proposed behavior all that suprising, which the
>> original behavior surely is. I guess the bigger question is whether the
>> values that timestamptz_part() returns for other cases
Attached is patch for the WAL writer that removes its tight polling
loop (which probably doesn't get hit often in practice, as we just
sleep if wal_writer_delay is under a second), and, at least
potentially, reduces power consumption when idle by using a latch.
I will break all remaining power con
Robert Haas writes:
> On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
>> I see:
>>
>> if (TIMESTAMP_NOT_FINITE(timestamp))
>> {
>> result = 0;
>> PG_RETURN_FLOAT8(result);
>> }
>>
>> Does anyone object to changing this?
> It's sort of non-obvious that either behavior is better than
> It's sort of non-obvious that either behavior is better than the other.
Here's the reason why the existing behavior is wrong:
postgres=# select extract('epoch' from timestamptz 'infinity') = extract
('epoch' from timestamptz '1970-01-01 00:00:00-00');
?column?
--
t
--
Josh Berkus
P
On 14 July 2011 06:58, Alvaro Herrera wrote:
> I don't find the proposed behavior all that suprising, which the
> original behavior surely is. I guess the bigger question is whether the
> values that timestamptz_part() returns for other cases (than epoch)
> should also be different from 0 when an
Bruce Momjian writes:
> Tom Lane wrote:
>> Another reason not to rely completely on the auto-analyze update path is
>> that it doesn't work for temp tables, since autovac can't access another
>> session's temp tables. It's also worth noting that auto-analyze will
>> never kick in at all for table
Excerpts from Robert Haas's message of mié jul 13 16:13:12 -0400 2011:
> On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
> > Daniele Varrazzo wrote:
> >> =# select extract(epoch from 'infinity'::timestamp);
> >> date_part
> >> ---
> >> 0
> >>
> >> A better value would be 'infin
On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
> Daniele Varrazzo wrote:
>> Hello,
>>
>> =# select extract(epoch from 'infinity'::timestamp);
>> date_part
>> ---
>> 0
>>
>> A better value would be 'infinity'::float8. Ditto for -infinity.
>>
>> I'm trying to use a box-based in
On Jul 12, 2011, at 8:10 PM, Florian Pflug wrote:
> On Jul13, 2011, at 00:10 , Robert Haas wrote:
>> On Jul 12, 2011, at 8:03 AM, Florian Pflug wrote:
>>> The algorithm is quite straight forward, if one assumes a lock-free
>>> implementation of a queue (More on that below)
>>
>> This is similar
"David E. Wheeler" wrote:
> Unless you could make a kind of "view column" or something where the
> expression was `relpersistence <> 't'`.
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't
On Jul 13, 2011, at 12:38 PM, Alvaro Herrera wrote:
>> Well, that assumes people read the documention and don't just do \d.
>> Keeping cruft around over time makes the system more complex.
>
> This seems a case where column synonyms would have been useful (as was
> the procpid / pid change).
Wel
Excerpts from Bruce Momjian's message of mié jul 13 15:24:35 -0400 2011:
> David E. Wheeler wrote:
> > On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
> >
> > >> I'm wondering if it would be possible to restore the relistemp column
> > >> to pg_class, at least for backwards compatibility, so th
David E. Wheeler wrote:
> On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
>
> >> I'm wondering if it would be possible to restore the relistemp column
> >> to pg_class, at least for backwards compatibility, so that apps that
> >> expected it can continue to work on both 9.0 and 9.1. Even if it'
On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
>> I'm wondering if it would be possible to restore the relistemp column
>> to pg_class, at least for backwards compatibility, so that apps that
>> expected it can continue to work on both 9.0 and 9.1. Even if it's
>> read-only somehow, and the sa
David E. Wheeler wrote:
> Hackers,
>
> With regard to this change:
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995
>
> I'm wondering if it would be possible to restore the relistemp column
> to pg_class, at least for backwards c
Tom Lane wrote:
> Another reason not to rely completely on the auto-analyze update path is
> that it doesn't work for temp tables, since autovac can't access another
> session's temp tables. It's also worth noting that auto-analyze will
> never kick in at all for tables of less than about 60 rows,
Andrew Dunstan wrote:
>
>
> On 07/13/2011 12:31 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I think you misunderstood the suggestion. This is not an improvement,
> >>> it's just more confusion.
> >> Well, I thought the "lock on" wording helped avoid the confusion bu
On 13.07.2011 21:56, Alexander Korotkov wrote:
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
Yes, you're right. It's scary that it worked during testing anyway.
Maybe the r
Florian Pflug wrote:
> We could also get rid of the noun completely by saying
>
> (D)
> "Locked page number within the relation, or null if it isn't
>a tuple or relation page that is locked".
>
> I personally slightly favor (D).
I don't think we can use "Locked" here because the lock mig
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
--
With best regards,
Alexander Korotkov.
On 07/13/2011 12:31 PM, Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
Well, I thought the "lock on" wording helped avoid the confusion but
obviously I didn't understand more than that.
Daniele Varrazzo wrote:
> Hello,
>
> =# select extract(epoch from 'infinity'::timestamp);
> date_part
> ---
> 0
>
> A better value would be 'infinity'::float8. Ditto for -infinity.
>
> I'm trying to use a box-based index to represent the intervals in a
> table containing a pair
On 30.06.2011 07:50, Jeff Janes wrote:
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is not surprising that I cann
On 7/12/11 2:05 PM, Fernando Acosta Torrelly wrote:
> Hi everybody:
>
>
>
> Does anybody has an example to send an email in html format using pgmail.
Please send your question to the pgmail mailing list. Nobody on
pgsql-hackers can answer it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://
I wrote:
> HarmeekSingh Bedi writes:
>> I did make a fix at least to alleviate this case in the optimizer . But I am
>> going to work on a more general approach of expression pruning based on the
>> lifetime of an expression. Basically each node will either references or
>> generate an expression.
Hackers,
With regard to this change:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995
I'm wondering if it would be possible to restore the relistemp column to
pg_class, at least for backwards compatibility, so that apps that expected
On 10.07.2011 21:43, Josh Berkus wrote:
Teodor, Oleg, Heikki,
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is n
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you misunderstood the suggestion. This is not an improvement,
>> it's just more confusion.
> Well, I thought the "lock on" wording helped avoid the confusion but
> obviously I didn't understand more than that. We did have similar
> confusion wh
On Jul 13, 2011, at 6:44 AM, Hiroshi Saito wrote:
> Um, Although I have not caught up with this thread.
>
> Ralf-san and the member of OSSP are maintaining OSSP continuously.
> I think that a reaction can merely be obtained in the intervals of when busy.
> Please do not need fast response.
I ha
Florian Pflug wrote:
> On Jul13, 2011, at 17:44 , Tom Lane wrote:
> > Bruce Momjian writes:
> >> OK, I went with this wording, using "lock object is on" terminology.
> >> Applied patch attached --- adjustments welcomed.
> >
> > I think you misunderstood the suggestion. This is not an improvemen
On Jul13, 2011, at 17:44 , Tom Lane wrote:
> Bruce Momjian writes:
>> OK, I went with this wording, using "lock object is on" terminology.
>> Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
F
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I went with this wording, using "lock object is on" terminology.
> > Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
Well, I thought the "lock
HarmeekSingh Bedi writes:
>1. May be I am mistaken Kindly help me understand a bit more. I do agree
>that passing datums up the node chain helps - but consider the case when
>either Sort or Hash joins spills on disk - large columns that get written
> on
>to the disk will still ca
Hi tom .
Thanks for your input . Appreciate your taking time and responding . Just
some comments.
1. May be I am mistaken Kindly help me understand a bit more. I do agree
that passing datums up the node chain helps - but consider the case when
either Sort or Hash joins spills on disk -
Bruce Momjian writes:
> OK, I went with this wording, using "lock object is on" terminology.
> Applied patch attached --- adjustments welcomed.
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
regards, tom lane
--
Sent vi
Florian Pflug wrote:
> On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Florian Pflug writes:
> >>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
> Yeah, I think this patch is going in the wrong direction altogether.
> It would be better to modify the description of
Dean Rasheed writes:
>>> On 7/12/11 9:46 AM, Andres Freund wrote:
I guess $subject wasn't implemented because plain unique indexes aren't
represented in pg_constraint and thus do not have a place to store
information about being deferred?
> I agree that expressing that using a UNIQ
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Another thing that struck me while looking at the code is that the
>> curpages clamp is applied to indexes too, which seems like a
>> thinko. A table occupying a few pages wouldn't likely have an
>> index as big as the table itself is.
> But not zer
Tom Lane wrote:
> Another thing that struck me while looking at the code is that the
> curpages clamp is applied to indexes too, which seems like a
> thinko. A table occupying a few pages wouldn't likely have an
> index as big as the table itself is.
But not zero pages, either.
> So what I'm
On 12.07.2011 11:34, Alexander Korotkov wrote:
New version of patch with a little more refactoring and comments.
Great! The README helps tremendously to understand this, thanks for that.
One thing that caught my eye is that when you empty a buffer, you load
the entire subtree below that buffe
Um, Although I have not caught up with this thread.
Ralf-san and the member of OSSP are maintaining OSSP continuously.
I think that a reaction can merely be obtained in the intervals of when
busy. Please do not need fast response.
(2011/07/13 11:35), David E. Wheeler wrote:
On Jul 12, 2011, a
On 07/13/2011 01:27 AM, Alvaro Herrera wrote:
Excerpts from Alvaro Herrera's message of mié jul 13 01:11:41 -0400 2011:
Blind attempt at fixing isolation_tester on Win32
If this doesn't work, I'm afraid I'll have to ask some Windows person
for help :-)
It appears to have worked.
cheers
an
On 07/13/2011 04:22 AM, Christian Ullrich wrote:
* Alvaro Herrera wrote:
[ ... looks some more ... ] Oh, it seems inconsistent. Several hosts
do not run it at all; chinchilla and anchovy are running the wrong make
target; but at least chough seems to be doing it right. Crake is good
too.
2011/6/29, Florian Pflug :
> Secondly, there is little point in having an type XML if we
> don't actually ensure that values of that type can only contain
> well-formed XML.
+1. The fact that XPATH() must return a type that cannot depend on the
given expression (even if it is a constant string) m
On Wed, Jul 13, 2011 at 12:40 PM, Alexander Korotkov
wrote:
> On Wed, Jul 13, 2011 at 12:33 PM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>
>> Is it possible to switch to the new buffering method in the middle of an
>> index build? We could use the plain insertion method u
Hi!
On Wed, Jul 13, 2011 at 12:33 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Is it possible to switch to the new buffering method in the middle of an
> index build? We could use the plain insertion method until the index grows
> to a certain size (effective_cache_size?
On Tue, 12 Jul 2011 11:11:40 -0700, Josh Berkus wrote:
Radoslaw,
For me this discussion is over. I putted my objections and
suggestions. Full
review is available in archives, and why to not escape is putted in
review
of your 2nd patch, about scalar values.
Did you install and test the funct
Hi,
Looking at the performance test results again on the wiki page
(http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011#Testing_results),
the patch can be summarized like this: it reduces the number of disk
accesses, at the cost of some extra CPU work.
Is it possible to switch to
* Alvaro Herrera wrote:
[ ... looks some more ... ] Oh, it seems inconsistent. Several hosts
do not run it at all; chinchilla and anchovy are running the wrong make
target; but at least chough seems to be doing it right. Crake is good
too.
chinchilla and jaguarundi are now running the buil
On 7 July 2011 22:34, Alvaro Herrera wrote:
> Hi,
>
> The attached patch introduces pg_constraint rows for NOT NULL
> column constraints.
>
> This patch is a heavily reworked version of Bernd Helmle's patch here:
> http://archives.postgresql.org/message-id/E57A252DFD60C1FCA91731BD@amenophis
>
> I
On 13 July 2011 01:23, Andres Freund wrote:
> On Tuesday, July 12, 2011 08:57:44 PM Dean Rasheed wrote:
>> On 12 July 2011 19:26, Josh Berkus wrote:
>> > On 7/12/11 9:46 AM, Andres Freund wrote:
>> >> Hi,
>> >>
>> >> I guess $subject wasn't implemented because plain unique indexes aren't
>> >> re
64 matches
Mail list logo
