Hi,
From: Magnus Hagander <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] initdb failed on Windows 2000
Date: Thu, 30 Aug 2007 10:14:45 +0200
> On Wed, Aug 29, 2007 at 08:57:55AM -0400, Andrew Dunstan wrote:
> >
> >
> > Yoshiyuki Asaba wrote:
> > >
> > >>I have compiled PostgreSQL 8.2.4 with MinGW
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tatsuo Ishii wrote
>> Can someone please fix this?
> It's working for me
On Fedora Core 6's sgml toolchain, HEAD builds but un-commenting those
two index entries fails, just as Tatsuo says.
I'm no expert in this, but looking at the complained-of booki
> Tatsuo Ishii wrote:
> > > I figured out how to make my toolchain warn about missing tags like
> > > newer tool chains. My openjade needs the "-wfully-tagged" warning. I
> > > added it to sgml/Makefile.
> > >
> > > --
> > > Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
> > >
Tatsuo Ishii wrote
Can someone please fix this?
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -c
/usr/share/sgml/docbook/dsssl-stylesheets/catalog -d stylesheet.dsl -i
output-html -t sgml postgres.sgml
openjade:bookindex.sgml:2731:0:E: character data is not allowed here
op
Tatsuo Ishii wrote:
> > I figured out how to make my toolchain warn about missing tags like
> > newer tool chains. My openjade needs the "-wfully-tagged" warning. I
> > added it to sgml/Makefile.
> >
> > --
> > Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
> > EnterpriseDB
> Joshua D. Drake wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> Tom Lane wrote:
> > >>> Some committers are using DocBook installations that seem quite lax
> > >>> about closing tags :-(, so they fail to see this type of breakage.
> > >
> > >> Yep. What should
Joshua D. Drake wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> Some committers are using DocBook installations that seem quite lax
> >>> about closing tags :-(, so they fail to see this type of breakage.
> >
> >> Yep. What should I upgrade, and t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why don't we create temp tables in a separate directory, anyway? That
> would make it trivially easy to get rid of them during recovery: just
> zap all the files in there.
Hmm ... doesn't do anything to fix the problem of file leakage for
crashes when
Tom Lane wrote:
Whether that's common enough to be worth special optimization, I'm
not sure. Your point that the transaction may have been heavyweight
enough that it'd hardly matter is still on-target, you just got there
by the wrong reasoning ;-)
My point is that there is hardly any effort ne
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > -1 to second: If there are any temporary deleted files then it is
> > because we've done a large sort, hash join etc, so avoiding the sync
> > makes no difference to the overall response time.
>
> I think you're confused, actually: thi
Simon Riggs <[EMAIL PROTECTED]> writes:
> -1 to second: If there are any temporary deleted files then it is
> because we've done a large sort, hash join etc, so avoiding the sync
> makes no difference to the overall response time.
I think you're confused, actually: this is not about temporary sor
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> ... So at least for the pl/pgsql case, it seems easy enough to temporarily
> change GUCs already. For other PLs, things might be different though -
> I wouldn't know, I have never really used them...
It's definitely possible, but it's inconvenient a
Simon Riggs wrote:
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there was a way to make that a DBA-controllable
setti
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Perhaps it would be possible to do this
>
> ALTER FUNCTION fubar SET synchronous_commit = off;
>
> So that any invocation of the function would automatically set all of
> the appropriate parameters prior to execution.
The problem here is that fun
Why does the windows installer require a password for the superuser
account, since it's perfectly legitimate not to have a password on
that account? I could see perhaps producing a warning, but making
this a hard requirement seems like overkill.
--
Decibel!, aka Jim Nasby
Tom Lane wrote:
What if we just defined the binary format as being identical to the text
format, ie, the enum label? A bit silly but at least it would eliminate
the gotcha that binary I/O fails.
So we should pretty much mimic text_send/text_recv? If so I can probably
get that d
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there was a way to make that a DBA-controllable
setting, much the same as
On Thu, 2007-08-30 at 14:14 -0400, Tom Lane wrote:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > So should we not force synchronous commit if all to-be-deleted files
> > are temporary? Or is that pushing our luck too much, because it opens
> > the window of possible file leakage considerably
On Thu, 2007-08-30 at 00:33 -0400, Tom Lane wrote:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > And I'm quite tempted to not flush the XLOG at all during ABORT, and to
> > only force synchronous commits if one of the to-be-deleted files is
> > non-temporary.
>
> +1 on the first, but -1 on
What if we just defined the binary format as being identical to the text
format, ie, the enum label? A bit silly but at least it would eliminate
the gotcha that binary I/O fails.
Seems like it would make a lot more sense to the client application that
way too...
-- Korry
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Merlin Moncure wrote:
>> I noticed that enums are not available to be queried as binary through
>> the protocol.
> The trouble is that an enum doesn't have an immutable internal binary value.
> I guess we could say that the binary value is the integer
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I noticed that enums are not available to be queried as binary through
> the protocol.
What do you think the binary representation ought to be? Copying OIDs
seems pretty useless.
regards, tom lane
---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm not sure I follow. Are you suggesting adding a new function,
> similar to pg_class_ownercheck, which additionally checks for temp-ness?
No, I was just suggesting adding the check for temp-ness in cluster()
and cluster_rel() where we do pg_class_own
Merlin Moncure wrote:
I noticed that enums are not available to be queried as binary through
the protocol. Is this a known issue? Too late to fix for 8.3? This
is kind of a pain, because it forces any query that returns an enum to
return the entire result as text. afaik, enums are the only
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> So should we not force synchronous commit if all to-be-deleted files
> are temporary? Or is that pushing our luck too much, because it opens
> the window of possible file leakage considerably wider?
I think this area is something to be left for late
Ron Mayer <[EMAIL PROTECTED]> writes:
> Could similar logic argue that we'd want special types for regular
> expressions too? That seems quite parallel to the tsquery type to me.
Yeah, it certainly seems like something we might want to consider in
future --- we could get rid of that klugy cache fo
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
+1 on the first, but -1 on the second, because we'd have to track
whether deleted files are temp or not ... it's very unclear that it'd
be worth the trouble.
I'm confused. smgrcreate already tracks if it created a
Gregory Stark wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
It seems doable, but it's not pretty. One possible scheme would be to
emit a record *after* chosing a name but *before* creating the file,
No, because the way you know the name is good is a successful
open(O_CREAT).
The idea
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Why does text search need a tsquery data type? I realize it needs
>> tsvector so it can create indexes and updated trigger columns, but it
>> seems tsquery could instead just be a simple text string.
>
> By that logic, we don't need a
I noticed that enums are not available to be queried as binary through
the protocol. Is this a known issue? Too late to fix for 8.3? This
is kind of a pain, because it forces any query that returns an enum to
return the entire result as text. afaik, enums are the only POD type
to behave this wa
On Thu, 30 Aug 2007, Jean-Paul Argudo wrote:
Hi all,
I cant find in the docs about tsearch2 (nor the Oleg&Teodor's wiki) when
to use @@@ instead of @@.
it's written here
http://www.sai.msu.su/~megera/postgres/fts/doc/indexes-fts.html
@@ works in GIST, even with 'lexeme:a' (:a, :bc, etc..
On Thu, 30 Aug 2007, Bruce Momjian wrote:
Gregory Stark wrote:
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can store a tsquery value in a colum
Hi Magnus,
Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
fine, but the buildsystem needed a lot more work.
Great - figured that might be the case.
3. If you have a contrib module that is no
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yeah, an extra fetch of the pg_class row doesn't seem all that nice.
> >> I think you'd want to check it in approximately the same two places
> >> where pg_class_ownercheck() is applied (one for the 1-xact and one
[EMAIL PROTECTED] wrote:
Ok, do you need it on unixware?
do you need it more than once a week?
FYI, centaurc is running make check for 3 hours now and has'nt finished!
The platform probably doesn't matter so much, I suspect. Once a week on
a separately registered animal should be fine. W
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > How would that happen if there wasn't a tsquery type?
>
> I don't think Bruce is suggesting that the search operand can really
> be plain text (or if he is, he's nuts). The question here is whether
Yes, that is what I was suggesting
Gregory Stark <[EMAIL PROTECTED]> writes:
> How would that happen if there wasn't a tsquery type?
I don't think Bruce is suggesting that the search operand can really
be plain text (or if he is, he's nuts). The question here is whether
there's really a need for a distinction between tsvector and
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >>
> >> > There is no question things would be clearer with only one text search
> >> > data type. The only value I can see to having a tsquery data ty
Hi Tom
On Thu, 30 Aug 2007, Tom Lane wrote:
> Date: Thu, 30 Aug 2007 10:04:34 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Andrew Dunstan <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], PostgreSQL-development
> Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in
> DefineIndex():
Hi all,
I cant find in the docs about tsearch2 (nor the Oleg&Teodor's wiki) when
to use @@@ instead of @@.
@@ works in GIST, even with 'lexeme:a' (:a, :bc, etc.. every combination
of a,b,c & d part)
@@ doesnt with GIN in the same queries it, PostgreSQL says:
ERREUR: With class of lexeme restr
[EMAIL PROTECTED] writes:
> Ok, do you need it on unixware?
> do you need it more than once a week?
No, and no.
> FYI, centaurc is running make check for 3 hours now and has'nt finished!
You're finding out why I suggested a really low duty cycle ;-)
regards, tom lane
--
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>>
>> > There is no question things would be clearer with only one text search
>> > data type. The only value I can see to having a tsquery data type is
>> > that you can store a tsq
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> +1 on the first, but -1 on the second, because we'd have to track
>> whether deleted files are temp or not ... it's very unclear that it'd
>> be worth the trouble.
> I'm confused. smgrcreate already tracks if it created a file for
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > There is no question things would be clearer with only one text search
> > data type. The only value I can see to having a tsquery data type is
> > that you can store a tsquery value in a column, but why would that be
> > mu
On 8/30/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> This isn't really the place to ask about running buildfarm - it has its
> own mailing list to which you should have been subscribed.
I am sorry.
Do you mean this?
http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-members
I could not f
Peter Eisentraut wrote:
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put the docs under the noses of people who have
*not* installed or even heard of the modules. So "it's not in the docs
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> I've just configure centaur (CentOS 5) like this.
>> Do you need it for every version (8.1, 8.2) or just HEAD
>> Do you need it just once a week or every run?
>> I can also configure wharthog (unixware) like this if you need..
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
> I thought a large part of the desire was to improve the visibility of
> the contrib docs, ie, put the docs under the noses of people who have
> *not* installed or even heard of the modules. So "it's not in the docs
> unless you installed it"
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
>>> It seems doable, but it's not pretty. One possible scheme would be to
>>> emit a record *after* chosing a name but *before* creating the file,
>>
>> No, because the way you know the name is good is a successful
>> open(O_CREAT).
>
> The idea was t
Am Donnerstag, 30. August 2007 15:13 schrieb Andrew Dunstan:
> What? No it doesn't. You have missed the key word in the sentence above:
> "standard". The idea is that the docs will describe the *standard*
> modules, i.e. those that ship with the PostgreSQL core distribution
> (because they are curr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If you want to design a pluggable documentation system then go for it,
> but it's not required by what I understand is the consensus plan for
> contrib.
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put th
[EMAIL PROTECTED] wrote:
Does someone have a box with lots of grunt that can spare some cycles
for a few hours once a week or so?
I've just configure centaur (CentOS 5) like this.
Do you need it for every version (8.1, 8.2) or just HEAD
Do you need it just once a week or every run?
I can
Peter Eisentraut wrote:
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized.
Gabor Szabo wrote:
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or withou
Gabor Szabo wrote:
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or with
Hi all,
On Tue, 28 Aug 2007, Andrew Dunstan wrote:
> Date: Tue, 28 Aug 2007 12:34:46 -0400
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> Newsgroups: pgsql.hackers
> Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was
> continuing to access the
>
>
>
> Tom Lane wrote:
> > An
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or without debug, with or with
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
And I'm quite tempted to not flush the XLOG at all during ABORT, and to
only force synchronous commits if one of the to-be-deleted files is
non-temporary.
+1 on the first, but -1 on the second, because we'd have to track
whether de
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
> Also, let's recall what has previously been discussed for contrib,
> namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized. That is, if I deinstall some module,
Am Mittwoch, 29. August 2007 20:18 schrieb Neil Conway:
> I wonder if it would be possible to keep the master version of the
> contrib docs as SGML, and generate plaintext READMEs from it during the
> documentation build.
Using asciidoc you could do it the other way around.
--
Peter Eisentraut
h
Andrew Dunstan a écrit :
>
>
> Albert Cervera i Areny wrote:
>>> I'm very strongly in favor of having this documentation. However, I
>>> think
>>> it might make sense to put "Contrib Modules" as a section under either
>>> "Reference" or "Appendices". Also, I don't think it's necessary to make
>
hi tom ...
the idea behind this is to disable the stats on a certain column
entirely.
this would give me more control about the plan. in this special case
data is changing so frequently that the default values are ways
better than trying to keep the "real" stats up to date.
in case of defau
On Wed, Aug 29, 2007 at 08:57:55AM -0400, Andrew Dunstan wrote:
>
>
> Yoshiyuki Asaba wrote:
> >
> >>I have compiled PostgreSQL 8.2.4 with MinGW on Windows 2000. Then I
> >>have executed initdb as Administrator. However initdb failed with the
> >>following message.
> >>
> >>
> >>The program
On Wed, Aug 29, 2007 at 08:53:55PM -0600, Charlie Savage wrote:
> In addition to the encoding issues I have with the 8.2.4 MSVC++ build
> (see previous email), there are some other issues that I've run into:
>
> 1. The custom build step that generates DEF files for DLLS using a perl
> script do
On Wed, Aug 29, 2007 at 09:49:03PM -0600, Charlie Savage wrote:
> Hmm. Its postgresql 8.2.4 + tsearch2 + tree + postgis. postgis in
> turn loads proj4 and geos. I grepped through those 3 libraries source
> code and did not find any calls to setlocale. So I don't think so.
>
> So now I'm con
65 matches
Mail list logo
