[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 s
>> 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
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.
> lo
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 tha
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 th
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
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
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:
/home/projects/pgsql/cvsroot/CVSR
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 cour
> > 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
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 PR
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
"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 corr
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
> > 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. At restart, how will you realize that
> > that data block now contains data you d
* Nathan Myers <[EMAIL PROTECTED]> [010112 15:49] wrote:
> 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
"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
>> 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?
> Thi
> -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 wh
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 notic
> > 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
[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
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 su
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
"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 ...
> > 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
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> as you can see, there is a pg_geqo.sample, but not a pg_geqo. Should I
> rename it for it to work?
Only if you want to mess with the default GEQO parameters.
The debug messages you show don't seem to indicate that anything's
wrong, so I'm not at
[ 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
> 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 b
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 committe
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 have just finished trudging through a bunch of code and trying to make
it secure against being interrupted by die() at arbitrary instants.
However, I am under no illusion that I have succeeded in making the
world safe for SIGTERM, and you shouldn't be either. There is just way
too much code tha
On Fri, Jan 12, 2001 at 12:35:14PM -0800, Nathan Myers wrote:
> Vadim wrote:
> > What do you mean by "external agents"?
>
> External agents include RAM bit drops and noise on cables when
> blocks are (read and re-) written. Every time data is moved,
> there is a chance of an undetected error be
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.
Thanks...
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812
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
> > 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
I'm trying to retrieve a big query (bah, not so big, but with a dozen of
joins) and all I get is this:
010112.17:22:06.050 [5387] DEBUG: Rel trabajos_docentes: Pages: 3 --> 2.
010112.17:30:48.458 [5412] DEBUG: geqo_params: ga parameter file
'/var/lib/pgsql/data/pg_geqo'
does not exist or per
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. ;-)
Vadim wrote:
> Tom wrote:
> > Bruce wrote:
> > > ... 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.
> >
> > A disk-block CRC would detect partially written blocks (ie,
Lamar Owen wrote:
> Well, it's pretty dramatic to get the starred box saying that I don't
> have permissions to install to where I want to install it when I'm
> running as root.
You'd think that, as a native English speaker, I could structure a
sentence more effectively than that
Let me re
> 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 fi
Frank Joerdens <[EMAIL PROTECTED]> writes:
> I managed to rescue my data via COPY
Oh, good.
> but if this is a 7.1-related error and not
> Frank-confusedness, then it looks like an evil issue indeed.
Evil it was. The haste with which beta3 appeared should've tipped you
off that beta2 was badly
Oliver Elphick wrote:
> because I have to redo a lot of packaging.
I know how you feel.:-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
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.
> 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.
>
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
> 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. Therefo
"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
>
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.
> 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
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.
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
> [ . . . ]
> > 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
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
On Fri, Jan 12, 2001 at 06:05:09PM +0100, Frank Joerdens wrote:
[ . . . ]
> Does this make any sense to anyone?
Are questions related to 7.1 beta versions best directed to hackers or to
general?
- Frank
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 fo
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 obta
> > 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 ge
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'
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.
-announce is moderated, which means it has to be approved by myself ... I
*try* to get in nightly and approve what is in the queue, targetting
-announce items first, but sometimes time doesn't permit :(
On Fri, 12 Jan 2001, Vince Vielhaber wrote:
> On Fri, 12 Jan 2001, Bruce Momjian wrote:
>
>
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
> i
> Postgresql subtracts one minute from any times I enter into a database:
> mydb=# create table test (timeval time);
> mydb=# insert into test values ('08:30');
> mydb=# select * from test;
> --
> 08:29:00
...
> In a later message he says he's running 7.0.2 on "Trustix Secure Linux
> 1.2
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:
postgres
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
On Fri, 12 Jan 2001, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > How about adding an optional test a la "bigtest" for GiST for this
> > release?
>
> We could do that, but it seems like rather pointless effort, compared
> to just telling people "go run the tests in these cont
On Fri, 12 Jan 2001, Bruce Momjian wrote:
> > 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 tw
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 serve
> 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
> 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 debu
On Fri, 12 Jan 2001, Keith G. Murphy wrote:
> Bruce Momjian wrote:
> >
> And here I was thinking it was
>
> post''-gre-see'-quel
>
> :-)
>
It's on the website in both WAV and MP3.
Vince.
--
==
Vince Vielhaber -- KA8CSH
> 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 pr
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
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 othe
> 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 b
On Wed, 10 Jan 2001, Peter Eisentraut wrote:
> Michael J Schout writes:
>
> > We would definately beta test 7.1 beta releases on our test machines if RPMS
> > were made available. However, if rpms are not made available, its unlikely
> > that anyone around here will get time to build the sour
Tom Lane writes:
> I think it's reasonable to make the changelog available on the
> website (broken down into per-version segments, probably). I just
> have doubts about forcing people to download it whether they
> want it or not.
I agree that the complete changelog is probably too long, I'm ju
> > 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 th
Thomas Lockhart writes:
> How about adding an optional test a la "bigtest" for GiST for this
> release?
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 fig
Bruce Momjian wrote:
>
And here I was thinking it was
post''-gre-see'-quel
:-)
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
> As far as AIX and IRIX are concerned the timezones _are_ the same. No
> variation of rules from year to year is possible. You are not going
> to work out DST rules for earlier years without incorporating third
> party libraries. As I understand it PostgreSQL undertakes to
> calculate dates on
> 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
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
Thomas Lockhart writes:
> > 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 r
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 CRIT_SECTION code so that SIGTERM response
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> How about adding an optional test a la "bigtest" for GiST for this
> release?
We could do that, but it seems like rather pointless effort, compared
to just telling people "go run the tests in these contrib modules if
you want to test GIST".
I have no
On Fri, 12 Jan 2001, Thomas Lockhart wrote:
> How about adding an optional test a la "bigtest" for GiST for this
> release? It could go mainstream for 7.1.x or for 7.2 as we get more
> experience with it. This is just a suggestion and I'm sure there are
> other possibilities. I'm pretty sure we a
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 w
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
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.
> >
> > H
> 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
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 oth
> 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 t
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 diff
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 ?
Can you do it usin already compiled-in functions and modifying
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 na
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:5
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
> 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?
> > >
At 00:03 13/01/01 +1100, Philip Warner wrote:
>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 rename
1 - 100 of 109 matches
Mail list logo
