OK, I have a stupid question- torn pages are a problem, but only during
recovery. Recovery is (I assume) a fairly rare condition- if data
corruption is going to happen, it's most likely to happen during normal
operation. So why not just turn off CRC checksumming during recovery,
or at least
I have a stupid question wrt hint bits and CRC checksums- it seems to me
that it should be possible, if you change the hint bits, to be able to
very easily calculate what the change in the CRC checksum should be.
The basic idea of the CRC checksum is that, given a message x, the
checksum is x
Jonah H. Harris wrote:
On Thu, Oct 2, 2008 at 9:07 AM, Brian Hurt [EMAIL PROTECTED] wrote:
I have a stupid question wrt hint bits and CRC checksums- it seems to me
that it should be possible, if you change the hint bits, to be able to very
easily calculate what the change in the CRC checksum
Paul Schlie wrote:
... if that doesn't fix
the problem, assume a single bit error, and iteratively flip
single bits until the check sum matches ...
This can actually be done much faster, if you're doing a CRC checksum
(aka modulo over GF(2^n)). Basically, an error flipping bit n will
always
Brian Hurt wrote:
Paul Schlie wrote:
... if that doesn't fix
the problem, assume a single bit error, and iteratively flip
single bits until the check sum matches ...
This can actually be done much faster, if you're doing a CRC checksum
(aka modulo over GF(2^n)). Basically, an error flipping
David Fetter wrote:
This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
Andrew Sullivan wrote:
On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote:
Being able to do read-only queries makes this feature more valuable in more
situations, but I disagree that it's a deal-breaker.
Your managers are apparently more enlightened than some
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
...
Neither the dealer, nor the workers would need access to the either
the shared memory or the disk, thereby not messing with the one backend
is one transaction is one session dogma.
...
Unfortunately, this idea has far too
Andrew Dunstan wrote:
Florian G. Pflug wrote:
Would it be possible to determine when the copy is starting that
this case holds, and not use the parallel parsing idea in those cases?
In theory, yes. In pratice, I don't want to be the one who has to
answer to an angry user who just
Kevin Grittner wrote:
If you really are doing proper maintenance, and you don't need exact
counts, you might be able to use the approximation stored in the
system tables:
Also, if you're using count(*) as an existance test (common in Mysql
code), it's better to use exists instead. Using
Brian Hurt wrote:
While we're blue skying things, I've had an idea for a sorting
algorithm kicking around for a couple of years that might be
interesting. It's a variation on heapsort to make it significantly
more block-friendly. I have no idea if the idea would work, or how
well it'd work
While we're blue skying things, I've had an idea for a sorting algorithm
kicking around for a couple of years that might be interesting. It's a
variation on heapsort to make it significantly more block-friendly. I
have no idea if the idea would work, or how well it'd work, but it might
be
Josh Berkus wrote:
Folks,
You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
We use mercurial here at work, having switched to it recently, and while
I
Kenneth Marshall wrote:
How likely is it that you will get a hash collision, two strings that are
different that will hash to the same value? To avoid this requires a very
large hash key (128 bits, minimum)- otherwise you get into birthday attack
problems. With a 32-bit hash, the
Kenneth Marshall wrote:
I understand that a hash value is a many-to-one mapping. That is the
point of the flag in the index. The flag means that there is only one
item in the heap corresponding to that hash value. In this case we
know that the value in the heap is the correct one and a possibly
Tom Lane wrote:
Comments? Does anyone think the C standard forbids what I'm worried
about?
My understanding of the C spec is that it explicitly *allows* for
exactly what you're afraid of. It's even possible if the uses include
function calls, as the compiler might inline the function
Chuck McDevitt wrote:
Tom, it isn't just a case of convenience. When we are trying to
convert users from another database (say Oracle for example) to
PostgeSQL, one of the big stumbling blocks that slows down the work is
all the little query changes that people have to make (people who might
I'm not sure if this is the right venue for this- if it isn't, I apologize.
But a feature that I'd like to see is the ability to put an 'as' alias
on the target of an update statement.
I find myself often writing statements like:
UPDATE
some_really_long_table_name
SET
col1
Peter Eisentraut wrote:
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
If everyone
Larry McGhaw wrote:
I'm really frustrated by this process I'm not trying to attack anyone
here. I'm just surprised that no one will even entertain the idea that
this is an issue that needs to be addressed.
Instead nearly all of the responses have been attacking the applications
that rely on
Tom Lane wrote:
I just finished giving someone the standard advice to wait a bit before
trying to drop a database that'd just been accessed:
http://archives.postgresql.org/pgsql-general/2007-05/msg01505.php
AFAICT a real fix for this would involve making PQfinish() synchronous
(don't return
My apologies for the late reply...
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I'd like to see a new variant on PQexec():
PGresult * PQexecf(PGconn *conn, const char *fmt, ...);
Way too late for 8.3 --- if we were going to do something like this,
we should think first and program
Shane Ambler wrote:
August Zajonc wrote:
Agreed with Tom on this one. Full usage of money is beyond tagged types
etc. For example, when you earn money in another currency, it is the
time at which you earn it that describes its value. So for PL accounts
there is generally no change in exchange
Markus Schiltknecht wrote:
Hi,
I recall having read something about rewriting the parser. Together
with Tom being worried about parser performance and knowing GCC has
switched to a hand written parser some time ago, I suspected bison to
be slow. That's why I've asked.
This has little to
Hello all. It seems I'm tripping an assert in 8.1.6- the assert on line
219 of src/backend/executor/execScan.c (found by running gdb on a core
dump). This is on x86 and Redhat Linux (forget which version). Note
that if I recompile 8.1.6 with asserts turned off the query completes
just
More info on that assert I've hit.
Compile 8.1.6 with configuration options:
./configure --with-perl --enable-debug --enable-cassert
(not sure if --perl is relevent or not, I think not).
This is on Fedora Core 5 on x86-32.
Execute, on a fresh database, the following sql, to recreate the bug:
I forgot to mention: core dumps available upon request (obviously I
don't want to post them to the list).
Brian
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Tom Lane wrote:
Brian Hurt [EMAIL PROTECTED] writes:
Execute, on a fresh database, the following sql, to recreate the bug:
Hmm, I thought that stack trace looked a bit familiar --- we seem to
have fixed the problem as of 8.2. Unfortunately I can't recall what
the relevant change
Neil Conway wrote:
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is *not* going in the right direction :-(
Well, then show me what direction you think is better.
Fewer restrictions, not more. The thrust of what I've been
Joachim Wieland wrote:
Yes, I completely agree that JDT should not be included. I just wanted to
understand how those lines show that JST is still in active use. As far as I
understand it, it says that JST was observed from 1948 to 1951 (the second
rule) and now there is a time zone J%sT
My apologies if this subject has already been hashed to death, or if
this is the wrong list, but I was wondering if people had seen this paper:
http://www.cwi.nl/htbin/ins1/publications?request=intabstractkey=ZuHeNeBo:ICDE:06
Basically it describes a compression algorithm for tables of a
32 matches
Mail list logo
