set digest
* The Hermit Hacker [EMAIL PROTECTED] [001109 20:19] wrote:
On Thu, 9 Nov 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
Done. Want to generate some new 7.0.3 release-candidate tarballs?
Hi!
I'll be in Las Vegas (Comdex) till next week
Wednesday.
I wasn't able to implement redo for sequences but
was going to turn WAL on by default anyway.
Unfortunately, I've got core in regress:opr_sanity
test (in FileSeek code), so WAL still is not
default.
See you!
Vadim
At 12:07 10/11/00 -0500, Tom Lane wrote:
Something's got to be done about this --- not being able to load
7.0 dump files will not do.
I assume modifying pg_dump for 7.0.x is not an option, since we really need
to support loading databases from historical dump files. If so, then would
there be
FINALLY, the SCO UDK Feature Supplement is released. I know
a couple of other people were waiting for it, so I figured I'd tell
people it's out.
Peter,
The released version is now on lerami.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812
Philip Warner [EMAIL PROTECTED] writes:
At 12:07 10/11/00 -0500, Tom Lane wrote:
Something's got to be done about this --- not being able to load
7.0 dump files will not do.
I assume modifying pg_dump for 7.0.x is not an option,
Not really ...
would
there be any value in modifying the
Hi
I hope this is the right list to write to.
A danish company just got a patent which we at SSLUG www.sslug.dk do not
think is a new invention.
I want to get in contact with somebody who can confirm that this patent is
not new and has been in PostgreSQL before the patent was taken.
If we can
At 06:35 PM 11/11/00 +0200, Hannu Krosing wrote:
I took only a brief look at them, so i may be in a state of
misunderstanding :)
As I understand it, the patent is about generating/composing queries
_before_
submitting them to backend, not about query processing in the backend.
Yes, it's a
Bruce Momjian [EMAIL PROTECTED] writes:
Not really, I thought an ack on a commit would mean that the data
is actually in stable storage, breaking that would be pretty bad
no?
The default is to sync on commit, but we need to give people options of
several seconds delay for performance
I'm trying to compile postgresql on Windows
2000. I've followed the directions accordingly.
When I run the "configure" script, and I get the
following error message:
configure: error installation or configuration
problem: C compiler cannot create executables.
If anyone has any clues,
* Gary MacDougall [EMAIL PROTECTED] [00 11:28] wrote:
I'm trying to compile postgresql on Windows 2000. I've followed the directions
accordingly.
When I run the "configure" script, and I get the following error message:
configure: error installation or configuration problem: C
At 10:55 11/11/00 -0500, Tom Lane wrote:
Just outputting a warning is possible, but it still leaves you with a
broken database after you reload your 7.0 dump file :-(. (And there
isn't any supported way to fix it, short of reloading all your function
definitions...) I thought about the
Philip Warner [EMAIL PROTECTED] writes:
Is it the PL manager stuff that requires the new interface for all
languages, or is it up to the PL implementor to choose the language for
their handler?
The current fmgr implementation requires PL handlers to be newC or
newInternal. That could be
On Sat, Nov 11, 2000 at 08:30:48PM -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
...
It does avoid "language 'evenNewerC'" in the furture.
How so? It appears to me it would just move the 'evenNewerFoo'
dirtiness to a different keyword, which would still be essential
At 21:15 11/11/00 -0500, Bruce Momjian wrote:
This is interesting. It allows us to control the default behavour of
"C". I would vote to default to 7.0-style when no version is used for
7.1, then default to 7.1 style in 7.2 and later. We don't need
backward C function compatibility for more
At 20:30 11/11/00 -0500, Tom Lane wrote:
The current fmgr implementation requires PL handlers to be newC or
newInternal. That could be relaxed, but I don't see any reason to do
so, since an old-style handler would be incapable of handling null
arguments/results or supporting triggers.
OK, then
Dear all,
Sorry if I post in the wrong list, but I've been tortured by the
problem for quite sometime.
I've been tring for several combinations, say
BACKEND FRONTEND
MULE_INTERNAL EUC_TW
BIG5
* Tatsuo Ishii [EMAIL PROTECTED] [001110 18:42] wrote:
Yes, though we can change this. We also can implement now
feature that Bruce wanted so long and so much -:) -
fsync log not on each commit but each ~ 5sec, if
losing some recent commits is acceptable.
Sounds great.
Bruce Momjian [EMAIL PROTECTED] writes:
I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack. You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.
It does not give up
Bruce Momjian [EMAIL PROTECTED] writes:
I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack. You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.
It does not
Bruce Momjian [EMAIL PROTECTED] writes:
I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack. You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.
It does not
* Bruce Momjian [EMAIL PROTECTED] [00 00:16] wrote:
* Tatsuo Ishii [EMAIL PROTECTED] [001110 18:42] wrote:
Yes, though we can change this. We also can implement now
feature that Bruce wanted so long and so much -:) -
fsync log not on each commit but each ~ 5sec, if
Bruce Momjian [EMAIL PROTECTED] writes:
Not really, I thought an ack on a commit would mean that the data
is actually in stable storage, breaking that would be pretty bad
no?
The default is to sync on commit, but we need to give people options of
several seconds delay for performance
23 matches
Mail list logo
