On Fri, Sep 22, 2006 at 12:29:05PM -0300, Tom Lane wrote:
Log Message:
---
We're going to have to spell dotless i as plain i, because dotless i is
not in the character set supported by DocBook nor standard HTML. (Sorry
Volkan.) Also replace random character-set references by a
Martijn van Oosterhout wrote:
Well you could always use te HTML4 #305; which most tools should
understand. At least browsers have good support for this kind of
entity.
Please review the recent thread on pgsql-docs before reiterating all the
suggestions.
--
Peter Eisentraut
On Sat, Sep 23, 2006 at 11:54:47AM +0200, Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
Well you could always use te HTML4 #305; which most tools should
understand. At least browsers have good support for this kind of
entity.
Please review the recent thread on pgsql-docs before
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sat, Sep 23, 2006 at 11:54:47AM +0200, Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
Well you could always use te HTML4 #305; which most tools should
understand. At least browsers have good support for this kind of
On Sat, Sep 23, 2006 at 08:49:02AM -0400, Bruce Momjian wrote:
That's not how I understand it. The document encoding is only related
to how high-bit characters are interpreted, I am told by Peter, but for
some reason the toolchain just doesn't support UTF8, even though if you
use #305; in
Martijn van Oosterhout kleptog@svana.org writes:
So to me (a more docbook novice) it seems like it's the stylesheet
that's limiting you to latin1, not the docbook parser.
But the stylesheet in question is part of the basic docbook
infrastructure, so the above distinction is academic. (Or at
Martijn van Oosterhout wrote:
Oh sorry, it wasn't clear from the commit entry. It's not that
DocBook doesn't support the character or that it can't be
represented. It's just not supported in the document encoding we're
using.
No, no, and no.
The reason that it doesn't work is that the
Some off-list investigation of Dan Kavan's data loss problem,
http://archives.postgresql.org/pgsql-admin/2006-09/msg00092.php
has led to the conclusion that it seems to be a kernel bug.
The smoking gun is this strace excerpt:
lseek(10, 0, SEEK_END) = 913072128
write(10,
Andrew - Supernews [EMAIL PROTECTED] writes:
Whether the underlying device lies about the write completion is another
matter. All current SCSI disks have WCE enabled by default, which means
that they will lie about write completion if FUA was not set in the
request, which FreeBSD never sets.
On Sat, Sep 23, 2006 at 12:27:51PM -0400, Tom Lane wrote:
To my mind the real problem is that one of the principal output formats
we are interested in is HTML, and there is no dotless-i entity in any
version of the HTML standard. I trust I need not point out again the
difference between my
On 2006-09-23, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
Whether the underlying device lies about the write completion is another
matter. All current SCSI disks have WCE enabled by default, which means
that they will lie about write completion if FUA was
Hi Andrew,
I'm just investigating a problem with beta 1 running on Windows 2K and
XP, and noticed that neither Snake or Bandicoot have built -HEAD for
nearly 3 weeks. I'm investigating why and will fix the problem, but it
strikes me that what would be useful is an alarm email from the server
to
Martijn van Oosterhout kleptog@svana.org writes:
I created a simple docbook document on my computer with inodot; and
ran openjade over and in the output file it is converted to #305;.
I experimented with that, and openjade didn't complain about it, but
it renders in my browser (Safari) as
Have
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I created a simple docbook document on my computer with inodot; and
ran openjade over and in the output file it is converted to #305;.
I experimented with that, and openjade didn't complain about it, but
it renders in my
Alvaro Herrera [EMAIL PROTECTED] writes:
So maybe your Openjade is not exactly the same
Martijn was using, because what I understood was that Openjade replaced
the inodot; with #305;, which should work.
I think it's more likely that he was running with a non-DocBook
stylesheet (his openjade
Russ Brown [EMAIL PROTECTED] writes on pgsql-general:
On Thu, 2006-09-21 at 23:39 -0400, Jim Nasby wrote:
Also make sure that you've set effective_cache_size
correctly (I generally set it to total memory - 1G, assuming the
server has at least 4G in it).
Thank you: the problem was the
Thank you: the problem was the effective_cache_size (which I hadn't
changed from the default of 1000). This machine doesn't have loads of
RAM, but I knocked it up to 65536 and now the query uses the index,
without having to change the statistics.
Considering recent discussion about how 8.2 is
Tom Lane wrote:
So ReadBuffer without hesitation zeroes out the page of data we just
filled, and returns it for re-filling. There went some tuples :-(
Although this is clearly Not Our Bug, it's annoying that ReadBuffer
falls into the trap so easily instead of complaining. I'm still
On Sat, 2006-09-23 at 17:14 -0700, Joshua D. Drake wrote:
Thank you: the problem was the effective_cache_size (which I hadn't
changed from the default of 1000). This machine doesn't have loads of
RAM, but I knocked it up to 65536 and now the query uses the index,
without having to change
* Tom Lane ([EMAIL PROTECTED]) wrote:
Russ Brown [EMAIL PROTECTED] writes on pgsql-general:
Thank you: the problem was the effective_cache_size (which I hadn't
changed from the default of 1000). This machine doesn't have loads of
RAM, but I knocked it up to 65536 and now the query uses the
There's a date to postgreSQL 8.2 final?[]'s- WalterOn 9/23/06, Marc G. Fournier [EMAIL PROTECTED]
wrote:Just a short note that the first Beta is now available on
ftp.postgresql.org, and, shortly, on the mirrors ...This isn't a full announce, which will be on Monday ... but please run afew tests,
Walter Cruz wrote:
There's a date to postgreSQL 8.2 final?
[]'s
No.
---
- Walter
On 9/23/06, Marc G. Fournier [EMAIL PROTECTED] wrote:
Just a short note that the first Beta is now available on
Greetings,
Was just playing with 8.2beta1 and importing some data from MySQL and
found something rather annoying. Not *100%* sure the best way to deal
with this, if there even is a way, but...
When loading a rather large data set I started getting errors along
these lines:
Mark Kirkwood [EMAIL PROTECTED] writes:
The check looks good - are we chasing up the Linux kernel (or Suse) guys
to get the bug investigated?
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand that RH's
kernel
Walter Cruz [EMAIL PROTECTED] writes:
There's a date to postgreSQL 8.2 final?
[ ... all together now ... ] When it's ready.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Dave Page wrote:
I'm just investigating a problem with beta 1 running on Windows 2K and
XP, and noticed that neither Snake or Bandicoot have built -HEAD for
nearly 3 weeks. I'm investigating why and will fix the problem, but it
strikes me that what would be useful is an alarm email from the
On Sat, 23 Sep 2006, Walter Cruz wrote:
There's a date to postgreSQL 8.2 final?
Figure 45-60 days, but not a firm date ...
[]'s
- Walter
On 9/23/06, Marc G. Fournier [EMAIL PROTECTED] wrote:
Just a short note that the first Beta is now available on
ftp.postgresql.org, and, shortly, on
Andrew Dunstan [EMAIL PROTECTED] writes:
It could certainly be done. In general, I have generally taken the view
that owners have the responsibility for monitoring their own machines.
Sure, but providing them tools to do that seems within buildfarm's
purview.
For some types of failure, the
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
The check looks good - are we chasing up the Linux kernel (or Suse) guys
to get the bug investigated?
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand that
Gavin Heikki,
The handling of stream and hash bitmaps looks pretty complicated to me.
All the bitmap-related nodes have logic to handle both types slightly
differently. It all seems to come down to that if a subnode (or
amgetbitmap in a bitmap index scan node) returns a StreamBitmap, the
Anyhow, don't know if there's really a good solution but it'd be nice
to only get one warning, or one of a given type, or something, and to
Except that one warning would not be accurate, because the warning is
per tuple. How is postgresql going to know that the warning applies to
the
Marc G. Fournier wrote:
On Sat, 23 Sep 2006, Walter Cruz wrote:
There's a date to postgreSQL 8.2 final?
Figure 45-60 days, but not a firm date ...
See Tom Lane's post.
Joshua D. Drake
---(end of broadcast)---
TIP 1: if posting/reading
Josh,
Anyhow, don't know if there's really a good solution but
it'd be nice
to only get one warning, or one of a given type, or
something, and
to
Except that one warning would not be accurate, because the
warning is per tuple. How is postgresql going to know that
the warning
Joshua D. Drake wrote:
Tom Lane wrote:
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand that RH's
kernel hackers might not be too excited about investigating. (Alan Cox,
for one, has got other things to worry
34 matches
Mail list logo
