I believe that there are many good points to have CRC facilities "built
int", and I failed to detect any arguments against it. In my domain (the
medical domain) we simply can't use data without "proof" of integrity
("proof" as in highest possible level of confidence within reasonable
effort)
Th
I wrote:
> Next 4 bytes: integer layout field. This consists of the int32 constant
> 0x0A820D0A expressed in the source machine's endianness. (Again, value
> chosen with malice aforethought, to catch files munged by things like
> DOS/Unix newline conversion or high-bit-stripping.)
Actually, tha
Philip Warner <[EMAIL PROTECTED]> writes:
> I don't want to continue being picky, but you could just use 4 bytes for a
> maj-min-rev-patch version number (in that order), and avoid the endian
> issues by reading and writing each byte. No big deal, though.
Well, the thing is that we need to protec
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> ... and find the *every* .htm file has a "good" name. Hmm. Is it the
> fact that someone went through and added an "id field" to every chapter
> and section header? Whoever it was, good job! It wasn't me, but whoever
> it was: good job :)
> Ah, a peru
> Is there any prospect of making the output filenames more predictable?
> Who should I annoy about it?
Well, you could annoy me about it...
... and I would go to my local installation of the source tree...
... and build the docs to confirm that the *chapters* have good
predictable names...
..
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> [ various good reasons ]
> 3) We put the docs into cvs, but the jade/docbook output did not have
> predictable file names. So each release would require wiping the output
> docs and somehow guessing which files were obsolete and which were new.
That'
At 14:28 7/12/00 -0500, Tom Lane wrote:
>
>Next 4 bytes: version number, currently 1 (expressed in source machine's
>endianness
I don't want to continue being picky, but you could just use 4 bytes for a
maj-min-rev-patch version number (in that order), and avoid the endian
issues by reading and w
> > Another thing we should think about is to not tar.gz the documentation
> > files. That way we could create useful incremental diffs between releases
> > later on. Any comments here?
> I've never figured out why we do that.
Well...
> Since the thing is going to be
> inside a tarball anyway,
| | That's ok, you work with Dan Moschuk right?
|
| He's my bitch. :-)
|
| And as such, I've donated him to do neat things with postgres' C++ interface
| (for whatever reason, he's of the less-enlightened opinion that C++ shouldn't
| be dragged out into the backyard and shot).
*sigh* No more
| > Sorry about that email. I was trying to forward your comments to a friend
| > and due to a lack of sleep I just typed "R" in pine. Doh!
|
| That's ok, you work with Dan Moschuk right?
He's my bitch. :-)
And as such, I've donated him to do neat things with postgres' C++ interface
(for wha
* Tom Samplonius <[EMAIL PROTECTED]> [001207 18:55] wrote:
>
> On Thu, 7 Dec 2000, Alfred Perlstein wrote:
>
> > We recently had a very satisfactory contract completed by
> > Vadim.
> >
> > Basically Vadim has been able to reduce the amount of time
> > taken by a vacuum from 10-15 minutes down
On Thu, 7 Dec 2000, Alfred Perlstein wrote:
> We recently had a very satisfactory contract completed by
> Vadim.
>
> Basically Vadim has been able to reduce the amount of time
> taken by a vacuum from 10-15 minutes down to under 10 seconds.
...
What size database was that on?
I looking at
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> ... However there's a hook mentioned in my abstract that
> explains that if a constant makes it into a function, you can
> provide a hook so that the function can return whether or not that
> constant is cacheable.
Oh, I see --- you're right, I misse
* Tom Lane <[EMAIL PROTECTED]> [001207 17:10] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Basically Vadim has been able to reduce the amount of time
> > taken by a vacuum from 10-15 minutes down to under 10 seconds.
>
> Cool. What's it do, exactly?
* Tom Lane <[EMAIL PROTECTED]> [001207 16:45] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Each function should have a marker that explains whether when given
> > a const input if the output might vary, that way subexpressions can
> > be collapsed until an input becomes non-const.
>
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Basically Vadim has been able to reduce the amount of time
> taken by a vacuum from 10-15 minutes down to under 10 seconds.
Cool. What's it do, exactly?
regards, tom lane
I just recently heard from Julia Case, who is willing to work on
maintaining the ODBC drivers after Xmas ... for those that don't know the
name, she was pretty much the original ODBC developer/maintainer, until
work overwhelmed her ...
On Thu, 7 Dec 2000, Joel Burton wrote:
> The official ODBC
* Joel Burton <[EMAIL PROTECTED]> [001207 15:52] wrote:
> > We had problem with a query taking way too long, basically
> > we had this:
> >
> > select
> > date_part('hour',t_date) as hour,
> > transval as val
> > from st
> > where
> > id = 500
> > AND hit_date >= '2000-12-07 14:27:24-08'
[EMAIL PROTECTED] (Nathan Myers) writes:
> 2. I disagree with way the above statistics were computed. That eleven
>million-year figure gets whittled down pretty quickly when you
>factor in all the sources of corruption, even without crashes.
>(Power failures are only one of many s
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Each function should have a marker that explains whether when given
> a const input if the output might vary, that way subexpressions can
> be collapsed until an input becomes non-const.
We already have that and do that.
The reason the datetime-rela
"Mikheev, Vadim" wrote:
>
> > > > Probably this is caused by my trial (local) change
> > > > and generated an illegal log output.
> > > > However it seems to mean that WAL isn't always
> > > > redo-able.
> > >
> > > Illegal log output is like disk crash - only BAR can help.
> >
> > But redo-recove
The official ODBC driver from pg7.0.x doesn't work w/7.1 (b/c of the
changes in the system catalogs, IIRC).
The CVS 7.1devel code works and builds easily, but I suspect 99%
of the beta testers won't have Visual C++ or won't be able to
compile the driver. Is there an official driver-compiler-p
On Thu, 7 Dec 2000, Martin A. Marques wrote:
> On Thursday 07 December 2000 16:48, The Hermit Hacker wrote:
> > Okay, since I haven't gotten word back on where to find the docs for v7.1,
> > it still contains those for v7.0, but I just put up beta1 tarballs in the
> > /pub/dev directory ... can s
> We had problem with a query taking way too long, basically
> we had this:
>
> select
> date_part('hour',t_date) as hour,
> transval as val
> from st
> where
> id = 500
> AND hit_date >= '2000-12-07 14:27:24-08'::timestamp - '24
> hours'::timespan AND hit_date <= '2000-12-07 14:27:24-
On Thu, Dec 07, 2000 at 04:35:00PM -0500, Tom Lane wrote:
> Remember that we are already sitting atop hardware that's really
> pretty reliable, despite the carping that's been going on in this
> thread. All that we have to do is detect the infrequent case where a
> block of data didn't get written
I have an abstract solution for a problem in postgresql's
handling of what should be constant data.
We had problem with a query taking way too long, basically
we had this:
select
date_part('hour',t_date) as hour,
transval as val
from st
where
id = 500
AND hit_date >= '2000-12-07 14:27:2
On Thu, Dec 07, 2000 at 12:22:12PM -0800, Mikheev, Vadim wrote:
> > > That's why an end marker must follow all valid records.
> ...
> >
> > That requires an extra out-of-sequence write.
>
> Yes, and also increase probability to corrupt already committed
> to log data.
>
> > (I'd also like to
We recently had a very satisfactory contract completed by
Vadim.
Basically Vadim has been able to reduce the amount of time
taken by a vacuum from 10-15 minutes down to under 10 seconds.
We've been running with these patches under heavy load for
about a week now without any problems except one:
On Thu, Dec 07, 2000 at 12:22:12PM -0800, Mikheev, Vadim wrote:
> > > That's why an end marker must follow all valid records.
> > That requires an extra out-of-sequence write.
> Yes, and also increase probability to corrupt already committed
> to log data.
Are you referring to the case where t
On Thursday 07 December 2000 18:35, Peter Eisentraut wrote:
>
> Ideally (IMHO) we'd build the documentation right in place when making the
> distribution tarball, i.e., broken docs, no release. I'm not sure how to
> usefully extrapolate that to the snapshot builds, though.
>
> Another thing we sh
On Thu, Dec 07, 2000 at 12:25:41PM -0800, Nathan Myers wrote:
> That requires an extra out-of-sequence write.
Ayup!
> Generally, there are no guarantees, only reasonable expectations.
I would differ, but that's irrelevant.
> A 64-bit CRC would give sufficient confidence...
This is part of wh
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Another thing we should think about is to not tar.gz the documentation
> files. That way we could create useful incremental diffs between releases
> later on. Any comments here?
I've never figured out why we do that. Since the thing is going to be
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> I would strongly suggest to use strong hashes like RIPEMD or
>> MD5 instead of CRC-32 and the like.
> Other opinions? Also, we shouldn't forget licence issues.
I agree with whoever commented that crypto hashes are silly for this
application. A 64-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 2. Why would you necessarily care to wait for shutdown? Startup I can
> see, but shutdown doesn't seem so important.
Well, maybe I'm the only one who has a script like
pg_ctl -w stop
cd ~/.../backend; make installbin
pg_ctl
> > (I'd also like to see CRCs on all the table blocks as well; is there
> > a place to put them?)
>
> Do we need it? "physical log" feature suggested by Andreas will protect
> us from non atomic data block writes.
CRCs are neccessary because of glitches, hardware failures, operating system
bugs,
> 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 logical, for
> example, that lpad might truncate on the left instead of the right,
> ie lpad('abcd', 3, 'whatever') might yield 'bcd' not 'abc'. Would
> someone check
P.S.: I would volunteer to integrate CRC routines into postgres if somebody
points me in the right direction in the source code.
Horst
The Hermit Hacker writes:
> Okay, since I haven't gotten word back on where to find the docs for v7.1,
/home/projects/pgsql/ftp/www/html/devel-corner/docs
Ideally (IMHO) we'd build the documentation right in place when making the
distribution tarball, i.e., broken docs, no release. I'm not sur
Tom Lane writes:
> Now that the postmaster takes a noticeable amount of time to shut down,
> I'm wondering if pg_ctl's default about whether or not to wait ought
> to be reversed. That is, "-w" would become the norm, and some new
> switch ("-n" maybe) would be needed if you didn't want it to wai
> > > Probably this is caused by my trial (local) change
> > > and generated an illegal log output.
> > > However it seems to mean that WAL isn't always
> > > redo-able.
> >
> > Illegal log output is like disk crash - only BAR can help.
>
> But redo-recovery after restore would also fail.
> The o
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> it still contains those for v7.0, but I just put up beta1 tarballs in the
> /pub/dev directory ... can someone take a look at these before we announce
> them to make sure they look okay?
The tarballs match what I have locally ... ship 'em ...
> > That's why an end marker must follow all valid records.
...
>
> That requires an extra out-of-sequence write.
Yes, and also increase probability to corrupt already committed
to log data.
> (I'd also like to see CRCs on all the table blocks as well; is there
> a place to put them?)
Do we
> > This may be implemented very fast (if someone points me where
> > I can find CRC func). And I could implement "physical log"
> > till next monday.
>
> I have been experimenting with CRCs for the past 6 month in
> our database for internal logging purposes. Downloaded a lot of
> hash librarie
On Thursday 07 December 2000 16:48, The Hermit Hacker wrote:
> Okay, since I haven't gotten word back on where to find the docs for v7.1,
> it still contains those for v7.0, but I just put up beta1 tarballs in the
> /pub/dev directory ... can someone take a look at these before we announce
> them
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
This may be implemented very fast (if someone points me where
I can find CRC func).
>>
>> Lifted from the PNG spec (RFC 2083):
> Thanks! What about Copyrights/licence?
Should fit fine under our regular BSD license. CRC as such is long
sinc
> recently I have downloaded a pre-beta postgresql, I found
> insert and update speed is slower then 7.0.3,
> even I turn of sync flag, it is still slow than 7.0, why?
> how can I make it faster?
Try to compare 7.0.3 & 7.1beta in multi-user environment.
Vadim
On Wed, Dec 06, 2000 at 06:53:37PM -0600, Bruce Guenter wrote:
> On Wed, Dec 06, 2000 at 11:08:00AM -0800, Nathan Myers wrote:
> > On Wed, Dec 06, 2000 at 11:49:10AM -0600, Bruce Guenter wrote:
> > >
> > > I don't know how pgsql does it, but the only safe way I know of
> > > is to include an "end
> Now that the postmaster takes a noticeable amount of time to
> shut down, I'm wondering if pg_ctl's default about whether or not
> to wait ought to be reversed. That is, "-w" would become the norm,
> and some new switch ("-n" maybe) would be needed if you didn't want
> it to wait.
>
> Comment
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> lpad and rpad never truncate, they only pad.
>>
>> 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 re
> > This may be implemented very fast (if someone points me where
> > I can find CRC func).
>
> Lifted from the PNG spec (RFC 2083):
Thanks! What about Copyrights/licence?
Vadim
On Thu, Dec 07, 2000 at 06:40:49PM +1100, Horst Herb wrote:
> > This may be implemented very fast (if someone points me where
> > I can find CRC func). And I could implement "physical log"
> > till next monday.
>
> As the logging might include large data blocks, especially now that
> we can TOAST
<[EMAIL PROTECTED]> writes:
> create function test(text) returns text AS '' LANGUAGE 'sql';
> [crashes]
OK, now it says:
regression=# create function test(text) returns text AS '' LANGUAGE 'sql';
ERROR: function declared to return text, but no SELECT provided
Thanks for the report!
Okay, since I haven't gotten word back on where to find the docs for v7.1,
it still contains those for v7.0, but I just put up beta1 tarballs in the
/pub/dev directory ... can someone take a look at these before we announce
them to make sure they look okay?
Marc G. Fournier IC
Philip Warner <[EMAIL PROTECTED]> writes:
>> Just thinking that the only way an endianness flag inside the header
>> would be useful is if we pick a magic number that's a bytewise
>> palindrome.
> You could just read the 1st, 2nd, 3rd, etc bytes and require that they be
> 'P', 'G', 'C', 'P', 'Y'
Now that the postmaster takes a noticeable amount of time to shut down,
I'm wondering if pg_ctl's default about whether or not to wait ought
to be reversed. That is, "-w" would become the norm, and some new
switch ("-n" maybe) would be needed if you didn't want it to wait.
Comments?
Thanks for responding. I will definitely kepp your comments in mind.
Cheers,
Randy
On Wed, 6 Dec 2000, Nathan Myers wrote:
> On Wed, Dec 06, 2000 at 05:09:31PM -0500, Randy Jonasz wrote:
> >
> > I know it's been a while since we last discussed a possible rewrite of
> > the C++ API but I now
Camm Maguire <[EMAIL PROTECTED]> writes:
> OK, I have 4 tables, and a view on a merge of the 4. I have a trigger
> on insert into table 3, and a trigger on insert into the view, which
> basically just takes the input data, does a few selects on the tables,
> and inserts the appropriate portions o
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.
I realize the job is not a small one nor will it be ea
Greetings, and thank you for your reply.
OK, I have 4 tables, and a view on a merge of the 4. I have a trigger
on insert into table 3, and a trigger on insert into the view, which
basically just takes the input data, does a few selects on the tables,
and inserts the appropriate portions of the d
Randy Jonasz writes:
> The following are my ideas for implementing the C++ API:
My feeling is that if you want to create a new API, don't. Instead
immitate an existing one. For you ambitions you could either take the C++
API of another RDBMS product, try to shoehorn the SQL CLI onto C++, write
> hi, yes a was talking about the first: the file format of tables. I was
> reading about diferent file organizations (structures): sequential, heal,
> ring, multi ring, etc...
afaik most of the files are sequential in nature, with some record
updates happening in the middle to mark records as "o
Could anyone please add the following to our todo list:
- make sure ECPG and postmaster use the same grammar
- make sure ECPG accepts ip numbers as host name
Also there are some more bugs in ecpg that I didn't find time to fix yet.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rh
Horst Herb wrote:
>
> > This may be implemented very fast (if someone points me where
> > I can find CRC func). And I could implement "physical log"
> > till next monday.
>
> I have been experimenting with CRCs for the past 6 month in our database for
> internal logging purposes. Downloaded a lo
Hi,
My pgsql an postgres ( version V 7.0.2 ) stop with an error when i write
the following query under pgsql :
create function test(text) returns text AS '' LANGUAGE 'sql';
ERROR under pgsql :
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend te
recently I have downloaded a pre-beta postgresql, I found insert and update speed
is slower then 7.0.3,
even I turn of sync flag, it is still slow than 7.0, why? how can I make it faster?
Regards,
XuYifeng
65 matches
Mail list logo
