future releases, OIDs will only be
guaranteed unique (modulo wraparounds) within a single table.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
On Thu, Jul 26, 2001 at 05:38:23PM -0400, Bruce Momjian wrote:
> Nathan Myers wrote:
> > Bruce wrote:
> > >
> > > I can confirm that current CVS sources have the same bug.
> > >
> > > > It's a bug in timestamp output.
> >
"the second
as a decimal number (00-61)". A footnote mentions "the range [0-61]
for tm_sec allows for as many as two leap seconds".
This is not to say that pg_dump should misrepresent stored times,
but rather that PG should not reject those misrepresented times as
being i
bly the perl scripts should say, likewise,
#!/usr/bin/env perl
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ce is that PG users are less
afraid to fork. Another is that without the GPL, we have elected
not to (and indeed cannot) stop any company from doing with PG what
NuSphere is doing with MySQL.
This is why characterizing the various licenses as more or less
"business-friendly" is
QL AB's license -- they shot the dog.
The lesson? Ask somebody competent, first, before you bet your
company playing license games.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
MySQL AB
would be within their rights to demand that the copyright to Gemini be
signed over, before offering forgiveness.
If Red Hat forks PostgreSQL, nobody will have any grounds for complaint.
(It's been forked lots of times already, less visibly.)
Nathan Myers
[EMAIL P
is a person who relies on someone
for financial support: Do you have any dependants?"
This is not for mailing-list pendantism, but just to make sure
that the right spelling gets into the code. (The page mentioned
above was found by entering "dependent dependant" into Google.)
On Thu, Jul 12, 2001 at 11:08:34PM +0200, Peter Eisentraut wrote:
> Nathan Myers writes:
>
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail. What I suggested is, instead of the
> > postmaster accept()ing the conne
in the normal case authentication happens quickly.
Then we can use a small listen() backlog, and never accept() if we
have more than MaxBackend back ends. The OS will keep a small queue
corresponding to our small backlog, and the clients will do our load
shedding for us.
Nathan Myers
[EMAIL PROTECT
that is often 5, which
is demonstrably too small.
> BTW: on linux, the backlog queue parameter is silently truncated to
> 128 anyway.
The 128 limit is common, applied on BSD and Solaris as well.
It will probably increase in future releases.
Nathan Myers
[EMAIL PROTECTED]
--
N), since there is no
> use in accepting more than your total allowed connections concurrently.
That might not have the effect you imagine, where many short-lived
connections are being made. In some cases it would mean that clients
are rejected that could have been served after a very short
determine how many attempts can
be in the queue before the network stack itself rejects them without
the postmaster involved.
As it is, the listen() queue limit is not useful. It could be made
useful with a slight change in postmaster behavior.
Nathan Myers
[EMAIL PROTECTED]
---
PG will need to support someday)
doesn't seem to change matters.
Probably if listen() did fail, then one or other of bind(), accept(),
and read() would fail too.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
seems better than depending on SSL
authentication, because SSL certification seems to be universally
misconfigured.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tue, Jul 10, 2001 at 06:36:21PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > All the OSes we know of fold it to 128, currently. We can jump it
> > to 10240 now, or later when there are 20GHz CPUs.
>
> > If you want to make it more compl
to 10240 now, or later when there are 20GHz CPUs.
If you want to make it more complicated, it would be more useful to
be able to set the value lower for runtime environments where PG is
competing for OS resources with another daemon that deserves higher
priority.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
r that we can't afford whole words, or even word
breaks? I propose "index_is_hint".
Actually, is the "ind[ex]" part even necessary?
How about "must_check_heap"?
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
re a new option on IMPORT. I suppose the
mappings could be temporary tables.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
7 -- to 127. See the six-page
discussion in Stevens UNPv1 beginning at page 93.
This is not to say we shouldn't fork before authentication, for
the above and other reasons, but the fix to listen(2)'s argument
should happen anyway.
Nathan Myers
[EMAIL PROTECTED]
---
st if we
> use a wraparound style of allocating XIDs. I think Vadim is advocating
> resetting the XID counter to 0 at each system restart, so the active
> range of XIDs might be a lot smaller than 2^32 in that scenario.)
That assumes a pretty frequent system restart
inding a NUL at *(char*)0, or
on being able to say "free(p); p = p->next;". Yes, it appears to work,
at the moment, on some platforms, but that doesn't make it correct.
It may not be terribly urgent to fix it right now, but that's far from
"isn't broken". It at least merits a TODO entry.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Thu, Jun 14, 2001 at 04:27:14PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > It could open a pipe, and write(2) a byte to it in the signal handler,
> > and then have select(2) watch that pipe. (SIGHUP could use the same pipe.)
> > Of course t
page 94. Examples using
other techniques (sigwait, nonblocking mq_receive) are presented also.
A pipe per backend might be considered pretty expensive. Does UNIX
allocate a pipe buffer before there's anything to put in it?
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
s.)
Things are a little more stable in some places (e.g. in Europe it is
improving) but worldwide all is chaos.
Assigning some country's current abbreviations at compile time is madness.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
T
s some errno codes that are not significant;
in particular, EINTR, EAGAIN, and EWOULDBLOCK. Of these, maybe
only the first occurs on a blocking socket.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensiv
that Java
doesn't also crash Netscape; it's just that pages with Java in them
are not very common.
There's little point in bookmarking a site that depends on client-side
Javascript or Java, because it won't be up for very long.
But this is *really* of
y weeks at a time. I also have no Flash
plugin. All together it makes for a far more pleasant web experience.
I didn't notice any problem with the Zend page.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading
d it out and redid it correctly,
you broke his code, you can just laugh, and add, if you're feeling
charitable, "experimental features are not to be depended on".
--
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
think that
> "char" ought to behave the same as char(1).
Does the standard require any particular behavior in with NUL
characters? I'd like to see PG move toward treating them as ordinary
control characters. I realize that at best it will take a long time
to get there. C
lmost always results in enough
performance improvement to make doing so worth a lot of disruption.
Today mmap() is used heavily enough, in important programs, that
worries about unreliability are no better founded than worries about
read().
Nathan Myers
[EMAIL PROTECTED]
careful planning about
breaking link compatibility. Other changes that break link compatibility
include changing a struct or class referred to from inline functions, and
adding a virtual function in a base class.
It's possible to make a lot of improvements without breaking link
compatibilit
to use the option. After a
major release, any modern construct that caused no trouble in the
last release is considered OK to use.
This process makes it easy to leave behind obsolete language
restrictions: if you wonder if it's OK now to use a feature that once
broke some cruft
:bar() const { ... }
>
> Thanks. That was my problem, not knowing when I break link compatiblity
> in C++. Major updated.
Wouldn't it be better to add the forwarding function and keep
the same major number? It's quite disruptive to change the
major number for wh
y,
you have to add another, overloaded member that is const, and turn
the non-const function into a wrapper. For example:
void Foo::bar() { ... } // existing interface
becomes
void Foo::bar() { ((const Foo*)this)->bar(); }
void Foo::bar() const { ... }
Nathan Myers
[EMAIL PRO
move old ones (which
>do not hold statuses for any running transactions).
I missed the original discussions; apologies if this has already been
beaten into the ground. But... mightn't sub-transactions be a
better-structured way to expose this service?
Nathan Myers
[
ted transactions on the old database when
you make the switch. But master-to-master replication is *hard* to
make work, and intrusive besides.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our exte
. Preferring mostly-full blocks improves active-storage and
cache density because a table tends to occupy fewer total blocks.
Does anybody know of papers that analyze the tradeoffs involved?
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast
On Thu, May 17, 2001 at 06:04:54PM +0800, Lincoln Yeoh wrote:
> At 12:24 AM 17-05-2001 -0700, Nathan Myers wrote:
> >
> >For those of you who have missed it, here
> >
>
>>http://www.google.com/search?q=cache:web.mit.edu/Saltzer/www/publications/endtoend/endto
are justified only as performance
enhancements.
It was written in 1981 and is undiminished by the subsequent decades.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister com
On Tue, May 15, 2001 at 05:53:36PM -0400, Bruce Momjian wrote:
> > But, if I may editorialize a little myself, this is just indicative of a
> > 'Fortress PostgreSQL' attitude that is easy to get into. 'We've always
>
> I have to admit I like the sound of 'Fortress PostgreSQL'. :-)
Ye Olde Pos
On Wed, Apr 25, 2001 at 09:41:57AM -0300, The Hermit Hacker wrote:
> On Tue, 24 Apr 2001, Nathan Myers wrote:
>
> > On Tue, Apr 24, 2001 at 11:28:17PM -0300, The Hermit Hacker wrote:
> > > I have a Dual-866, 1gig of RAM and strip'd file systems ... this past
> > &
Now that 7.1 is safely in the can, is it time to consider
this patch? It provides cursor support in PL.
http://www.airs.com/ian/postgresql-cursor.patch
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at
rather than all moving in concert reading or writing
only one block at a time. (Striping the WAL file on a couple of raw
devices might be a good idea along with the above. Can we do that?)
But of course speculation is much less useful than trying it. Some
measurements before and after would be reall
er excessive load, to clients who already
have a connection -- even if they just got one -- can have a similar
effect, but with finer granularity and with less complexity in the
clients.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
tive looks much better to me. On Linux you have
the much more efficient alternative, /proc/loadavg. (I wouldn't
use system(), though.)
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists
to make use of? I'll play with it if so ...
I agree that it would be useful. Even more useful would be soft load
shedding, where once some load average level is exceeded the postmaster
delays a bit (proportionately) before accepting a connection.
Nathan Myers
[EMAIL PROTECTED]
On Fri, Apr 20, 2001 at 04:53:43PM -0700, G. Anthony Reina wrote:
> Nathan Myers wrote:
>
> > Does the replication have to be reliable? Are you equipped to
> > reconcile databases that have got out of sync, when it's not?
> > Will the different labs ever tr
ally when it's made to
work, it runs on a LAN.
Reliable WAN replication is harder. Most of the proprietary database
companies will tell you they can do it, but their customers will tell
you they can't.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadc
t the timeout in a psql script
> than to try and code it.
Good: add a timeout feature to psql.
There's no limit to what features you might add to the database
core once you decide that new features need have nothing to do with
databases. Why not (drum roll...) deliver e-mail?
Natha
ply for the whole transaction. We could just set an alarm and do a
> longjump out on timeout.
Of course, it begs the question why the client couldn't do that
itself, and leave PG out of the picture. But that's what we've
been talking about all along.
Nathan Myers
ter need for simple
components than people building little ones.
What might be a reasonable alternative would be a BEGIN timeout: report
failure as soon as possible after N seconds unless the timer is reset,
such as by a commit. Such a timeout would be meaningful at the
database-interface
y, very nasty. If they find
that by seeding the press with reasonable-sounding criticisms of PG,
they can prod the PG community into making itself look like idiots,
they will go to town on it.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)
can possibly provide the needed service.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
2 and 7.3, and lots of deployments. Few will read his rambling.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
publishes them. Typically the Linux magazines print what he
writes, and thereby get it mostly right, but the finance magazines
mangle them to total nonsense.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Sun, Apr 15, 2001 at 11:44:48AM -0300, The Hermit Hacker wrote:
> On Sat, 14 Apr 2001, Nathan Myers wrote:
>
> > This is probably a good time to point out that this is the _worst_
> > _possible_ response to erroneous reportage. The perception by readers
> > will
r to help her check her
facts next time. PostgreSQL needs friends in the press, even if
they are ignorant or lazy. It doesn't need any enemies in the press.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> [EMAIL PROTECTED]
>
> Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux,
> redhat-announce is also a suitable location.
Linux Journal: [EMAIL PROTECTED]
Freshmeat: [EMAIL PROTECTED]
LinuxToday: http://linuxtoday.com/contribute.php3
--
Nathan Mye
On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > We are thinking about working around the name length limitation
> > (encountered in migrating from other dbs) by allowing "foo.bar.baz"
> > name syntax, as
On Fri, Apr 13, 2001 at 02:54:47PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Sorry, false alarm. When I got the test case, it turned out to
> > be the more familiar problem:
>
> > create table foo_..._bar1 (id1 ...);
> > [notic
On Fri, Apr 13, 2001 at 01:16:43AM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > We have noticed here also that object (e.g. table) names get truncated
> > in some places and not others. If you create a table with a long name,
> > PG truncates t
choice is not just between Yacc and a hand-coded parser.
Since Yacc, many more powerful parser generators have been released,
one of which might be just right for PG.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
d creates a table with the shorter name; but
if you refer to the table by the same long name, PG reports an error.
(Very long names may show up in machine- generated schemas.) Would
patches for this, e.g. to refuse to create a table with an impossible
name, be welcome
discussion until after 7.1 is out
the door, but that "dubious at best" demands an answer. See the archive
posting:
http://www.postgresql.org/mhonarc/pgsql-hackers/2001-01/msg00473.html
...
Incidentally, is the page at
http://www.postgresql.org/mhonarc/pgsql-hackers/2001-01/
the best
previous text?
>
> Let's return to this discussion *after* 7.1 release.
> My main objection was (and is) - no time to deal with
> this issue for 7.1.
OK, everybody agreed on that before.
This doesn't read like an objection to having it on the TODO list
maybe while Vadim was absent.
Should I re-post the previous text?
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
a is physically on the platter, they will
"forget" if they see activity that looks like benchmarking. Others just
ignore the command, and in any case they all default to unsafe mode.)
If the reason that a block CRC isn't on the TODO list is that Vadim
objects, maybe we should
oting,
besides, the glibc-version tested along with each Linux kernel version.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
26, Alexander Klimov
> Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only)
I saw three separate reports of successful builds on Linux 2.4.2 on x86
(including mine), but it isn't listed here.
--
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)
lt different from the child's, then pg_dump
> had better emit the child field explicitly.
The rule above appears to work even if inherited-default conflicts
are not taken as an error, but just result in a derived-table column
with no default.
Nathan Myers
[EMAIL PROTECTED]
--
lt value.
A bit of O-O doctrine... when you find yourself tempted to do something
like the above, it usually means you're trying to do the wrong thing.
You may not have a choice, in some cases, but you should know you are
on the way to architecture meltdown. "She'll blow, Cap'
On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> >> This seems pretty random. It would be more reasonable if multiple
> >> (default) inheritance weren't allowed unless you explicitly specify a new
> >> defau
t said:
--
All 76 tests passed.
--
Nathan Myers
[EMAIL PROTECTED]
On Sat, Mar 31, 2001 at 12:02:35PM +1200, Franck Martin wrote:
> I still don't see an entry for Linux 2.4.x
>
> Cheers.
>
> Thomas Lockhart wrote:
>
> > Unreported or problem platform
se-table code only has to understand
the derived table. The derived table need not be able to represent
all values possible in the base table.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Fri, Mar 30, 2001 at 12:10:59PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > The O-O principle involved here is Liskov Substitution: if the derived
> > table is used in the context of code that thinks it's looking at the
> > base table, d
lumn type) remains unchanged.
The O-O principle involved here is Liskov Substitution: if the derived
table is used in the context of code that thinks it's looking at the
base table, does anything break?
Changing the default value of a column should not break anything,
because the different defau
manual, it's probably much freer than GPL. For the paranoid,
the actual instructions, extracted, are just
1:
ll %0,%3
bnez %0,2f
li %1,1
sc %1,%2
beqz %1,1b
2:
Nathan Myers
[EMAIL PROTECTED]
---
/* Machine-dependent p
Or, better
#define FRAG64(bits,shift) (((uint64)(bits)) << (shift))
#define LITERAL64(a,b,c,d) \
FRAG64(a,48) | FRAG64(b,32) | FRAG64(c,16) | FRAG64(d,0)
LITERAL64(0xdead,0xbeef,0xfeed,0xface)
That might be overkill for just a single literal...
Nathan Myers
ncm
-
hed in shm and copied to mmapped blocks
after it is ok for them to be written.
What platforms does PG run on that don't have mmap()?
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Mon, Mar 05, 2001 at 02:00:59PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > The CRC-64 code used in the SWISS-PROT genetic database is (now) at:
> > ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz
>
> > From
like "12:47:63".
The only unfortunate feature is their standard format for a
date/time: "2001-03-22T12:47:63". To me the ISO date format
is far better than something involving month names.
I'd like to see ISO 8601 as the default data format.
--
Nathan Myers
[EM
gt;
> >Can we slightly enlarge the font?
>
> Can do. What size do you think is best?
>
> I've always used size=1 for that line...
Absolute font sizes in HTML are always a mistake. size="-1" would do.
--
Nathan Myers
[EMAIL PROTECTED]
---(end o
On Sat, Mar 10, 2001 at 06:29:37PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Is this page
> > http://members.fortunecity.com/nymia/postgres/dox/backend/html/
> > common knowledge?
>
> Interesting, but bizarrely incomplete. (Yeah, we ha
also a way to automate internal
documentation.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
On Fri, Mar 09, 2001 at 12:05:22PM -0500, Tom Lane wrote:
> > Gettext takes care of this. In the source you'd write
>
> > elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
> > string, string);
>
> Duh. For some reason I was envisioning the localization su
On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Similar approaches have been tried frequently, and even enshrined
> > in standards (e.g. POSIX catgets), but have almost always proven too
> > cumbersome. The pr
It's better to scan the program for elog() arguments, and generate
a catalog by using the string itself as the index code. Those
maintaining the secondary programs can compare catalogs to see what
has been broken by changes and what new messages to expect. elog()
itself can (optionally) invent tokens (e.g. catalog indices) to help
out those programs.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
d a movement toward more
modern, better behaved interprocess communication mechanisms. Still,
"if it were done when 'tis done, then 'twere well It were done" cleanly.
--
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
n't hurt you when running on sound hardware,
but it offers a good chance of preventing embarrassments for (the
overwhelming fraction of) users on garbage hardware.
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading
an enormous win vs. a fixed shm and manual scheduling by PG. If that
requires changes in the logging protocol, it's worth it.
(What supported platforms don't have mmap?)
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
y (probably more, actually, since it's much more likely that
> the previous checkpoint will have reached disk safely).
Actually far more: if the checkpoints are minutes apart, even the
worst disk drive will certainly have flushed any blocks written for
the earlier checkpoin
On Tue, Mar 06, 2001 at 04:20:13PM -0500, Lamar Owen wrote:
> Nathan Myers wrote:
> > That is why there is no problem with version skew in the syscall
> > argument structures on a correctly-configured Linux system. (On a
> > Red Hat system it is very easy to get them out
ed/
usupported feature that disappears in a later library version.)
That is why there is no problem with version skew in the syscall
argument structures on a correctly-configured Linux system. (On a
Red Hat system it is very easy to get them out of sync, but RH fans
are used to problems.)
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
the same. (As a rule of thumb, where it
works right, credit Linux; where it doesn't, blame Red Hat. :-)
Nathan Myers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ought not to require an
initdb.
Of course the details of the current implementation may interfere with
that ideal, but it seems a worthy goal for the next beta, if it's not
possible already. Given the opportunity to change the current WAL format,
it ought to be possible to avoid even need
le-time option to select the old one, you could allow users who
> > wish to avoid the initdb a way to continue with the existing pair of
> > CRC-32s.
>
> Added to TODO:
>
> * Correct CRC WAL code to be normal CRC32 algorithm
Um, how about
* Correct CRC WAL code to be a real CRC64 algorithm
instead?
Nathan Myers
[EMAIL PROTECTED]
generator polynomial is x64 + x4 + x3 + x1 + 1.
I would suggest that if you don't change the algorithm, at least change
the name in the sources. Were you to #ifdef in a real crc-64, and make
a compile-time option to select the old one, you could allow users who
wish to avoid the initdb a way to continue with the existing pair of
CRC-32s.
Nathan Myers
[EMAIL PROTECTED]
ed widely. Since it was
the fundamental mechanism for all memory operations in Mach, arbitrary
limits would make no sense. That it worked so well is the reason it
was copied everywhere else, so adding arbitrary limits while copying
it would be silly. I don't think we'll see any systems like that.
Nathan Myers
[EMAIL PROTECTED]
t seems (100k,1) (brown +) did best by far, which seems
very odd. Even more odd, it did pretty well at very high loads but had
problems at intermediate loads.
Nathan Myers
[EMAIL PROTECTED]
1 - 100 of 192 matches
Mail list logo
