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
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 to libpq to allow
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 to libpq to allow
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 won't know
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)---
TIP 3:
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 JustAUser
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 not
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 to
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 need an
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 harder to
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|
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
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
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
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
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
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
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 modified
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 is the first I have
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
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 supply
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
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,
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 for
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), I
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,
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]etspecific() on
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 choose
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 getting in
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 context of
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 by
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-memory
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
[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 trademark
[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
at close(). We
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 select *
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 being
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
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 English
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,
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
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 because I'm running
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
43 matches
Mail list logo
