Thomas Lockhart <[EMAIL PROTECTED]> writes:
> btw, I've applied the patch for the expected/ files to all variants of
> horology.out, so all platforms should pass that test now.
FWIW, I confirm that horology-no-DST-before-1970 is good; it passes on
HPUX. Can anyone confirm horology-solaris-1947?
> Okay, unless I hear different from anyone out there, I'm goin to roll RC3
> when I get to work tomorrow, and announce it before I leave (to give it
> some time to propogate to the mirrors) ...
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > Thomas? Did I miss your patch for the 'WITH TI
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Found the issue. Try out the attached SQL in a fresh database.
And? AFAICT it behaves as expected, in either 7.0.2 or current ...
regards, tom lane
---(end of broadcast)---
TIP 2
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc.
The only thing that surprised me here was all of the warnings from
libreadline calls:
>> tab-complete.c: In function `initialize_readline':
>> tab-complete.c:103: warning:
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc. It's probably good enough for normal use since the
> differences are not extensive, but someone would need to look at the
> diff's for longer than the 10 seconds or so I've spent so far, and
> someone should actually s
> after running `unlimit' (tcsh) before `make check', the only failures i have
> are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64.
I'll mark both NetBSD/sparc as supported, for both 32 and 64-bit builds.
Thanks!
- Thomas
Bottom line: 7.1RC1 passes most of the regression tests on
NetBSD/macppc. It's probably good enough for normal use since the
differences are not extensive, but someone would need to look at the
diff's for longer than the 10 seconds or so I've spent so far, and
someone should actually set it
Found the issue. Try out the attached SQL in a fresh database.
I had honestly expected the second delete to work properly as nothing
had to be removed that table.
The rule was added as a temporary measure to protect the data
currently in the table -- without the intent of otherwise impeding the
At 22:52 5/04/01 -0400, Tom Lane wrote:
>
>> What about guarding against file system problems, like blocks of one
>> (non-PG) file erroneously writing to blocks of another (PG table) file?
>
>Well, what about it? Can you offer numbers demonstrating that this risk
>is probable enough to justify th
Okay, unless I hear different from anyone out there, I'm goin to roll RC3
when I get to work tomorrow, and announce it before I leave (to give it
some time to propogate to the mirrors) ...
On Thu, 5 Apr 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Thomas? Did I mis
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Still not there in CVS ...
> Does anyone else have anything left outstanding that should hold me off
> from doing an RC3 tomorrow?
Other than a better answer for the horology
Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Does anyone else have anything left outstanding that should hold me off
from doing an RC3 tomorrow?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EM
Philip Warner <[EMAIL PROTECTED]> writes:
>> So the only real benefit of a block-level CRC would be to guard against
>> bits dropped in transit from the disk surface to someplace else
> What about guarding against file system problems, like blocks of one
> (non-PG) file erroneously writing to blo
> > Blocks that have recently been written, but failed to make
> > it down to the disk platter intact, should be restorable from
> > the WAL log. So we do not need a block-level CRC to guard
> > against partial writes.
>
> If a block is missing some sectors in the middle, how would you know
> to
At 18:25 5/04/01 -0400, Tom Lane wrote:
>
>A block-level CRC might be useful to guard against long-term data
>lossage, but Vadim thinks that the disk's own CRCs ought to be
>sufficient for that (and I can't say I disagree).
>
>So the only real benefit of a block-level CRC would be to guard against
On Thu, Apr 05, 2001 at 06:25:17PM -0400, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> If the reason that a block CRC isn't on the TODO list is that Vadim
> >> objects, maybe we should hear some reasons why he objects? Maybe
> >> the objections could be dealt with, and eve
> > So, for what CRC could be used? To catch disk damages?
> > Disk has its own CRC for this.
>
> Oh, I see. For anyone else who has trouble reading between the lines:
>
> Blocks that have recently been written, but failed to make it down to
> the disk platter intact, should be restorable from
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> If the reason that a block CRC isn't on the TODO list is that Vadim
>> objects, maybe we should hear some reasons why he objects? Maybe
>> the objections could be dealt with, and everyone satisfied.
> Unordered disk writes are covered by backing u
On Thu, Apr 05, 2001 at 02:47:41PM -0700, Mikheev, Vadim wrote:
> > > So, for what CRC could be used? To catch disk damages?
> > > Disk has its own CRC for this.
> >
> > OK, this was already discussed, maybe while Vadim was absent.
> > Should I re-post the previous text?
>
> Let's return to th
> > So, for what CRC could be used? To catch disk damages?
> > Disk has its own CRC for this.
>
> OK, this was already discussed, maybe while Vadim was absent.
> Should I re-post the previous text?
Let's return to this discussion *after* 7.1 release.
My main objection was (and is) - no time to
On Thu, Apr 05, 2001 at 02:27:48PM -0700, Mikheev, Vadim wrote:
> > If the reason that a block CRC isn't on the TODO list is that Vadim
> > objects, maybe we should hear some reasons why he objects? Maybe
> > the objections could be dealt with, and everyone satisfied.
>
> Unordered disk writes
> If the reason that a block CRC isn't on the TODO list is that Vadim
> objects, maybe we should hear some reasons why he objects? Maybe
> the objections could be dealt with, and everyone satisfied.
Unordered disk writes are covered by backing up modified blocks
in log. It allows not only catch
On Thu, Apr 05, 2001 at 04:25:42PM -0400, Ken Hirsch wrote:
> > > > TODO updated. I know we did number 2, but did we agree on #1 and is
> it
> > > > done?
> > >
> > > #2 is indeed done. #1 is not done, and possibly not agreed to ---
> > > I think Vadim had doubts about its usefulness, though per
> > > TODO updated. I know we did number 2, but did we agree on #1 and is
it
> > > done?
> >
> > #2 is indeed done. #1 is not done, and possibly not agreed to ---
> > I think Vadim had doubts about its usefulness, though personally I'd
> > like to see it.
>
> That was my recollection too. This
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just committed some changes so that ecpg does acceptt "long long"
> variables all the time, but repleces them with type "long" if
> HAVE_LONG_LONG_INT_64 is not defined.
This looks like a workable strategy for now. Ten years from now, when
"long" me
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Has anybody done performance and reliability tests with CRC64 ?
> I think it must be a CPU eater. It looks a lot more complex than a CRC32.
On my box (PA-RISC) the inner loop is about 14 cycles/byte, vs. about
7 cycles/byte for CRC32. On alm
> > 1. Under "RELIABILITY/MISC", add:
> >
> > Write out a CRC with each data block, and verify it on reading.
> TODO updated. I know we did number 2, but did we agree on #1 and is it
> done?
Has anybody done performance and reliability tests with CRC64 ?
I think it must be a CPU eater. It
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>>
>> "Bad address"? That seems pretty bizarre.
> This is obviously some
matthew green <[EMAIL PROTECTED]> writes:
> digging into the regression.diffs, i can see that:
> - reltime failed because it just had:
> ! psql: Backend startup failed
>The postmaster log file should have more info, but a first thought is
>that you ran up against process or swap-space
I will be on the road for the next two weeks. If something need to be done
with ecpg please go ahead and make the changes.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)-
Mathijs Brands wrote:
>
> On Wed, Apr 04, 2001 at 06:46:12PM +0300, Martín Marqués allegedly wrote:
> > Why are you running configure inside src/? I'm not sure if the 7.0.x had the
> > configure on the src/ dir or the root.
>
> It's in the src dir with 7.0.x alright.
>
> > You could take a look
> > FATAL 2: XLogWrite: write request is past end of log" to syslog.
Ok, I hope this one is fixed. Tom, please review changes.
Konstantin, are you able to compile PG from CVS?
To restart postmaster with current version...
Vadim
---(end of broadcast)---
On Thu, Apr 05, 2001 at 10:01:53AM +0200, Zeugswetter Andreas SB wrote:
> I do agree with the statement, that HAVE_LONG_LONG_INT_64 shoud be
> defined on all platforms where the compiler understands it to be 64bits.
> It would imho be the responsibility of backend code, to only do one of
> the two
On Thu, Apr 05, 2001 at 09:13:49AM +0300, Adriaan Joubert wrote:
> I think we probably do need the CPP defines from my patch in there, so
Not exactly. The test in typename.c does not make sense at all. It will be
removed. But there are other places where it is needed. Or can I safely
assume that
> > Could you please try to just remove the cpp flag? Also I wonder why you are
> > using "long long int" instead of just "long int" in your C program. Well
> > that is the people who complained to you.
>
> Yes, dropping the CPP flags solves the problem for us. I assume all
> platforms have long
Tom Lane <[EMAIL PROTECTED]> writes:
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms
36 matches
Mail list logo
