On Wed, Mar 12, 2008 at 02:10:08PM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > > Tom Lane wrote:
> > > > >> Personally I think it would be just
Magnus Hagander wrote:
> On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > Tom Lane wrote:
> > > >> Personally I think it would be just fine if we had only the wiki copy
> > > >> and forgot about shipping it in
On Wed, Mar 12, 2008 at 11:32:16AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Personally I think it would be just fine if we had only the wiki copy
> > >> and forgot about shipping it in tarballs.
> >
> > > The problem w
Bruce Momjian wrote:
> Probably the biggest missing feature for the TODO is the ability to
> summarize, group into labeled sections and subsections, and the ability
> to move items around, with URL links to more detail. Effectively that
> is all the TODO list is.
Oh, like a Wiki page.
--
Alvar
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 12 Mar 2008 12:39:06 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > > > If it was a service we could use for free, we could consider it.
> > >
> > > https://launchpad.net/
> > > http://www.sourcefo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:39:06 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > If it was a service we could use for free, we could consider it.
> >
> > https://launchpad.net/
> > http://www.sourceforge.net/
>
> Those are a step backward ---
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 12 Mar 2008 12:10:27 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > It is a best effort with our limited resources.
> > >
> > > Should we outsource it? It is user-facing :-p
> >
> > If it was a serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 12 Mar 2008 12:10:27 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> It is a best effort with our limited resources.
> >
> > Should we outsource it? It is user-facing :-p
>
> If it was a service we could use for free, we could conside
Dave Page wrote:
> On Wed, Mar 12, 2008 at 3:32 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote:
> > > This seems to me to be nonsense. You've never maintained the
> > > back-branch versions of the TODO list, so they're out of date anyway
> > > --- ie, they don't account for pro
On Wed, Mar 12, 2008 at 3:32 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > This seems to me to be nonsense. You've never maintained the
> > back-branch versions of the TODO list, so they're out of date anyway
> > --- ie, they don't account for problems discovered post-relea
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Personally I think it would be just fine if we had only the wiki copy
> >> and forgot about shipping it in tarballs.
>
> > The problem with not shipping the TODO file at all is that TODO gives
> > users a list of
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Personally I think it would be just fine if we had only the wiki copy
>> and forgot about shipping it in tarballs.
> The problem with not shipping the TODO file at all is that TODO gives
> users a list of all known bugs/missing feature
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Let's move the TODO list to the wiki.
>
> > We need it to do a few things:
>
> > o We need to be able to pull a text and HTML copies for tarballs
>
> Why? Even if we think the TODO list needs to app
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Let's move the TODO list to the wiki.
> We need it to do a few things:
> o We need to be able to pull a text and HTML copies for tarballs
Why? Even if we think the TODO list needs to appear in tarballs (which
is hardly
Magnus Hagander wrote:
> > If you change the text file, I will see the CVS update and update the
> > HTML --- I will never lose a change because my CVS sees your changes.
>
> That seems like a lot of extra work that should be unnecessary.
>
> I asked before for general reactions, so I will now tu
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Something to remember: currently we update t_infomask (set
> HEAP_XMAX_COMMITTED etc) while holding share lock on buffer -
> we have to change this before block CRC implementation.
Yeah, we'd lose some concurrency there.
rega
> To be perfectly clear: I have actually seen bug reports trace to
> problems that I think a block-level CRC might have detected (not
> corrected, of course, but at least the user might have realized he had
> flaky hardware a little sooner). So I do not say that the upside to
> a block CRC is nil
> If we're in the business of expending cycles to guard against
> nil-probability risks, let's checksum our executables every time we
> start up, to make sure they're not overwritten. Actually, we'd
better
> re-checksum program text memory every few seconds, in case RAM
dropped
> a bit since we l
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
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
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Two changes for the TODO list.
>>
>> 1. Under "RELIABILITY/MISC", add:
>>
>> Write out a CRC with each data block, and verify it on reading.
>>
>> 2. Under SOURCE CODE, I believe Tom has already implemented:
>>
>> Correct CRC WAL code to be a real C
> > 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 was the discus
>
> Bruce,
>
> Two changes for the TODO list.
>
> 1. Under "RELIABILITY/MISC", add:
>
> Write out a CRC with each data block, and verify it on reading.
>
> 2. Under SOURCE CODE, I believe Tom has already implemented:
>
> Correct CRC WAL code to be a real CRC64 algorithm
TODO updated.
PHP can run java code. It would be easiest, because php doesn't parse php
pages, the Zend engine is linked to php to actually parse. Which would
make Zend easy to add into Postgresql, (which already runs under apache,
which is non-threaded).
The only issue is the Zend license..
Of course, this m
37 matches
Mail list logo
