Just Curious, which postgresql server version bug has been fixed ?. is it existing on 8.1.3 and under which circumstances ?.
On 3/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Tatsuo Ishii <[EMAIL PROTECTED]> writes:> It seems I get a segfault in backend if autovacuum is enabled.
Fixed, thanks for r
Tom,
On 3/7/06 8:03 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Luke Lonergan" <[EMAIL PROTECTED]> writes:
>> Two passes is the state-of-the-practice on external disk sorts.
>
> There is no such thing as a fixed number of passes regardless of
> available memory and size of the data.
While tech
People:
> > Uh oh, $50 sounds light for downtown; you aren't thinking of doing
> > this
> > thing somewhere out in Toronto's nigh infinite suburbs are you?
Since Ryerson is a university, they will rent us some dorm rooms for a cost
below that of nearby hotels for the budget-conscious.
BTW, the
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 3/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > However, now that we've changed the code to prefer large numbers of tapes,
> > it's not at all clear that Algorithm D is still the right one to use. In
> > particular I'm looking at cascade merge
Mark Kirkwood wrote:
Tatsuo Ishii wrote:
BTW, I found the answer to my question myself by reading the source
code: if that's an index, then blockfreebytes is explicitly set to 0.
I suggest that this should be noted in the README and in this case
blockfreebytes is better to set to NULL, rather t
Title: Re: [HACKERS] Merge algorithms for large numbers of "tapes"
Yes – all of the current best practice external sorts use two passes. A first to produce the runs, which results in “S” number of “files”, then a single merge pass across the runs. At most 1 pass across the S runs is required t
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> Two passes is the state-of-the-practice on external disk sorts.
There is no such thing as a fixed number of passes regardless of
available memory and size of the data.
regards, tom lane
---(end of broad
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > This seems pretty widespread.
>
> Try "universal" --- Bruce broke both contrib and PL regression tests
> last night, by not updating them for the change of escape_string_warning
> default.
I have updated the /contrib and PL regr
Tom,
> fewer passes when T is large. Do you want to try that?
Two passes is the state-of-the-practice on external disk sorts.
If we¹re looking to replace the tape sort approach, I would hope for a two
pass approach, with the merge pass avoided in the case of unidirectional
access.
- Luke
--
Use a priority queue for the sorted sub-lists.
When the key-object extracted from the head of the smallest queue exceeds the key-object
from the head of the second queue, adjust the priority of the smallest queue
within the list of queues.
It uses a total of 2 read/write passes
over th
Patch withdrawn by author for reworking.
---
ITAGAKI Takahiro wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > > CREATE INDEX foo ON bar (x) WITH (fillfactor = 70, option = blah);
> >
> > Yeah, something along this line
On 3/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
BTW, I was just looking over Knuth's discussion of sorting again, andrealized that there is still something more that could be done withinthe existing sort framework. We currently use standard polyphase merge
(his Algorithm 5.4.2D), which IIRC I chose
Tatsuo Ishii wrote:
> Just for curiousity, why FSM gathers info for indexes? I thought FSM
> is only good for tables.
It's part of the implementation of the page-recycling algorithm for
btrees Tom did for 7.4. When a btree page is empty after a vacuum, it's
entered in the free space map. When a
> > BTW, I found the answer to my question myself by reading the source
> > code: if that's an index, then blockfreebytes is explicitly set to 0.
> > I suggest that this should be noted in the README and in this case
> > blockfreebytes is better to set to NULL, rather than 0.
> >
>
> Good points!
Tom Lane wrote:
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
I have another question -- why is the view showing relfilenode and
reltablespace? I imagine it should be showing the relation Oid instead.
I guess that's because FSM keeps those info, not relation oid.
Righ
Tatsuo Ishii wrote:
Peter Eisentraut wrote:
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
-+-+---+-
BTW, I was just looking over Knuth's discussion of sorting again, and
realized that there is still something more that could be done within
the existing sort framework. We currently use standard polyphase merge
(his Algorithm 5.4.2D), which IIRC I chose because it was simple and
for relatively sma
Martijn van Oosterhout writes:
> #ifdef STATIC_ANALYSIS
> #define ereport(elevel, rest) \
> (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \
> (errfinish rest) : (void) 0), (elevel >= ERROR ? exit(0) : 0)
> #else
> /* Normal def */
> #endif
Hmm, neat idea ... though
On Tue, Mar 07, 2006 at 05:10:44PM -0500, Greg Stark wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > but they do make the mistake of not noticing that ereport(ERROR)
> > does not continue execution.
>
> There is a way in gcc to indicate that a function never returns. But in
> Postgr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> but they do make the mistake of not noticing that ereport(ERROR)
> does not continue execution.
There is a way in gcc to indicate that a function never returns. But in
Postgres it's a bit weird since elog()/ereport() sometimes return and
sometimes do
I wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> samples %symbol name
>> 24915704 96.2170 ltsReleaseBlock
> We probably need to tweak things so this doesn't get called during the
> "final merge" pass. Looking at it now.
I've committed a fix for this into CVS HEAD --- plea
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It seems I get a segfault in backend if autovacuum is enabled.
Fixed, thanks for report.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space m
On Tue, 2006-03-07 at 11:04 -0500, Greg Stark wrote:
>
>
> Uh oh, $50 sounds light for downtown; you aren't thinking of doing
> this
> thing somewhere out in Toronto's nigh infinite suburbs are you?
The Bay Street Hotel has rooms for about $60/night and is located within
a 7 minute walk of Ryer
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Having to change the types to shells, then drop the IO, then drop the
> type seems like a 'gotcha' and a bunch of needless extra work.
Depends. From pg_dump's perspective it's easier to do it that way,
because it drives all this from a reverse-dependen
On Mon, Mar 06, 2006 at 12:07:34AM -0700, Michael Fuhr wrote:
> On Mon, Mar 06, 2006 at 12:06:28AM -0500, Bruce Momjian wrote:
> > Is there any progress on this cleanup?
>
> I'm still planning to work on it unless somebody else wants to, but
> I was hoping for more feedback on the use of DROP TYPE
Josh Berkus writes:
> However, it's looking like registration will be around $175-$200 USD per
> developer. Sponsorships may bring that down, but I'm not counting on it.
I suppose that's about as cheap as one can expect for this kind of thing.
> Accomodations will range between $50/night to
It seems I get a segfault in backend if autovacuum is enabled. Here is
the backtrace when I connect to backend by using psql:
Program received signal SIGSEGV, Segmentation fault.
0x081fe737 in AtEOXact_GUC (isCommit=1 '\001', isSubXact=0 '\0') at guc.c:3139
3139if (stack->nest_
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>> I have another question -- why is the view showing relfilenode and
>> reltablespace? I imagine it should be showing the relation Oid instead.
> I guess that's because FSM keeps those info, not relation oid.
Right, which is co
> Peter Eisentraut wrote:
> > Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
> > > test=# select * from pg_freespacemap where blockfreebytes = 0;
> > > blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
> > > blockfreebytes
> > > -+-+---+
"Eduardo Morelli" <[EMAIL PROTECTED]> writes:
> sorry, but the address that you wrote tells that there isn´t any patch to
> apply. Is this patch Itagaki's one? How could I pick it?
Yeah, should be in the pgpatches archives [ digs... ] here you go:
http://archives.postgresql.org/pgsql-patches/2006-
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> This seems pretty widespread.
Try "universal" --- Bruce broke both contrib and PL regression tests
last night, by not updating them for the change of escape_string_warning
default.
regards, tom lane
Peter Eisentraut wrote:
> Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
> > test=# select * from pg_freespacemap where blockfreebytes = 0;
> > blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
> > blockfreebytes
> > -+-+---+
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
> test=# select * from pg_freespacemap where blockfreebytes = 0;
> blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
> blockfreebytes
> -+-+---+-++---
Hi,
I tried pg_freespacemap and found strange result:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
-+-+---+-++
Neil Conway wrote:
> I'm a bit surprised to see that there are ~300 unfixed defects: AFAIR I
> fixed all the issues the EDB guys passed on to me, with the exception of
> some false positives and a handful of minor issues in ECPG that I
> couldn't be bothered fixing (frankly I would rather not touc
Tom Lane <[EMAIL PROTECTED]> wrote
>Um, are you aware that a patch for that was already submitted?
>http://momjian.postgresql.org/cgi-bin/pgpatches
>
>I find the whole idea pretty ugly myself.
Tom,
sorry, but the address that you wrote tells that there isn´t any patch to
apply. Is this patch Ita
Tom Lane <[EMAIL PROTECTED]> wrote:
> > CREATE INDEX foo ON bar (x) WITH (fillfactor = 70, option = blah);
>
> Yeah, something along this line is what I'd like to see; probably the
> first form since that creates the least hazard of foreclosing other
> additions to the syntax later.
> Anyway the
On Mon, Mar 06, 2006 at 12:50:15PM -0400, Marc G. Fournier wrote:
> >I thought we ran the Converity analysis a year ago and cleaned up the
> >warnings, so I am surprised at our high number, but I assume they are
> >mostly noise.
>
> Got an account and will take a look at the details this evening .
On Mar 7, 2006, at 17:48 , Dave Page wrote:
The PGBuildfarm member snake had the following event on branch HEAD:
Status changed from OK to PLCheck failure
The snapshot timestamp for the build that triggered this
notification is: 2006-03-07 02:00:00
The specs of this machine are:
OS: Windows
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Peter Eisentraut
> Sent: 07 March 2006 08:55
> To: Tom Lane
> Cc: Josh Berkus; pgsql-hackers@postgresql.org; Greg Stark
> Subject: Re: [HACKERS] PostgreSQL Anniversary Summit, Call
> for Contribu
Am Dienstag, 7. März 2006 08:50 schrieb Tom Lane:
> Sometime you ought to clue us in on where the event is being held.
It's at Ryerson University in downtown Toronto. There will be a web site with
further information Real Soon Now.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
> -Original Message-
> From: PG Build Farm
> [mailto:[EMAIL PROTECTED]
> Sent: 07 March 2006 02:18
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: PGBuildfarm member snake Branch HEAD Status changed
> from OK to PLCheck failure
>
>
> The PGBuildfarm member snake had the fol
42 matches
Mail list logo
