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.]
And how many simult connections you did?
..
[Fri Jan 12 07:48:58 2001] [error] DBI-connect(dbname=mydb) failed: The
Data
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 just
From: "Vadim Mikheev" To: "Valter Mazzola" , Subject: Re: [HACKERS]
Pg7.1beta3: connect failed: The DB System is starting up. Date: Fri, 12 Jan
2001 00:36:55 -0800
With Apache Mod Perl, Apache::DBI, stress test with apache bench (ab -n
10 -c 4) in apache error_log i've got:
On Thu, 11 Jan 2001, Mikheev, Vadim 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
A disk-block CRC would detect partially written blocks (ie, power drops
after disk has written M of the N sectors in a block). The disk's own
checks will NOT consider this condition a failure.
But physical log recovery will rewrite every page that was changed
after last checkpoint, thus
OK. We found an old implementation of R-Tre using GiST (Pg95)
and we'll try to implement regression test using R-Tree
it's anyway will be a good test.
Regards,
Oleg
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, Mikheev, Vadim wrote:
Um, you do
Two questions about pgaccess. I use tkl/Tk 8.2, Postgresql 7.1,
FreeBSD 4.0 .
1. I cannot view russian text in russian when I use pgaccess. I set all
the fonts in 'Preferences' to
-cronyx-helvetica-*-*-*-*-17-*-*-*-*-*-koi8-* , but don't see russian
letters in 'tables' and others windows. The
At 13:29 7/01/01 -0500, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Essentially, worst case scenario, we are going from 'broken-broken' ...
No, I don't think so. The current pg_dump code is only broken if
you've renamed a column involved in a foreign-key dependency (if I
On Fri, 12 Jan 2001, Vadim Mikheev wrote:
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.]
And how many simult connections you did?
..
[Fri Jan 12 07:48:58 2001]
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?
_If_ we want to have a tested GiST (and not the "probably works but
really has some nasty
On Fri, 12 Jan 2001, Hannu Krosing wrote:
Oleg Bartunov wrote:
OK. We found an old implementation of R-Tre using GiST (Pg95)
and we'll try to implement regression test using R-Tree
it's anyway will be a good test.
How is it different than using RD-tree for tests ?
No difference at
Here is the program. The call to localtime(t_ago) is redundant and
hence the adjustment of t_ago can be skipped. It is in this program
as a sanity check.
As it stands, this program assumes that the input and resulting date
are in the usual UNIX range of [1901, 2038]. I presume that there
Oleg Bartunov [EMAIL PROTECTED] writes:
What's wrong with
warning message if GiST test not passed ?
You're being *way* too optimistic. An output discrepancy in a test of
GIST we could live with. But think about other scenarios:
1. GIST test coredumps on some platforms. This corrupts other
IMHO, giving out real test results, even negative, instead of leaving
things untested would be a honest thing to do.
afaict there are several concerns or decisions, and we've made a few
already:
Re: gist.c patches...
1) Oleg and Hannu are committed to testing the repaired GiST as soon as
it
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Fri, 12 Jan 2001, Hannu Krosing wrote:
Oleg Bartunov wrote:
OK. We found an old implementation of R-Tre using GiST (Pg95)
and we'll try to implement regression test using R-Tree
it's anyway will be a good test.
How is it different
On Fri, 12 Jan 2001, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
What's wrong with
warning message if GiST test not passed ?
You're being *way* too optimistic. An output discrepancy in a test of
GIST we could live with. But think about other scenarios:
1. GIST test
Bruce Momjian wrote:
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
Pete Forman [EMAIL PROTECTED] writes:
Thinking about that a bit more, I think that tm_isdst should not be
written into.
IIRC, setting isdst to -1 was necessary to get the right behavior across
DST boundaries on more-mainstream systems. I do not think it's
acceptable to do worse on systems
Pete Forman [EMAIL PROTECTED] writes:
Thinking about that a bit more, I think that tm_isdst should not be
written into.
IIRC, setting isdst to -1 was necessary to get the right
behavior across
DST boundaries on more-mainstream systems. I do not think it's
acceptable to do worse on
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Yes, the annoyance is, that localtime works for dates before 1970
but mktime doesn't. Best would probably be to assume no DST before
1970 on AIX and IRIX.
That seems like a reasonable answer to me, especially since we have
other platforms that
Yes, the annoyance is, that localtime works for dates before 1970
but mktime doesn't. Best would probably be to assume no DST before
1970 on AIX and IRIX.
That seems like a reasonable answer to me, especially since we have
other platforms that behave that way. How can we do this ---
Lamar Owen writes:
Does the python build stuff use DESTDIR these days?
It does not. You'd have to delve into the internals of the
Python-provided makefiles. I might just have to do that, but if you want
to look then let me know because this should get fixed.
The perl stuff needs some other
Peter Eisentraut [EMAIL PROTECTED] writes:
I agree that the complete changelog is probably too long, I'm just against
the per-version segmenting. Changelogs are usually used (well, by me) to
get an overview when and how segments of code were worked on. The primary
key here is not what
An optional test is like no test at all. No one runs optional tests. If
the test is supposed to work then it should be mainstream. If the test
might not work then you better go back and figure out what you're testing.
If the test might not *compile* (which is probably the more severe
At this point my vote is to leave the GIST test in contrib for 7.1.
Anyone who actually cares about GIST (to be blunt: all three of you)
can run it as a separate step. I don't want it in the standard regress
tests until 7.2, when we will have a reasonable amount of time to test
and debug
Agreed ... now let's move onto more important things, cause we've spent
much too long on this as it is ...
Namely, should we bundle up a beta4 this weeekend, so that the GiST
changes are in place for further testing, or hold off for ... ?
I would hold off. GIST people can download the
Speaking of which..
rpm -ivh ftp://ftp.postgresql/pub/whatever/postgresql-\*.rpm
Is there a clearing house for packages? I have made some for OpenBSD
(www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to
get the rpm or deb files. Should there be a folder on the ftp server
On Fri, 12 Jan 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Namely, should we bundle up a beta4 this weeekend, so that the GiST
changes are in place for further testing, or hold off for ... ?
First I'd like to finish a couple of open items I have, like fixing
the
First I tried to dump out a database like:
frank@limedes:~ pg_dump mpi dump.mpi
getTables(): relation 'institute': 6 Triggers were expected, but got 0
The database mpi does contain a table 'institute' and a few foreign key constraints.
Then
I tried to dump another database, as in:
Tom Lane writes:
Pete Forman [EMAIL PROTECTED] writes:
Thinking about that a bit more, I think that tm_isdst should not
be written into.
IIRC, setting isdst to -1 was necessary to get the right behavior
across DST boundaries on more-mainstream systems. I do not think
it's
bpalmer writes:
Is there a clearing house for packages? I have made some for OpenBSD
(www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to
get the rpm or deb files. Should there be a folder on the ftp server for
packages for the betas?
The RPMs are on the FTP server.
Pete Forman [EMAIL PROTECTED] writes:
It is fairly arbitrary what the answer to this question is: if six
months is subtracted from a to give b, should a.local.hour =
b.local.hour or should a.utc.hour = b.utc.hour? If you want the
former then set tm_isdst = -1 before calling mktime.
It's not
Is there a clearing house for packages? I have made some for OpenBSD
(www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to
get the rpm or deb files. Should there be a folder on the ftp server for
packages for the betas?
The RPMs are on the FTP server.
In general I
bpalmer wrote:
Is there a clearing house for packages? I have made some for OpenBSD
(www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to
get the rpm or deb files. Should there be a folder on the ftp server for
packages for the betas?
Typically, deb files are
bpalmer writes:
This traffic does not seem necessary for the list, but here are my
thoughts.
I think it is.
I don't begin to disagree with this for a second. I know that there are a
lot of RPM users out there that would like the RPM. I'm aware that there
would be a lesser demand for
Frank Joerdens wrote:
[ . . . ]
Restarting the server didn't make a difference.
I upgraded to beta3 just now and the problem persists. I didn't do an initdb obviously
cuz
I cannot save the data via pg_dump. Beta3 will read beta2 data OK (I guess this means
that
an initdb is not required when
[ . . . ]
Restarting the server didn't make a difference.
I upgraded to beta3 just now and the problem persists. I
didn't do an initdb obviously cuz
I cannot save the data via pg_dump. Beta3 will read beta2
data OK (I guess this means that
an initdb is not required when going from
Frank Joerdens [EMAIL PROTECTED] writes:
Then I had a look via psql at intranet and it turns out that it shows
up as the database mpi mangled into the database intranet,
contentwise; i.e. it doesn't only show the tables that are in intranet
but also those that belong to mpi?
I think you've
Frank Joerdens [EMAIL PROTECTED] writes:
Are questions related to 7.1 beta versions best directed to hackers or to
general?
hackers is the proper place for discussing any unreleased version, I'd
say. Or you can file a bug report on pgsql-bugs, if that seems more
appropriate.
You should probably write off your databases as toast ... update to
beta3 and do an initdb. Sorry about that ...
And try to reproduce bug.
Sorry.
Vadim
On Fri, Jan 12, 2001 at 10:00:40AM -0600, Keith G. Murphy wrote:
And here I was thinking it was
post''-gre-see'-quel
I pronounce it "postgres". (I suspect that everybody else does
too, whenever possible.) In English there's no problem with the
spelling differing from the pronunciation.
"Mikheev, Vadim" wrote:
[ . . . ]
Restarting the server didn't make a difference.
I upgraded to beta3 just now and the problem persists. I
didn't do an initdb obviously cuz
I cannot save the data via pg_dump. Beta3 will read beta2
data OK (I guess this means that
an initdb is
ERROR: Cannot insert a duplicate key into unique index
pg_class_oid_index
-- start log
--
Which makes me pause . . . are OIDs unique per database or
per PostgreSQL installation? I think per database. Therefore
Bruce Momjian wrote:
Lamar Owen wrote:
Now that I look through my inbox, I don't see the post anywhere.
Hmmm Not in trash either, which I didn't empty yesterday.
That is strange. I saw it on those lists.
I've been seeing some odd e-mail propagation lately.
I want to say I
Bruce Momjian wrote:
Lamar Owen wrote:
Now that I look through my inbox, I don't see the post anywhere.
Hmmm Not in trash either, which I didn't empty yesterday.
That is strange. I saw it on those lists.
I've been seeing some odd e-mail propagation lately.
I want to
Peter Eisentraut wrote:
Lamar Owen writes:
Does the python build stuff use DESTDIR these days?
It does not. You'd have to delve into the internals of the
Python-provided makefiles. I might just have to do that, but if you want
to look then let me know because this should get fixed.
Evil it was. The haste with which beta3 appeared should've tipped you
off that beta2 was badly broken :-(. What's puzzling us, though, is
that this bug was in the WAL code from day one, and no one noticed it
Just for accuracy - this bug is not related to WAL anyhow.
This bug was in new file
But physical log recovery will rewrite every page that was changed
after last checkpoint, thus this is not an issue anymore.
No. That assumes that when the drive _says_ the block is written,
it is really on the disk. That is not true for IDE drives. It is
true for SCSI drives only
On Fri, Jan 12, 2001 at 01:07:56PM -0800, Mikheev, Vadim wrote:
But physical log recovery will rewrite every page that was changed
after last checkpoint, thus this is not an issue anymore.
No. That assumes that when the drive _says_ the block is written,
it is really on the disk.
Well there is cvs2cl and there is a utility I use:
pgsql/src/tools/pgcvslog
Has anyone ever thought of asking the FreeBSD folks for
their CVS COmmit message generator? They generate ONE message
with more info in it for multi-directory commits than we
do with ours.
I'm referring to the actual commit messages.
It would be in the CVS server config
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 12, 2001 4:03 PM
To: Larry Rosenman
Cc: PostgreSQL Hackers List
Subject: Re: [HACKERS] CVS updates on
I think we'd be lots better off to abandon the notion that we can exit
directly from the SIGTERM interrupt handler, and instead treat SIGTERM
the same way we treat QueryCancel: set a flag that is inspected at
specific places where we know we are in a good state.
Comments?
This will be
[ Charset ISO-8859-1 unsupported, converting... ]
I'm referring to the actual commit messages.
It would be in the CVS server config
Oh, yes, I understand now.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+
You know - this is *core* assumption. If drive lies about this then
*nothing* will help you. Do you remember core rule of WAL?
"Changes must be logged *before* changed data pages written".
If this rule will be broken then data files will be inconsistent
after crash recovery and you will
"Larry Rosenman" [EMAIL PROTECTED] writes:
I'm referring to the actual commit messages.
It *would* be awfully nice if the pgsql-committers traffic were one
message per commit, instead of one per directory touched per commit.
This has been suggested before, but nothing got done ...
On Fri, Jan 12, 2001 at 02:16:07PM -0800, Mikheev, Vadim wrote:
You know - this is *core* assumption. If drive lies about this then
*nothing* will help you. Do you remember core rule of WAL?
"Changes must be logged *before* changed data pages written".
If this rule will be broken then
Tom Lane [EMAIL PROTECTED] writes:
"Larry Rosenman" [EMAIL PROTECTED] writes:
I'm referring to the actual commit messages.
It *would* be awfully nice if the pgsql-committers traffic were one
message per commit, instead of one per directory touched per commit.
This has been suggested
[EMAIL PROTECTED] (Nathan Myers) writes:
"Changes must be logged *before* changed data pages written".
If this rule will be broken then data files will be inconsistent
after crash recovery and you will not notice this, w/wo CRC in
data blocks.
You can include the data blocks' CRCs in the
It wouldn't help you recover, but you would be able to report that
you cannot recover.
How? The scenario Vadim is pointing out is where the disk
drive writes a changed data block in advance of the WAL log entry
describing the change. Then power drops and the WAL entry never gets
made.
On Fri, Jan 12, 2001 at 06:06:21PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] (Nathan Myers) writes:
"Changes must be logged *before* changed data pages written".
If this rule will be broken then data files will be inconsistent
after crash recovery and you will not notice this, w/wo CRC in
-Original Message-
From: Mikheev, Vadim
I think we'd be lots better off to abandon the notion that we can exit
directly from the SIGTERM interrupt handler, and instead treat SIGTERM
the same way we treat QueryCancel: set a flag that is inspected at
specific places where we
I think we'd be lots better off to abandon the notion that we can exit
directly from the SIGTERM interrupt handler, and instead treat SIGTERM
the same way we treat QueryCancel: set a flag that is inspected at
specific places where we know we are in a good state.
Comments?
This will be
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
Hmm, CancelQuery isn't so urgent an operation currently.
For example, VACUUM checks QueryCancel flag only
once per table.
Right, we'll need to check in more places. See my just-posted proposal.
Checking at any spinlock grab should ensure that we
El Mi 10 Ene 2001 20:55, Alfonso Peniche escribi:
Existe un archivo llamado postmaster.init en el directorio de postgres, en
ese directorio le especificas si quieres que use o no los logs. Ya
revisaste ese archivo?
No existe tal archivo, pero ya lo sulocione.
Gracias de todas formas. ;-)
--
I keep meaning to work with Alfred on this ... just keeps getting
backburnered :(
Let me take a look at her this weekend ...
On Fri, 12 Jan 2001, Larry Rosenman wrote:
Has anyone ever thought of asking the FreeBSD folks for
their CVS COmmit message generator? They generate ONE message
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If log record was not really flushed on disk in 3. but on-disk image of
index block was updated in 4. and system crashed after this then after
restart recovery you'll have unlawful index tuple pointing to where?
Who knows! No guarantee that
On Fri, Jan 12, 2001 at 04:10:36PM -0800, Alfred Perlstein wrote:
Nathan Myers [EMAIL PROTECTED] [010112 15:49] wrote:
Obviously it's better to configure the disk so that it doesn't
lie about what's been written.
I thought WAL+fsync wasn't supposed to allow this to happen?
It's an OS
Done ... just tried adding white space to three files, in three
directories, and it seems to go through as one commit ...
let's see what happens next time Tom makes a big change :)
On 12 Jan 2001, Ian Lance Taylor wrote:
Tom Lane [EMAIL PROTECTED] writes:
"Larry Rosenman" [EMAIL
If log record was not really flushed on disk in 3. but
on-disk image of index block was updated in 4. and system
crashed after this then after restart recovery you'll have
unlawful index tuple pointing to where? Who knows!
No guarantee that corresponding heap tuple was flushed on
Nathan Myers wrote:
It wouldn't help you recover, but you would be able to report that
you cannot recover.
While this could help decting hardware problems, you still won't be able
to detect some (many) memory errors because the CRC will be calculated
on the already corrupted data.
Of course
The Hermit Hacker writes:
Done ... just tried adding white space to three files, in three
directories, and it seems to go through as one commit ...
let's see what happens next time Tom makes a big change :)
When Peter makes a small change, this happens:
Peter Eisentraut [EMAIL PROTECTED] writes:
The Hermit Hacker writes:
Done ... just tried adding white space to three files, in three
directories, and it seems to go through as one commit ...
let's see what happens next time Tom makes a big change :)
When Peter makes a small change,
Ian Lance Taylor writes:
/home/projects/pgsql/cvsroot/CVSROOT/log_accum: not found
Odd that it would work once.
Is log_accum listed in the CVSROOT/checkoutlist file?
commit_prep Won't be able to do mail logging.
log_accum Won't be able to do mail logging.
What files are in
Lamar Owen writes:
It's pretty dramatic to get the 'You don't have permissions to install'
message from the perl 'make install' when I am performing the build (and
the make install) as root. Particularly when 7.0's perl 'make install'
worked semi-properly. I say semi-properly because the
okay, got all of this fixed up ... I missed the 'checkoutlist' file, and
the mail program was pointing at the wrong place :(
testing now ...
On Sat, 13 Jan 2001, Peter Eisentraut wrote:
Ian Lance Taylor writes:
/home/projects/pgsql/cvsroot/CVSROOT/log_accum: not found
Odd that it
Peter Eisentraut [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
/home/projects/pgsql/cvsroot/CVSROOT/log_accum: not found
Odd that it would work once.
Is log_accum listed in the CVSROOT/checkoutlist file?
commit_prep Won't be able to do mail logging.
log_accum
AFAICS, disk-block CRCs do not guard against mishaps involving intended
writes. They will help guard against data corruption that might creep
in due to outside factors, however.
Right.
Given that we seem to have agreed on that, I withdraw my complaint about
disk-block-CRC not being in
[EMAIL PROTECTED] (Anatoly K. Lasareff) writes:
Two questions about pgaccess. I use tkl/Tk 8.2, Postgresql 7.1,
FreeBSD 4.0 .
1. I cannot view russian text in russian when I use pgaccess. I set all
the fonts in 'Preferences' to
-cronyx-helvetica-*-*-*-*-17-*-*-*-*-*-koi8-* , but don't see
78 matches
Mail list logo
