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 lot of hash
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
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
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
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 of the
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 have
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?
[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!
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 our
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
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?
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" marker
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
"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
since in the
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 to
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 libraries, tried
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 need
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 ...
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 operation which
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 wait.
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
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
"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-bit
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
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 should
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 see CRCs on
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
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
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
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
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 someone
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-related
[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
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
* 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.
We already
* 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?
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 missed
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
* 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 to under 10
| | 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
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, there's
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's
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...
...
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 protect
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, that
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 realized I
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?
47 matches
Mail list logo
