> > But CRC is used in WAL records only.
>
> Oh. I thought we'd agreed that a CRC on each stored disk block would
> be a good idea as well. I take it you didn't do that.
>
> Do we want to consider doing this (and forcing another initdb)?
> Or shall we say "too late for 7.1"?
I personally was
> > No, I thought we agreed disk block CRC was way overkill. If the CRC on
> > the WAL log checks for errors that are not checked anywhere else, then
> > fine, but I thought disk CRC would just duplicate the I/O subsystem/disk
> > checks.
>
> A disk-block CRC would detect partially written block
At 21:55 11/01/01 -0500, Tom Lane wrote:
>
>Oh. I thought we'd agreed that a CRC on each stored disk block would
>be a good idea as well. I take it you didn't do that.
>
>Do we want to consider doing this (and forcing another initdb)?
>Or shall we say "too late for 7.1"?
>
I thought it was comi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Oh. I thought we'd agreed that a CRC on each stored disk block would
>> be a good idea as well. I take it you didn't do that.
> No, I thought we agreed disk block CRC was way overkill. If the CRC on
> the WAL log checks for errors that are not check
With Apache Mod Perl, Apache::DBI, stress test with apache bench (ab -n
10 -c 4) in apache error_log i've got:
[Pg7.1beta3 with standard conf files.]
..
[Fri Jan 12 07:48:58 2001] [error] DBI->connect(dbname=mydb) failed: The
Data Base System is starting up
Architectur
I announced this on Announce/General a few hours ago.
I wanted to mention that all general PostgreSQL news goes to those two
lists, on the assumption that all people are subscribed to either of
those two lists.
I don't post to hackers by default because I don't want to duplicate
these postings
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> Actually, I'd expect the CRC check to catch an all-zeroes page (if
> >> it fails to complain, then you misimplemented the CRC), so that would
> >> be the place to deal with it now.
>
> > I've used standard CRC32 implementation you pointed me to
Added to TODO.detail/drop.
[ Charset ISO-8859-1 unsupported, converting... ]
>
> I read the transcript of the alter table drop column discussion (old
> discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop,
> and I have something to add:
>
> People mentioned such ideas as a
I think all valid options should appear in the options file. Right now,
only a few are in there, I think.
> I've just been looking through the options which can and cannot be set in
> postgresql.conf and have a few points to raise.
>
> 1. There are some undocumented options which appear to re
Add to TODO:
* Enforce referential integrity for system tables
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Suppose a function using table t1 as its argument:
> > create table t1(...
> > create fuction f1(t1) returns...
> > And if I drop t1 then do pg_dump, I would got something like:
Architecture and regression.diffs:
valter.
-
valter@lora:$ uname -a:
Linux lorax 2.2.17 #3 Mon Oct 2 23:11:04 UTC 2000 i686 unknown
-
valter@lora:$ less
./src/test/regress/regression.diffs
*** ./expected/random.out Thu Jan 6 06:40:54 2000
--- ./results/random.
Some of the noise here is coming from the fact that you didn't wait for
the old postmaster to quit before you tried to start another. ("pg_ctl
stop" doesn't wait unless you say -w ... there's been some talk of
reversing that default ...)
However, it still looks like you had other problems. What
In Linux Weekly News, an Interview with Bruce (from Nov 30):
http://lwn.net/2001/features/Momjian/
:-)
Go get'em, Bruce
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
[EMAIL PROTECTED] wrote:
>
> Can PostgreSQL 7.1 store java classes or objects?
Sure it can, but not automatically. just serialize your object to a
byte array and store that String.
--
Joseph Shraibman
[EMAIL PROTECTED]
Increase signal to noise ratio. http://www.targabot.com
what happens?
valter.
[i've done vacuum analyze while query are running... vacuum stopped at some
point, then i've decided to ctrl-c, then killed postmaster]
-
postgres@lora:~$ /usr/pg71/bin/pg_ctl -D /usr/pg71/data/ stop
Smart Shutdown request at Fri Jan 1
On Thu, 11 Jan 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> >> I'm unhappy again. Bad enough we accepted a new feature during beta;
> >> now we're going to expect an absolutely virgin contrib module to work
> >> everywhere in order to pass regress tests?
>
> > Last I checked,
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> >> I'm unhappy again. Bad enough we accepted a new feature during beta;
> >> now we're going to expect an absolutely virgin contrib module to work
> >> everywhere in order to pass regress tests?
> > Last I checked, two contrib modules h
At 09:38 AM 11-01-2001 -0800, Adam Haberlach wrote:
> We do something like this with listen/notify pairs. To syncronize
>two clients, we have them each listen for the other's token string,
>send a notify, and then block on select(), checking for incoming
>notifications. When they get the n
Lamar Owen <[EMAIL PROTECTED]> writes:
>> I'm unhappy again. Bad enough we accepted a new feature during beta;
>> now we're going to expect an absolutely virgin contrib module to work
>> everywhere in order to pass regress tests?
> Last I checked, two contrib modules had to be built for regressi
Tom Lane wrote:
> Um, you do realize that a contrib module that gets used as part of the
> regress tests may as well be mainstream? At least in terms of the
> portability requirements it will have to meet?
> I'm unhappy again. Bad enough we accepted a new feature during beta;
> now we're going
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Actually, I'd expect the CRC check to catch an all-zeroes page (if
>> it fails to complain, then you misimplemented the CRC), so that would
>> be the place to deal with it now.
> I've used standard CRC32 implementation you pointed me to -:)
> But CR
I read the transcript of the alter table drop column discussion (old
discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop,
and I have something to add:
People mentioned such ideas as a hidden column and a really deleted column,
and it occurred to me that perhaps "vacuum" woul
At 01:26 PM 11-01-2001 -0500, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
>> GETLOCK "string" will lock on "string", the lock being only released at the
>> end of a transaction.
>However, the whole thing strikes me as more of an ugly kluge than a
>clean solution to the real problem.
At 09:20 AM 11-01-2001 -0800, Mikheev, Vadim wrote:
>> In contrast the current alternatives appear to be either LOCK
>> the entire table (preventing ALL inserts and selects),
>
>SHARE ROW EXCLUSIVE mode doesn't prevent selects...
Sorry, I meant all inserts and selects on the locked table. At lea
> > > Another "obvious solution" (delegating the use of the thesaurus to the
> > > client application) is also a non-solution : how do you join your data
> > > and the thesaurus data ?
> >
> > The usual way as in any relational data base: by referencing the information.
>
> That makes the client
> Um, you do realize that a contrib module that gets used as part of the
> regress tests may as well be mainstream? At least in terms of the
> portability requirements it will have to meet?
>
> I'm unhappy again. Bad enough we accepted a new feature during beta;
> now we're going to expect an a
Oleg Bartunov <[EMAIL PROTECTED]> writes:
No way, we need to load functions. there are several contributions
which depends on loaded functions. If you suggest how to do this
in general way, it would fine. To test GiST you need to define some
data structure ( in our case - RD-tr
On Thu, 11 Jan 2001, Mikheev, Vadim wrote:
> > > erk, can we get this somehow done in such a way that its part of the
> > > *standard* regression tests? so when ppl do 'make test',
> > > the GiST stuff is checked also? My worry, as with others, isn't that
> > > GiST itself is broken by the cha
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The Hermit Hacker writes:
>> ChangeLogs is meant to be more detailed then HISTORY, for those that would
>> like to see results similar to 'cvs log', but without cvs access ...
> In that case it would be more useful (and customary) to put the complete
> > erk, can we get this somehow done in such a way that its part of the
> > *standard* regression tests? so when ppl do 'make test',
> > the GiST stuff is checked also? My worry, as with others, isn't that
> > GiST itself is broken by the changes, its that *somehow* there is an
> > interaction
The Hermit Hacker writes:
> > > ChangeLogs is meant to be more detailed then HISTORY, for those that would
> > > like to see results similar to 'cvs log', but without cvs access ...
> >
> > In that case it would be more useful (and customary) to put the complete
> > ChangeLog (since the beginning
Lamar Owen <[EMAIL PROTECTED]> writes:
> There have been more changes since 7.0 than in any previous version I
> can remember as far as the build goes.
No surprise, considering the amount of work Peter E. has done on
cleaning up the configure, build, and install process --- exactly
the stuff that
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Does anyone have any objections to my downloading the tar file (doing that
> now), committing the changes and wrapping up a quick Beta4 just so that we
> have a tar ball that is testable right away?
I think we oughta review the changes at least a li
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
> On Fri, 12 Jan 2001, Oleg Bartunov wrote:
>
> > On Thu, 11 Jan 2001, The Hermit Hacker wrote:
> >
> > >
> > > just downloaded it and can't find any regression tests ... ?
> >
> > it's in the contrib-intarray.tar.gz
> > gmake, gmake install, gmake in
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
> On Thu, 11 Jan 2001, The Hermit Hacker wrote:
>
> >
> > just downloaded it and can't find any regression tests ... ?
>
> it's in the contrib-intarray.tar.gz
> gmake, gmake install, gmake installcheck
erk, can we get this somehow done in such a way that
On Fri, 12 Jan 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > ChangeLogs is meant to be more detailed then HISTORY, for those that would
> > like to see results similar to 'cvs log', but without cvs access ...
>
> In that case it would be more useful (and customary) to put the co
The Hermit Hacker writes:
> ChangeLogs is meant to be more detailed then HISTORY, for those that would
> like to see results similar to 'cvs log', but without cvs access ...
In that case it would be more useful (and customary) to put the complete
ChangeLog (since the beginning of time) into *one
Oliver Elphick writes:
> 2. The following command line options to postgres don't have an equivalent in
> postgresql.conf. Is that intentional? (I suppose it is in several cases,
> and I have left out some where it is obviously intentional.) I can't see
> why these items can't be p
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
>
> just downloaded it and can't find any regression tests ... ?
it's in the contrib-intarray.tar.gz
gmake, gmake install, gmake installcheck
Oleg
>
> On Thu, 11 Jan 2001, The Hermit Hacker wrote:
>
> > On Fri, 12 Jan 2001, Oleg Bartunov wr
On Thu, 11 Jan 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > Due to the large number of changes made since Beta1 was released, we have
> > included a Changelog file detailing all changes, that is viewable in the
> > ChangeLogs subdirectory.
>
> Shouldn't that be in the HISTORY f
Thomas Swan writes:
> When trying to run initdb I get the following error:
>
> The program '/usr/bin/postgres' needed by initdb does not belong to
> PostgreSQL version 7.1beta2. Check your installation.
If you are updating your sources via 'cvs update' you should do 'make
clean' before recompil
The Hermit Hacker writes:
> Due to the large number of changes made since Beta1 was released, we have
> included a Changelog file detailing all changes, that is viewable in the
> ChangeLogs subdirectory.
Shouldn't that be in the HISTORY file?
--
Peter Eisentraut [EMAIL PROTECTED] ht
The Hermit Hacker wrote:
> Save Lamar and the other packagers a bit of work by avoiding beta3
> packages :)
:-)
Well, working on those packages now. Fun stuff. I learn more about
more different parts of the code each new version, as the hang-ups
change from version to version. Although, thank
just downloaded it and can't find any regression tests ... ?
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
> On Fri, 12 Jan 2001, Oleg Bartunov wrote:
>
> > On Thu, 11 Jan 2001, Tom Lane wrote:
> >
> > > Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > > > I understand Tom's arguments and respect
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
> On Thu, 11 Jan 2001, Tom Lane wrote:
>
> > Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > > I understand Tom's arguments and respect his experience, so I think it's
> > > possible to put link to my page in 7.1 docs for people interested in
> > > GiST fea
On Thu, 11 Jan 2001, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > I understand Tom's arguments and respect his experience, so I think it's
> > possible to put link to my page in 7.1 docs for people interested in
> > GiST features.
>
> Bear in mind that I only have one core vote
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I understand Tom's arguments and respect his experience, so I think it's
> possible to put link to my page in 7.1 docs for people interested in
> GiST features.
Bear in mind that I only have one core vote ;-). We've already had some
private core discus
> 1. There are some undocumented options which appear to relate to WAL:
...
> Is there any text anywhere to explain what these do?
> (Point me to that or some commented code, and I'll write
> a documentation patch.)
I'll send description to you soon, thanks.
Vadim
I've just been looking through the options which can and cannot be set in
postgresql.conf and have a few points to raise.
1. There are some undocumented options which appear to relate to WAL:
NameVariableDefault Set by
checkpoint_time
Thomas Swan <[EMAIL PROTECTED]> writes:
> When trying to run initdb I get the following error:
> The program '/usr/bin/postgres' needed by initdb does not belong to
> PostgreSQL version 7.1beta2. Check your installation.
Hm. Either install failed to overwrite the existing /usr/bin/postgres,
or
I was just shown the following example:
CREATE TABLE profile (haushaltseinkommen_pm numeric(22,2));
CREATE VIEW profile_view AS
SELECT *, haushaltseinkommen_pm*12 AS haushaltseinkommen_pa FROM profile;
7.0.* pg_dump produces the following for the view:
CREATE TABLE "profile_view" (
"ha
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Has anyone any input to offer on adding an arbitrary locking feature?
>
> > Where
> > GETLOCK "string" will lock on "string", the lock being only released at the
> > end of a transaction.
>
> > Any comments, suggestions or tips would b
On Thu, 11 Jan 2001, Hannu Krosing wrote:
> I make a personal promise to spend at least 5 hours of testing new GiST
> functionality during this weekend if it is commited to 7.1 CVS.
> (ok, I do it anyhow, just that currently I'm testing it using the
> patches ;)
Hanny,
latest version is availab
On Thu, 11 Jan 2001, Mikheev, Vadim wrote:
> > The RelFileNodeEquals() bug we found on Monday proves that no one had
> > yet done enough stress-testing on 7.1 to discover that multiple
> > databases were broken. Think about that for awhile before
> > you campaign for inserting untested new featu
> This is just one instance of the generic problem that we don't enforce
> referential integrity across system catalogs. Since this issue has
Wouldn't be easy to do for views (rules) anyway - table oids are somewhere
in the body of rule, they are not just keys in column. Also, triggers are
handl
Tom Lane wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> ... the calendar says it's too late for 7.1.
>
> > Even for the _real_ bugfixes in gist.c ?
>
> If he were submitting only bugfixes, we wouldn't be having this
> discussion.
But he had very little incentive to fix bugs in the v
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Has anyone any input to offer on adding an arbitrary locking feature?
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
> Any comments, suggestions or tips would be welcome. It looks like quite
Can PostgreSQL 7.1 store java classes or objects?
> The RelFileNodeEquals() bug we found on Monday proves that no one had
> yet done enough stress-testing on 7.1 to discover that multiple
> databases were broken. Think about that for awhile before
> you campaign for inserting untested new features at this point.
> We need to focus on TESTING, p
On Thu, Jan 11, 2001 at 03:43:39PM +0800, Lincoln Yeoh wrote:
> Hi,
>
> Has anyone any input to offer on adding an arbitrary locking feature?
>
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
>
> While the lock is held, other process
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Suppose a function using table t1 as its argument:
> create table t1(...
> create fuction f1(t1) returns...
> And if I drop t1 then do pg_dump, I would got something like:
> failed sanity check, type with oid 1905168 was not found
> This is because
> In contrast the current alternatives appear to be either LOCK
> the entire table (preventing ALL inserts and selects),
SHARE ROW EXCLUSIVE mode doesn't prevent selects...
> or to create a UNIQUE constraint (forcing complete rollbacks
> and restarts in event of a collision :( ).
Hopefully, sa
> I have machines running AIX 4.1.5, 4.2.1, and 4.3.3 if you would like
> to send me your test programs.
I haven't yet actually fixed the code, but will post patches when I've
done so (assuming that a fix is possible).
- Thomas
> > How about having some #if BROKEN_TIMEZONE_DATABASE code which uses both
> > mktime() and localtime() to derive the correct time zone? That is, call
> > mktime to get a time_t, then call localtime() to get the time zone info,
> > but only on platforms which do not get a complete result from jus
> Oh, so AIX and IRIX have just one-line time zone databases? Yuck.
>
> How about having some #if BROKEN_TIMEZONE_DATABASE code which uses both
> mktime() and localtime() to derive the correct time zone? That is, call
> mktime to get a time_t, then call localtime() to get the time zone info,
> b
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> ... the calendar says it's too late for 7.1.
> Even for the _real_ bugfixes in gist.c ?
If he were submitting only bugfixes, we wouldn't be having this
discussion.
Look, I don't like postponing improvements either. But if we don't
adhere to project
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> Is UNDER being stripped out for 7.1?
It's history.
regards, tom lane
> > As I see it, the Linux results are also not 100 % correct
> in respect to dates
> > before 1970. (based on assumption that Solaris is correct)
> > <| Sat May 10 23:59:12 1947 PST
> > >| Sat May 10 23:59:12 1947 PDT
> > Was 1947 PDT or PST ? In eighter case one result is one h
Tom Lane wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > That's my vote too, specially if there will be some regression tests
> > accompanying the patches. The current (pre-patch) state of affairs with
> > GiST could probably be described as security-by-obscurity anyhow i.e.
> > "we have
> Is UNDER being stripped out for 7.1? I'm looking at documentation and don't
> want to write about it if it won't be in there.
Already gone. Check the recent archives for the discussion...
- Thomas
> FWIW, that should be to add 28*n to tm_year and subtract (365*4+1)*7
> *24*60*60*n from the time_t returned. That calculates tm_wday
> correctly.
> Also I should have been more explicit that this applies only to AIX
> and IRIX. Those return -1 from mktime(year < 1970) and do not allow
> DST ru
> As I see it, the Linux results are also not 100 % correct in respect to dates
> before 1970. (based on assumption that Solaris is correct)
> <| Sat May 10 23:59:12 1947 PST
> >| Sat May 10 23:59:12 1947 PDT
> Was 1947 PDT or PST ? In eighter case one result is one hour off, Solar
Hi
Im new here. I was wondering if anybody is working on ALTER TABLE to make it
more complete.
More specifically drop constraints
Sincerely
Per-Olof Pettersson
"Robert B. Easter" wrote:
>
> Is UNDER being stripped out for 7.1? I'm looking at documentation and don't
> want to write about it if it won't be in there.
Thats' how I understand the outcome of a discussion about 1 week ago
here:
Tom Lane wrote on Tue Jan 2 20:19:18 2001:
> Anyway, we seem
At 1/10/2001 09:10 PM, you wrote:
>Thomas Swan <[EMAIL PROTECTED]> writes:
> > Actually if it were possible to look at the values before expanding. You
> > could reorder the expression so that it was always the case that B < C,
> > then your cost would only be one comparison plus the sequential s
Hannu Krosing <[EMAIL PROTECTED]> writes:
> That's my vote too, specially if there will be some regression tests
> accompanying the patches. The current (pre-patch) state of affairs with
> GiST could probably be described as security-by-obscurity anyhow i.e.
> "we have't tried it so we think it
The Hermit Hacker wrote:
>
> Oleg ... how about a contrib/patches directory that we put this into for
> v7.1 release, so that ppl have access to it, and then we apply the patch
> first thing for part of v7.2?
And have Mandrake ship postgresql-v7.1-GiST-1mdk.rpm by default ;)
I would even vote
Is UNDER being stripped out for 7.1? I'm looking at documentation and don't
want to write about it if it won't be in there.
--
Robert B. Easter [EMAIL PROTECTED] -
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechs
Pete Forman writes:
> One workaround would be to add 4*n to tm_year and subtract (365*4+1)
> *24*60*60*n from the time_t returned. (All leap years are multiples
> of 4 in the range 1901 to 2038. If tm_wday is wanted, that will need
> to be adjusted as well.)
FWIW, that should be to add 28*n
Oleg Bartunov wrote:
>
> On Thu, 11 Jan 2001, Zeugswetter Andreas SB wrote:
>
> > I think featureism is the the most prominent argument for PostgreSQL.
Exactly! Altough it has already lost much of it ;(
> > Thus standing before a decision to eighter fix GiST bugs and risc a new
> > bug (limit
Oleg ... how about a contrib/patches directory that we put this into for
v7.1 release, so that ppl have access to it, and then we apply the patch
first thing for part of v7.2?
On Thu, 11 Jan 2001, Oleg Bartunov wrote:
> On Wed, 10 Jan 2001, Tom Lane wrote:
>
> > Oleg Bartunov <[EMAIL PROTECTED
Zeugswetter Andreas SB writes:
> Try the attachment with negative values, and tell us whether mktime
> returns anything other that -1. Do you have an idea how else we
> could determine daylight savings time ?
mktime always returns -1 for tm's that might expect to return a
negative number. In
Tatsuo Ishii wrote:
>
> Suppose a function using table t1 as its argument:
>
> create table t1(...
> create fuction f1(t1) returns...
>
> And if I drop t1 then do pg_dump, I would got something like:
>
> failed sanity check, type with oid 1905168 was not found
>
> This is because the
Suppose a function using table t1 as its argument:
create table t1(...
create fuction f1(t1) returns...
And if I drop t1 then do pg_dump, I would got something like:
failed sanity check, type with oid 1905168 was not found
This is because the type t1 does not exist anynmore. Since not
On Thu, 11 Jan 2001, Zeugswetter Andreas SB wrote:
>
> > > > we've almost totally rewrite gist.c because old code and algorithm
> > > > were not suitable for variable size keys. I think it might be
> > > > submitted into 7.1 beta source tree.
> > >
> > > Urgh. Dropping in a total rewrite when we
> > > we've almost totally rewrite gist.c because old code and algorithm
> > > were not suitable for variable size keys. I think it might be
> > > submitted into 7.1 beta source tree.
> >
> > Urgh. Dropping in a total rewrite when we're already past
> beta3 doesn't
> > strike me as good project
On Wed, 10 Jan 2001, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > we've almost totally rewrite gist.c because old code and algorithm
> > were not suitable for variable size keys. I think it might be
> > submitted into 7.1 beta source tree.
>
> Urgh. Dropping in a total rewrite
> > > > On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
> > > > info for that particular year and returns -1.
> > > > The following code then makes savings time out of the -1.
> > > > tz = (tm->tm_isdst ? (timezone - 3600) : timezone);
> > > Hmm. That description is consista
88 matches
Mail list logo
