Sorry, but I just found out that many of my mails bounced because I was using
my secondary email address =8-0
-- Forwarded Message --
Subject: Re: [HACKERS] CRC, hash Co.
Date: Mon, 11 Dec 2000 07:13:31 +1100
From: Horst Herb [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
On
On Mon, 11 Dec 2000, Thomas Lockhart wrote:
All in all it's a synchronization and communication problem, but it's a
real problem, as history shows.
There is nothing stopping Marc from running the docs generation
explicitly just before release. The group permissions in my docs build
area
Perhaps they *should* truncate if the specified length is less than
the original string length. Does Oracle do that?
Yes, it truncates, same as Informix.
I went to fix this and then realized I still don't have an adequate spec
of how Oracle defines these functions. It would seem
PG should include support for SHA1 anyway. MD5 is not being used in
new stuff anymore, I think. I actually have an SHA1 implementation
that links into PG if anyone is interested (especially if it could get
included in a future release).
e
Interesting. I was under the impression that virtually no RISC CPU had
a rotate instruction. Do any others?
(fyi; doesn't really contribute to the thread :/
Most or all do. There are no "pure RISC" chips in production; all have
had some optimized complex operations added for performance and
I suggest to remove the following elog from line 943 of xlog.c.
It does not give real useful info and is repeated for each checkpoint,
thus filling the log of an otherwise idle server.
elog(LOG, "MoveOfflineLogs: skip %s", xlde-d_name);
DEBUG: MoveOfflineLogs: skip
Thomas Lockhart writes:
There is nothing stopping Marc from running the docs generation
explicitly just before release. The group permissions in my docs build
area are set to allow this.
That's kind of what I meant, only instead of "Marc running the docs
generation explicitly just before
If we move tuples in already committed state, a page with new
tuple position goes to disk and backend crashes before page with
old tuple position updated then we'll have two version of tuple
after restart (new tuple with HEAP_MOVED_IN is valid and there is
no HEAP_MOVED_OFF in old tuple
Hiroshi Inoue [EMAIL PROTECTED] writes:
When VACUUM for a table starts, the transaction is not
committed yet of cource. After *commit* VACUUM has handled
heap/index tuples very carefully to be crash-safe before
7.1. Currently another vacuum could be invoked in the
already committed
Randy Jonasz wrote:
I appreciate your comments and would like to respond to your concerns.
The API I sketched in my earlier e-mail is borrowed heavily from
Rogue Wave's dbtools.h++ library. I think it can be a very clean and
elegant way of accessing a database.
Yes, this looks neat. At
I suggest to remove the following elog from line 943 of xlog.c.
It does not give real useful info and is repeated for each checkpoint,
thus filling the log of an otherwise idle server.
elog(LOG, "MoveOfflineLogs: skip %s",
xlde-d_name);
DEBUG: MoveOfflineLogs:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If we move tuples in already committed state, a page with new
tuple position goes to disk and backend crashes before page with
old tuple position updated then we'll have two version of tuple
after restart (new tuple with HEAP_MOVED_IN is valid and
It is clear in this algorithm that there is no order dependency: the
conditions for keeping or discarding a candidate are fixed before we
start the second pass, and do not vary depending on which other
candidates were discarded before it.
I won't argue strongly for either solution, but have
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Also, what happens if the specified length is less than zero? Error,
or is it treated as zero?
Returns NULL in both if length = 0. I would see the 0 case as proper,
but the == 0 case sure looks weird to me.
Since Oracle fails to distinguish
I know you guys are pretty busy with the upcoming release but I
was hoping for more interest in this work.
With this (which needs forward porting) we're able to cut
vacuum time down from ~10minutes to under 30 seconds.
The code is a nop unless you compile with special options(MMNB)
specify the
Sounds good to me. [Of course, I never met a patch I didn't like, or so
they say.]
I know you guys are pretty busy with the upcoming release but I
was hoping for more interest in this work.
With this (which needs forward porting) we're able to cut
vacuum time down from ~10minutes to
Alfred Perlstein [EMAIL PROTECTED] writes:
Basically Vadim left it up to me to campaign for acceptance of this
work and he said he wouldn't have a problem bringing it in as long
as it was ok with the rest of the development team.
So can we get a go-ahead on this? :)
If Vadim isn't
Ok, after taking in feedback from several RPM users over the last six
months or so, I have come up with a list of possible changes to the
RPMset for PostgreSQL 7.1. I'd like comments on these changes. If
there are now comments, I'll go ahead and make the changes.
1.) Addition of a
On Mon, Dec 11, 2000 at 02:09:35PM -0500, Lamar Owen wrote:
I am cross-posting (via blind copy) this to -hackers since the community
in -hackers is well-versed in system issues such as these.
Ah, _that's_ why my procmail filter missed this one! Couldn't think of
why you'd email me about RPMs
Alfred Perlstein [EMAIL PROTECTED] writes:
Basically Vadim left it up to me to campaign for acceptance of this
work and he said he wouldn't have a problem bringing it in as long
as it was ok with the rest of the development team.
So can we get a go-ahead on this? :)
If Vadim isn't
On Mon, 11 Dec 2000, Tom Lane wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
Basically Vadim left it up to me to campaign for acceptance of this
work and he said he wouldn't have a problem bringing it in as long
as it was ok with the rest of the development team.
So can we get a
"Mikheev, Vadim" wrote:
If we move tuples in already committed state, a page with new
tuple position goes to disk and backend crashes before page with
old tuple position updated then we'll have two version of tuple
after restart (new tuple with HEAP_MOVED_IN is valid and there is
Ops, sorry - this case is not relevant to 7.1: WAL guarantees that
both pages will be updated on restart. Seems we are safe now.
First,already committed state isn't a normal state at least
without WAL. We must have access to db as less as possible in the
state without WAL.
AFAIK there
* The Hermit Hacker [EMAIL PROTECTED] [001211 14:27] wrote:
On Mon, 11 Dec 2000, Bruce Momjian wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
Basically Vadim left it up to me to campaign for acceptance of this
work and he said he wouldn't have a problem bringing it in as long
If Vadim isn't sufficiently confident of it to commit it
on his own authority, I'm inclined to leave it out of 7.1.
My concern is mostly schedule. We are well into beta cycle
now and this seems like way too critical (not to say high-risk)
a feature to be adding after start of
On Mon, 11 Dec 2000, Mikheev, Vadim wrote:
If Vadim isn't sufficiently confident of it to commit it
on his own authority, I'm inclined to leave it out of 7.1.
My concern is mostly schedule. We are well into beta cycle
now and this seems like way too critical (not to say
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and incorporate
changes into 7.2.
Comments?
IMHO, we are in beta now and this doesn't fix a bug ... if we could make
this available as a patch in /contrib until
Go for it Vadim ... it is only a couple of days in, and I know there are
several places I could personally use it ...
On Mon, 11 Dec 2000, Bruce Momjian wrote:
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and
Hiroshi Inoue [EMAIL PROTECTED] writes:
VACUUM of a toast table crashed immediately after the movement
of a tuple(and before inserting corresponding index tuples).
Unfortunately the movement of a tuple is directly committed in
already committed state but corresponding index tuples aren't
Thanks. The other good item is that is already being used in production
use, so it seems it is pretty well tested.
Go for it Vadim ... it is only a couple of days in, and I know there are
several places I could personally use it ...
On Mon, 11 Dec 2000, Bruce Momjian wrote:
If
I thought the hackers team would be interested in knowing that SourceForge, as
of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
Source projects are depending on your stuff, so I hope it's going to be stable
for us. ;-)
Throughout the codebase we're making good use of
On Mon, 11 Dec 2000, Tom Lane wrote:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and incorporate
changes into 7.2.
I'd vote for the second choice. I do not think we
One thing I would like to see, which we have built into our own,
primitive, C++ interface, is support for binary data retrieval. For some
applications the savings are huge.
I haven't thought very hard about how to do this: we do it by having a
perl script generate structures from the table
A few points in favor of including this ... first, when Vadim does do the
storage manager rewrite for v7.2, the patch is essentially useless ... and
second, its currently being used in production on a server that is/will
tax it heavily, so it isn't untested ...
I'd almost extend that to
Bruce Momjian wrote:
This is great news. As far as the optimizer, any chance of testing 7.1
to see if it is improved. I believe it has been over 7.0.3.
I just did a test of my database that exhibits this behavior, using 7.1
from CVS.
When postmaster is started with "-o -fs" I get this:
On Mon, 11 Dec 2000, Tom Lane wrote:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and incorporate
changes into 7.2.
I'd vote for the second choice. I do not think we
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
VACUUM of a toast table crashed immediately after the movement
of a tuple(and before inserting corresponding index tuples).
Unfortunately the movement of a tuple is directly committed in
already committed state but
Tim Perdue [EMAIL PROTECTED] writes:
I thought the hackers team would be interested in knowing that SourceForge,
as of Friday evening, is running on Postgres.
Cool!
I'm running into some places where the query optimizer is not using the right
indexes, and sometimes does sequential scans on
I'd vote for the second choice. I do not think we should be adding new
features now. Also, I don't know about you, but I have enough bug fix,
testing, and documentation work to keep me busy till January even
without any new features...
It'd be really naughty to add it to the beta at
one thing I've found to get around this is for any query that doesn't
appear to use the index properly, just do:
SET ENABLE_SEQSCAN=OFF;
query
SET ENABLE_SEQSCAN=ON;
that way for those queries that do work right, ou haven't forced it a
different route ..
On Mon, 11 Dec 2000, mlw wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
should be easily testable though, no?
What makes you think that?
worst case, we pull it out afterwards ...
No, worst case is that we release a seriously broken 7.1, and don't
find out till afterwards.
There are plenty of new features on my to-do
On Mon, 11 Dec 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
should be easily testable though, no?
What makes you think that?
Alfred could volunteer to move to v7.1? *grin*
* Andrew Snow [EMAIL PROTECTED] [001211 20:21] wrote:
On Mon, 11 Dec 2000, Tom Lane wrote:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and incorporate
changes into
43 matches
Mail list logo
