Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It's surprising that nobody noticed the bug until now. It seems it has
> been there since 7.3 days. I would like to make a back patch for
> 7.3-stable if nobody objects.
No objection here. Note that I applied a minimal patch to the 7.4
branch, but a more
"Dan Langille" <[EMAIL PROTECTED]> writes:
> I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the
> schemas which existed in the original databases were not created in
> the new database.
> New issue? Known bug?
New one on me. Look at the log output from when the dump was bein
Dave Cramer wrote:
> Interesting it works now, and the good news is it is *WAY* faster, this
> might be able to speed up marc's doc search by orders of magnitude
>
> this is searching 100536 rows
>
> select * from url where fn_strrev(url) like fn_strrev('%beta12.html');
> 1.57ms
>
>
> explain
"[EMAIL PROTECTED] (Greg Stark)" stated in
comp.databases.postgresql.hackers:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
>> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> > FreeBSD 4.7/4.9 and the UFS filesystem
>>
>> Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC
"[EMAIL PROTECTED] (Jean-Michel POURE)" stated in
comp.databases.postgresql.hackers:
> Le Mardi 25 Novembre 2003 07:32, Randolf Richardson a écrit :
>> I'm curious, has anyone consulted with a lawyer on this?
>
> Yes, the lawyer concluded that the number "2003" had been both
> registered as a tr
Greg Stark wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
That means
open();
write();
sync();
could succeed, but the data is not stored on disk, correct?
That would be true on any filesystem. Unless you throw an fsync() call in.
The checkpoint code uses sync() right now. Ac
Manfred Spraul <[EMAIL PROTECTED]> writes:
> That means
> open();
> write();
> sync();
>
> could succeed, but the data is not stored on disk, correct?
That would be true on any filesystem. Unless you throw an fsync() call in.
With sync replaced by fsync then any filesystem ought to
I think users would prefer %ProgramFiles%\PostgreSQL - that's what Mozilla
and some other projects do, although still other projects do
%ProgramFiles%\GNU\PostgreSQL.
I'd vote for %ProgramFiles%\PostgreSQL.
- Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Satoshi,
The postgres, knoppix CD that I created last summer was compiled to work
with plpgsql, plperl(u), plpythonu, pltcl(u). It has ODBC and JDBC
drivers compiled into it too: I had some problems with Java initially
but overcame it after I tinkered with the ant startup script.
I recompiled
I've read past thread and I know about new book from No Starch Press.
Now, I need some comments about applications which should be included in
such LiveCD. Which application is appealing for PostgreSQL promotions
or demonstrations?
Or which kind of applications (admin tools, middleware, language
Oops. Sorry I missed that thread.
(Because I was working on my master thesis...)
I'll read the past msgs before coming back this topic.
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> On Sat, 24 Jan 2004, Satoshi Nagayasu wrote:
>
> > OK.
> > I've started working on the PostgreSQL-KNOPPIX Englis
OK.
I've started working on the PostgreSQL-KNOPPIX English version.
Could anyone tell me postgresql related events schedule?
Are OSCON(June, Portland) and LinuxWorld(August, San Francisco) nearest?
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Jean-Michel,
>
> > Morphix is an auto-bootable Debian GNU
> "Korea PostgreSQL Users' Group" <[EMAIL PROTECTED]> writes:
> >> Hm. I don't think it can actually fail, because the wchar strings are
> >> zero-terminated.
>
> > [ yes it can ]
>
> You're right. I was confused at first because I couldn't reproduce the
> problem, but then I realized it's beca
Hi folks,
I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the
schemas which existed in the original databases were not created in
the new database.
The CREATE SCHEMA commands are there...
\connect "freebsddiary.org"
--
-- PostgreSQL database dump
--
SET SESSION AUTHORIZATION
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> ORing and ANDing of such bitmaps still works, with the understanding
>> that it's lossy and you have to double check each retrieved tuple.
> That would make it really hard to ever clear the bits.
We're speaking of in
Tom Lane <[EMAIL PROTECTED]> writes:
> That seems a bit too lossy for me, but I really like your later idea
> about folding. Generalizing that a little, we can choose any fold point
> we like. We could allocate, say, one 32-bit word per page and set the
> (i mod 32) bit when item i is fingered
Tom Lane kirjutas L, 31.01.2004 kell 01:02:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Another idea would be using bitmaps where we have just one bit per
> > database page and do a seq scan but just over marked pages.
>
> That seems a bit too lossy for me,
I originally thought of it in conte
On 14 Jan, Jan Wieck wrote:
> Neil Conway wrote:
>
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> This is a bug Jan introduced recently --- he forgot to modify the
>>> shared memory setup code to allow space for the new data structures
>>> used by ARC. Jan, would you mind fixing that soon? It's get
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Another idea would be using bitmaps where we have just one bit per
> database page and do a seq scan but just over marked pages.
That seems a bit too lossy for me, but I really like your later idea
about folding. Generalizing that a little, we can choos
Scott Lamb wrote:
> Scott Lamb wrote:
> > You could just do a pthread_sigmask() before and after the
> > pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
> > thread in that time. I think it's pretty safe to assume that as long as
> > you're not doing a pthread_[gs]etspecifi
Scott Lamb wrote:
> You could just do a pthread_sigmask() before and after the
> pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
> thread in that time. I think it's pretty safe to assume that as long as
> you're not doing a pthread_[gs]etspecific() on that same pthread_key
Peter Eisentraut kirjutas N, 29.01.2004 kell 19:31:
> Andrew Dunstan wrote:
> > Peter: this looks very nice. What are your intentions with this code?
>
> Once we figure out how to handle the on-the-wire character set recoding
> when faced with XML documents (see separate thread a few weeks ago),
Tom Lane kirjutas R, 30.01.2004 kell 16:48:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Also, what does an in-memory bitmapped index look like?
>
> One idea that might work: a binary search tree in which each node
> represents a single page of the table, and contains a bit array with
> one bit
Scott Lamb wrote:
You could just do a pthread_sigmask() before and after the
pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
thread in that time. I think it's pretty safe to assume that as long as
you're not doing a pthread_[gs]etspecific() on that same pthread_key_t,
it'
Bruce Momjian wrote:
Scott Lamb wrote:
Speaking of async signal-safe functions, pthread_getspecific() isn't
specified to be (and thus PQinSend() and thus
sigpipe_handler_ignore_send()). It's probably okay, but libpq is
technically using undefined behavior according to SUSv3.
Yikes. I never s
Tom Lane wrote:
In config/c-compiler.m4 I read
if test "$ac_env_CFLAGS_set" != set; then
CFLAGS="$CFLAGS $pgac_cv_prog_cc_no_strict_aliasing"
fi
This means that a configure operation as innocuous-looking as
CFLAGS="-O3" ./configure
will break the build on gcc >= 3.3 because it will fail to
In config/c-compiler.m4 I read
if test "$ac_env_CFLAGS_set" != set; then
CFLAGS="$CFLAGS $pgac_cv_prog_cc_no_strict_aliasing"
fi
This means that a configure operation as innocuous-looking as
CFLAGS="-O3" ./configure
will break the build on gcc >= 3.3 because it will fail to supply
-fn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Any ideas on how to record the
> modified files without generating tones of output or locking contention?
What I've suggested before is that the bgwriter process can keep track
of all files that it's written to since the last checkpoint, and fsync
them d
On Fri, Jan 30, 2004 at 11:10:49AM -0600, Scott Lamb wrote:
> On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote:
> >Manfred Spraul wrote:
> >>Bruce Momjian wrote:
> >>
> >>>Woh, as far as I know, any application should run fine with
> >>>-lpthread,
> >>>threaded or not. What OS are you on? This i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The trick is to somehow record all files modified since the last
> > checkpoint, and open/fsync/close each one. My idea is to stat() each
> > file in each directory and compare the modify time to determine if the
> > file has been mo
Scott Lamb wrote:
> Speaking of async signal-safe functions, pthread_getspecific() isn't
> specified to be (and thus PQinSend() and thus
> sigpipe_handler_ignore_send()). It's probably okay, but libpq is
> technically using undefined behavior according to SUSv3.
Yikes. I never suspected pthrea
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The trick is to somehow record all files modified since the last
> checkpoint, and open/fsync/close each one. My idea is to stat() each
> file in each directory and compare the modify time to determine if the
> file has been modified since the last chec
On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote:
Manfred Spraul wrote:
Bruce Momjian wrote:
Woh, as far as I know, any application should run fine with
-lpthread,
threaded or not. What OS are you on? This is the first I have
heard of
this problem.
Perhaps we should try to figure out how oth
As some know, win32 doesn't have sync, and some are concerned that sync
isn't reliable enough during checkpoint anyway.
The trick is to somehow record all files modified since the last
checkpoint, and open/fsync/close each one. My idea is to stat() each
file in each directory and compare the mod
Having googled around I found this about Docbook to PDF conversion:
http://www.linuxfocus.org/English/May2000/article152.shtml
no sign of fop.
I hope it helps and that I am not mistaken when I claim the format is
docbook.
Cheers
Zoltan
- Original Message -
From: "Karel Zak" <[EMAIL PR
On Jan 30, 2004, at 6:31 AM, Bruce Momjian wrote:
I like the idea of building in-memory bitmapped indexes.
Me too (FWIW)! This thread is really interesting as the whole idea
would help to solve the biggest issue with my (currently stalled)
project to integrate Xapian as a full-text search engin
I have applied the following patch for the following reasons:
Remove sleep() and use single PG_SLEEP call for Win32 signal handling
and consistency.
Change PG_USLEEP to use SleepEx() for signal interuptability.
--
Bruce Momjian|
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Is there a reason sort the pages before scanning them? The result won't
>> come out sorted one way or the other.
> I think the goal would be to hit the heap in sequential order as much as
> possible.
Exactly. Also, it'll be ha
Alvaro Herrera wrote:
> On Fri, Jan 30, 2004 at 09:48:19AM -0500, Tom Lane wrote:
>
> > A variant is to make the per-page bit arrays be entries in a hash table
> > with page number as hash key. This would reduce insertion to a nearly
> > constant-time operation, but the drawback is that you'd nee
On Fri, Jan 30, 2004 at 09:48:19AM -0500, Tom Lane wrote:
> A variant is to make the per-page bit arrays be entries in a hash table
> with page number as hash key. This would reduce insertion to a nearly
> constant-time operation, but the drawback is that you'd need an explicit
> sort at the end
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > In any case, this discussion is predicated on the assumption that the
> > operations involving the bitmap are a significant fraction of the total
> > time, which I think is quite uncertain. Until we build it and profile
> > it, we
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Also, what does an in-memory bitmapped index look like?
>
> One idea that might work: a binary search tree in which each node
> represents a single page of the table, and contains a bit array with
> one bit for each possible item numb
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, what does an in-memory bitmapped index look like?
One idea that might work: a binary search tree in which each node
represents a single page of the table, and contains a bit array with
one bit for each possible item number on the page. You could n
Richard Huxton wrote:
> On Wednesday 28 January 2004 00:38, Simon Riggs wrote:
> > POSTGRESQL: Summary of Changes since last release (7.4.1)
>
> > All corrections and changes welcome...if this is well received, then I
> > will monitor pgsql-commiters to keep track of things.
>
> Speaking as Just
On Thu, Jan 29, 2004 at 03:27:06PM -0400, Marc G. Fournier wrote:
>
> I would say that "two such transactions concurrently" heavily implies
> such, no? :)
Like I said, the text tries to explain it--but it remains murky!
---(end of broadcast)---
TI
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > In any case, this discussion is predicated on the assumption that the
> > operations involving the bitmap are a significant fraction of the total
> > time, which I think is quite uncertain. Until we build it and profile
> > it, we
Jan Wieck wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> Are those exposed through the libpq interface?
> >>>
> >>> No, because libpq doesn't really have any concept of prepared statements.
> >>> It would probably make sense to add some more API
Jan Wieck wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> Are those exposed through the libpq interface?
> >>>
> >>> No, because libpq doesn't really have any concept of prepared statements.
> >>> It would probably make sense to add some more API
On Thu, Jan 29, 2004 at 07:02:12PM +0100, Peter Eisentraut wrote:
> > Peter E. works on XML docbook version of docs. I don't know if he
> > wants to move directly to XML or uses on the fly conversion to XML
> > by osx (sgml2xml). This conversion you try use by "make testxml"
> > stuff in the
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >Woh, as far as I know, any application should run fine with -lpthread,
> >threaded or not. What OS are you on? This is the first I have heard of
> >this problem.
> >
> >
> Perhaps we should try to figure out how other packages handle
> multith
50 matches
Mail list logo
