AW: [HACKERS] Re: tinterval - operator problems on AIX
The time zone is now evaluated in the time zone of the result, rather than the input, using system support routines from libc. Ok, I have the answer. On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone info for that particular year and returns -1. From man page: The mktime subroutine returns the specified time in seconds encoded as a value of type time_t. If the time cannot be represented, the function returns the value (time_t)-1. The following code then makes savings time out of the -1. tz = (tm-tm_isdst ? (timezone - 3600) : timezone); What now ? Andreas
[HACKERS] GiST for 7.1 !!
Hi, 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. We have fixed several bugs and memory leaks. Version for 7.0.3 is also available. Sampe application for contrib area - implementation RD-Tree and index support for int arrays I'll submit later (Need some documentation). Regards, Oleg Here is a README.gist New version of gist.c for PostgreSQL 7.1 New feature: 1. Support of variable size keys - new algorithm of insertion to tree (GLI - gist layrered insertion). Previous algorithm was implemented as described in paper by Joseph M. Hellerstein et.al "Generalized Search Trees for Database Systems". This (old) algorithm was not suitable for variable size keys and could be not effective ( walking up-down ) in case of multiple levels split Bug fixed: 1. fixed bug in gistPageAddItem - key values were written to disk uncompressed. This caused failure if decompression function does real job. 2. NULLs handling - we keep NULLs in tree. Right way is to remove them, but we don't know how to inform vacuum about index statistics. This is just cosmetic warning message (like in case with R-Tree), but I'm not sure how to recognize real problem if we remove NULLs and suppress this warning as Tom suggested. 3. various memory leaks All our tests and Gene Selcov's regression tests passed ok. We have version also for 7.0.3 Sample application which utilize RD-Tree for index support of int arrays is in contrib/intarray (will be submitted separately). TODO: 1. Description of GLI algorithm 2. regression test for GiST (based on RD-Tree) This work was done by Teodor Sigaev ([EMAIL PROTECTED]) and Oleg Bartunov ([EMAIL PROTECTED]). On Sun, 17 Dec 2000, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I checked 7.1 feature list and didn't find any mention about GiST but there are changes in GiST code. Who is a maintainer of GiST code ? You are ;-). If you expect to find someone who understands GiST better than you, you're probably out of luck. I recall having made a number of changes that applied to all of the index access methods, including GiST --- but I was just changing similar code in all the methods. I don't claim to know anything about GiST in particular. regards, tom lane Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 gist-7.1.tar.gz
[HACKERS]
Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
[HACKERS] RD-Tree, index support for int array (contrib-intarray)
Hi,
I attached archive with contrib-intarray. Please submit it into
7.1 beta source tree.
Here is README
--
This is an implementation of RD-tree data structure using GiST interface
of PostgreSQL. It has built-in lossy compression - must be declared
in index creation - with (islossy). Current implementation has index support
for one-dimensional array of int4's.
All works was done by Teodor Sigaev ([EMAIL PROTECTED]) and Oleg Bartunov
([EMAIL PROTECTED]).
INSTALLATION:
gmake
gmake install
-- load functions
psql database _int.sql
EXAMPLE USAGE:
create table message (mid int not null,sections int[]);
create table message_section_map (mid int not null,sid int not null);
-- create indices
CREATE unique index message_key on message ( mid );
CREATE unique index message_section_map_key2 on message_section_map (sid, mid );
CREATE INDEX message_rdtree_idx on message using gist ( sections ) with ( islossy);
-- select some messages with section in 1 OR 2 - OVERLAP operator
select message.mid from message where message.sections '{1,2}';
-- select messages contains in sections 1 AND 2 - CONTAINS operator
select message.mid from message where message.sections @ '{1,2}';
-- the same, CONTAINED operator
select message.mid from message where '{1,2}' ~ message.sections;
TEST:
subdirectory test contains test suite.
cd ./test
1. createdb TEST
2. psql TEST ../_int.sql
3. ./create_test.pl | psql TEST
4. ./bench.pl - perl script to benchmark queries, supports OR, AND queries
with/without RD-Tree. Run script without arguments to
see availbale options.
a)test without RD-Tree (OR)
./bench.pl -d TEST -s 1,2 -v
b)test with RD-Tree
./bench.pl -d TEST -s 1,2 -v -r
BENCHMARKS:
Size of table message: 20
Size of table message_section_map: 268538
Distribution of messages by sections:
section 0: 73899 messages
section 1: 16298 messages
section 50: 1241 messages
section 99: 705 messages
old - without RD-Tree support,
new - with RD-Tree
+--+---++
|Search set|OR, time in sec|AND, time in sec|
| +---+---++---+
| | old | new | old | new |
+--+---+---++---+
| 1| 1.427| 0.215| -| -|
+--+---+---++---+
|99| 1.029| 0.018| -| -|
+--+---+---++---+
| 1,2| 1.829| 0.334| 5.654| 0.042|
+--+---+---++---+
| 1,2,50,60| 2.057| 0.359| 5.044| 0.007|
+--+---+---++---+
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
contrib-intarray.tar.gz
Re: AW: [HACKERS] Re: tinterval - operator problems on AIX
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 consistant with what I see in the Linux man page. So I should check for (tm-tm_isdst 0) rather than checking for non-zero? Would you like to test that on your machine? I'll try it here, and if successful will consider this a bug report and a necessary fix for 7.1. It is interesting that this is the only place in all of our code which tickles this bug; afaik this line of code appears in other places too. Can you find a case where the current code fails when you are not doing arithmetic? Perhaps there are some more tests we could include in the regression tests?? It is also interesting that afaik AIX is the only machine exhibiting this problem. The before-1970 range of dates is known to occur in some use cases, and having *something* in the timezone database isn't that difficult :/ - Thomas
Re: AW: [HACKERS] Re: tinterval - operator problems on AIX
Thomas Lockhart writes: 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 consistant with what I see in the Linux man page. So I should check for (tm-tm_isdst 0) rather than checking for non-zero? Would you like to test that on your machine? I'll try it here, and if successful will consider this a bug report and a necessary fix for 7.1. 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. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
[HACKERS] Re: BETWEEN [SYMMETRIC | ASYMMETRIC]
At 1/9/2001 10:29 PM, Tom Lane wrote: Thomas Swan [EMAIL PROTECTED] writes: Shouldn't be much of problem... where would I start to look... :) Well, the Right Way To Do It would be to invent a new expression node type that implements both kinds of BETWEEN. Right now, the parser expands A BETWEEN B AND C into "A = B AND A = C", which is perfectly correct according to the letter of the spec, but it implies evaluating the subexpression A twice, which sucks. Besides which, this doesn't 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 scan. readily generalize to the SYMMETRIC case. I'd make a new expr node type with three subexpressions and a SYMMETRIC bool flag. If you chase down all the places where CaseExpr nodes are processed, and add a BetweenExpr case in parallel, you'll have it made. regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen writes: However, there are some hard-coded paths left in the build, and the perl client is being difficult, The Perl and Python clients use their own build system. Not sure how to handle it. and odbcinst is going to the REAL /usr/etc instead of $RPM_BUILD_ROOT/etc Works here. Hmm, are you using 'make install DESTDIR=/random/place'? Given that it's not documented it's unlikely that you are. But do start using it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen writes: Hmm, are you using 'make install DESTDIR=/random/place'? Given that it's not documented it's unlikely that you are. But do start using it. Enlighten me. DESTDIR does? It installs files at a different place than where they will eventually reside. E.g., if your --prefix is /usr/local and DESTDIR=/var/tmp/foo then the files will end up in /var/tmp/foo/usr/local. This is exactly for package management type applications. Currently, my install lines look like: make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src install make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src/interface s/perl5 install Then it's not surprising that things don't work since neither POSTGRESDIR nor PREFIX are used anywhere in PostgreSQL makefiles. So, I would put something like: make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr DESTDIR=/usr -C src install ??? ./configure --prefix=/usr --sysconfdir=/etc \ --docdir=/usr/share/doc/postgresql-'$(VERSION)' \ --mandir=/usr/share/man \ ...other options... make all make install DESTDIR=$RPM_BUILD_ROOT -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Peter Eisentraut wrote:
Lamar Owen writes:
Enlighten me. DESTDIR does?
It installs files at a different place than where they will eventually
reside. E.g., if your --prefix is /usr/local and DESTDIR=/var/tmp/foo
then the files will end up in /var/tmp/foo/usr/local. This is exactly for
package management type applications.
Good.
Then it's not surprising that things don't work since neither POSTGRESDIR
nor PREFIX are used anywhere in PostgreSQL makefiles.
Had they been prior to 7.1?
./configure --prefix=/usr --sysconfdir=/etc \
--docdir=/usr/share/doc/postgresql-'$(VERSION)' \
--mandir=/usr/share/man \
...other options...
Already doing all of that, except --sysconfdir and friends. It's more
complicated than the above:
./configure --prefic=/usr --sysconfdir=/etc \
--docdir=%{_docdir}/%{name}/%{version} \
--mandir=%{_mandir} \
to take into account the differing distributions' differing ideas of
where things ought to be put.
make all
make install DESTDIR=$RPM_BUILD_ROOT
Much simpler. Will get back as soon as I get time to run a build (staff
meeting here in ten minutes.).
Does the python build stuff use DESTDIR these days? The perl stuff
needs some other things, unfortunately. I need to look in the CPAN RPM
spec's to get examples of how to do this portably without major
connarptions.
I knew you had changed something along those lines; I even remember a
message listing the switches necessary; but I could not find it in my
message archive.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
[HACKERS] psql -l bug
Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery)
[HACKERS] Re: psql -l bug
Sorry to folowup on my own post Problem solved: real and test db don't run on the same machine. On the test one, postgres had the same uid as pg_shadow.usesysid for the user... Sorry to have bothered you all. Reagrds On Wed, 10 Jan 2001, Olivier PRENANT wrote: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery)
Re: [HACKERS] psql -l bug
* Olivier PRENANT [EMAIL PROTECTED] [010110 12:47]: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm also on UW711, and do *NOT* see the bug: Password: List of databases Database | Owner | Encoding ---+--+--- ler | ler | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows) Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] Re: psql -l bug
On Wed, 10 Jan 2001, Olivier PRENANT wrote: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. For more info (don't think it's a bug) I see two templates db too. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm looking forword to seeing the release of 7.1. System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] psql -l bug
* Olivier PRENANT [EMAIL PROTECTED] [010110 15:03]: As I said previously.. I apologies, this was all my fault. Please discard... Oh my, When will we have an RC??? SOON. I'm running the BETA, LER On Wed, 10 Jan 2001, Larry Rosenman wrote: * Olivier PRENANT [EMAIL PROTECTED] [010110 12:47]: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm also on UW711, and do *NOT* see the bug: Password: List of databases Database | Owner | Encoding ---+--+--- ler | ler | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows) Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] psql -l bug
As I said previously.. I apologies, this was all my fault. Please discard... Oh my, When will we have an RC??? On Wed, 10 Jan 2001, Larry Rosenman wrote: * Olivier PRENANT [EMAIL PROTECTED] [010110 12:47]: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm also on UW711, and do *NOT* see the bug: Password: List of databases Database | Owner | Encoding ---+--+--- ler | ler | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows) Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery)
Re: [HACKERS] still no log
"Martin A. Marques" wrote: Sorry for the insistence, but after looking and looking again, I can't find out why the postgres logs are empty. The postgres database is up and working great, but nothing is getting logged. I'm on a RedHat Linux (6.0 with lot of upgrades) postgres 7.0.3 from rpm (downoaded from the postgres ftp server) Any ideas? If postmaster is started with -S, nothing gets logged. Is that your problem? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Be patient therefore, brethren, unto the coming of the Lord...Be patient; strengthen your hearts, for the coming of the Lord draweth nigh." James 5:7,8
[HACKERS] Interesting CERT advisory
FYI, CERT Advisory CA-2001-01 Interbase Server Contains Compiled-in Back Door Account Original release date: January 10, 2001 Last revised: -- Source: CERT/CC A complete revision history is at the end of this file. Systems Affected * Borland/Inprise Interbase 4.x and 5.x * Open source Interbase 6.0 and 6.01 * Open source Firebird 0.9-3 and earlier Overview Interbase is an open source database package that had previously been distributed in a closed source fashion by Borland/Inprise. Both the open and closed source verisions of the Interbase server contain a compiled-in back door account with a known password. I. Description Interbase is an open source database package that is distributed by Borland/Inprise at http://www.borland.com/interbase/ and on SourceForge. The Firebird Project, an alternate Interbase package, is also distributed on SourceForge. The Interbase server for both distributions contains a compiled-in back door account with a fixed, easily located plaintext password. The password and account are contained in source code and binaries previously made available at the following sites: http://www.borland.com/interbase/ http://sourceforge.net/projects/interbase http://sourceforge.net/projects/firebird http://firebird.sourceforge.net http://www.ibphoenix.com http://www.interbase2000.com This back door allows any local user or remote user able to access port 3050/tcp [gds_db] to manipulate any database object on the system. This includes the ability to install trapdoors or other trojan horse software in the form of stored procedures. In addition, if the database software is running with root privileges, then any file on the server's file system can be overwritten, possibly leading to execution of arbitrary commands as root. This vulnerability was not introduced by unauthorized modifications to the original vendor's source. It was introduced by maintainers of the code within Borland. The back door account password cannot be changed using normal operational commands, nor can the account be deleted from existing vulnerable servers [see References]. This vulnerability has been assigned the identifier CAN-2001-0008 by the Common Vulnerabilities and Exposures (CVE) group: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0008 The CERT/CC has not received reports of this back door being exploited at the current time. We do recommend, however, that all affected sites and redistributors of Interbase products or services follow the recommendations suggested in Section III, as soon as possible due to the seriousness of this issue. II. Impact Any local user or remote user able to access port 3050/tcp [gds_db] can manipulate any database object on the system. This includes the ability to install trapdoors or other trojan horse software in the form of stored procedures. In addition, if the database software is running with root privileges, then any file on the server's file system can be overwritten, possibly leading to execution of arbitrary commands as root. III. Solution Apply a vendor-supplied patch Both Borland and The Firebird Project on SourceForge have published fixes for this problem. Appendix A contains information provided by vendors supplying these fixes. We will update the appendix as we receive more information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Users who are more comfortable making their own changes in source code may find the new code available on SourceForge useful as well: http://sourceforge.net/projects/interbase http://sourceforge.net/projects/firebird Block access to port 3050/tcp This will not, however, prevent local users or users within a firewall's adminstrative boundary from accessing the back door account. In addition, the port the Interbase server listens on may be changed dynamically at startup. Appendix A. Vendor Information Borland Please see: http://www.borland.com/interbase/ IBPhoenix The Firebird project uncovered serious security problems with InterBase. The problems are fixed in Firebird build 0.9.4 for all platforms. If you are running either InterBase V6 or Firebird 0.9.3, you should upgrade to Firebird 0.9.4. These security holes affect all version of InterBase shipped since 1994, on all platforms. For those who can not upgrade, Jim Starkey developed a patch program that will correct the more serious problems in any version of InterBase on any platform. IBPhoenix chose to release the program without charge, given the nature of the problem and our relationship to the community. At the moment, name service is not set up to the machine that is
Re: AW: AW: [HACKERS] Re: tinterval - operator problems on AIX
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 consistant with what I see in the Linux man page. So I should check for (tm-tm_isdst 0) rather than checking for non-zero? It is obviously not possible to determine tm_isdst with mktime for a negative time_t. Thus with above fix PST works, but PDT is then busted :-( Obvious to AIX only? My conclusion is that the AIX timezone database is damaged or missing for pre-1970 dates, but that other systems bothered to get it at least somewhat right. Is there another issue here that I'm missing? localtime does convert a negative time_t correctly including dst. Is there another way to determine tm_isdst ? Yes. Replace AIX with Linux or something else, then recompile Postgres ;) Seriously, not that I know of. The problem is that there is no API for accessing time zone info other than the localtime()/mktime() kinds of calls, so we are stuck using that (or stuck repackaging something like zinc into Postgres directly, which afaik is not anything we would be interested in doing). - Thomas
Re: [HACKERS] Interesting CERT advisory
Both the open and closed source versions of the Interbase server contain a compiled-in back door account with a known password. Darn. We are probably too late in beta to consider adding this feature; we'll have to play catchup in 7.2 ;) - Thomas
Re: [HACKERS] global/pg_database ?
Patrick Welche [EMAIL PROTECTED] writes: Posting again as even though I receive mail from hackers I am apparently not a member (registered correctly as [EMAIL PROTECTED] - from will say [EMAIL PROTECTED] - setting reply-to to [EMAIL PROTECTED] used to get around it..) Easiest answer might be to subscribe again under that address and then set it to 'nomail', or whatever the option is to turn off actually receiving mail from the list (yes, there is one...). psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory and it's true.. % ls /usr/local/pgsql/data/global 1260126112621264126917127 17130 pg_control source from Jan 3 15:59 GMT That is the correct contents of $PGDATA/global in current sources --- pg_database's file is now named by its OID, ie 1262, not by its relname. Not sure why you are getting such a message, but it strikes me that you may have a corrupted set of sources, ie, some out-of-date files. Have you tried doing a fresh cvs checkout and build from scratch? regards, tom lane
[HACKERS] Re: ERROR: cannot find attribute 10 of???
On Wed, 3 Jan 2001 21:07:22 +0100, ineck [EMAIL PROTECTED] wrote: Anyone can help with that one? Warning: PostgresSQL query failed: ERROR: cannot find attribute 10 of relation pg_am in [..] Warning: 0 is not a PostgresSQL result index in Sounds like PHP to me. Usually when you get a "0 is not a ..." it means that you failed to set the variable used in your function call. ie. you might have pg_fetch_array( $result, 10 ) but had pg_exec( $database, $query ); instead of $result = pg_exec( $database, $query ); Thanks in advice ineck Lee Harr [EMAIL PROTECTED]
Re: [HACKERS] A post-7.1 wish-list.
Horst Herb wrote: On Sunday 07 January 2001 21:31, Emmanuel Charpentier wrote: [ ... ] Excuse me, but where has MS Access competence? It is a pretty useless data lottery with an admittedly very capable easy user interface. The odds of data corruption can't possibly be higher with any other system (I used to develop hospital information systems prototyping with Access). Competence : in this context, the ability to define a correct data structure and the views used tu access and update it. The "easy to use" interface is a big incentive to end users to define things properly, instead of relying to the horrible "Excel sheet with forms" I used to have to cope with. In a heavy multi-user environment, MS Access might be a "data lottery". I have no direct experience of this. In my low-use environment, I had no real reason to complain about data corruption : my problems were more bound to the lack of protection of the MS Windows environment, and were solved my migrating data files on a proper server. Performance, however, can be poor. I have in mind some examples involving Cartesian products or remerging that were hell to compute :=(( ... [ ... ] According to the current documentation, views are read.only. This implies some grunt work when creating update forms for the kind of low-use applications I have to manage. You can implement it yourself through trigger functions, no big deal. Grunt work, as I said. And we are awfully short on time for doing this. But, typical applications nowadays interact with the user through dialogues with text entry fields. Your client has to process this information anyway. Just a minimum, none if possible ... Our processing is made mostly *post* entry. Doesn't make much of a difference then to split the information to the tables it belongs to instead of just putting it into your view. "Just putting it into my view" is a hell of a lot faster and a hell of a lot less work. And I (and my assistants) are paid to work on our data, not to write programs to access them ... Data entry and maintainance are an ancilliary task. Quite often, two or more distinct applications have to use common data. My favourite example is again medical : two othewise unrelated applications might have to use a common medical thesaurus. The obvious solution (including the medical thesaurus tables in each and every application) leads to awful consistency problems. Working this way can be properly done only with replication, which is not yet available ??? why? You are working with a client-server system, and you can have any number of databases on a postgres server. Nope : the thesaurus data might not be ours, and live on a server we can *read*, not *write to*, and certainly not program to our heart's content, and definitively *not* with PostgreSQL. Do you really think I can request our financial department to throw off their beloved Oracle databases, end result of tens of years of work, and switch to our preffered PostgreSQL server ? And do you think I could put sensitive medical information on a server accessible to people not cleared to view any medical data ? If so, you'd better think again before proposing gnumed ... For reasons that should be obvious, our data live in a server accessible to a small number of microcomputers in our department. And there is a *lot* of good and bad reasons for which they will stay here. For example, our database authority (the french CNIL) would have a seizure if those data were to be migrated on a non-restricted server. Furthermore, we might have to use *several* unrelated database not belonging to us ... The "one server serves all client" is totally unapplicable to our problems .. I'm looking for a practical solution, not for an excuse to an administrative war, that I'd loose, btw ... No need for replication for this purpose. in PostgreSQL. Furthermore, most applications will use only one or two views of the thesaurus, while the thesaurus might be both large and complex. That does not matter for the application (client). It will be blissfully unaware of the size or complexity of your thesaurus. A microcomputer client having to manage the huge size of the original database would be painfully aware of this ... and the users too ... That non-solution, therefore, would imply migrating our medical data to exactly one central server, which is, again, unacceptable. 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 application a relational RDBMS with capability to access more than one database at a time. This was MS Access for us, up until now. And I would *love* to get rid of
Re: [HACKERS] A post-7.1 wish-list.
I would like to inquire if in the next release of postgresql the database will have to be compacted into a single file like what Interbase database supports? I find this feature convenient because it will simplify the updating of your database considering that you will be dealing only with one single file. Thanks and MORE POWER TO EVERYONE! -- Manny C. Cabido e-mail:[EMAIL PROTECTED] [EMAIL PROTECTED] =
Re: [HACKERS] A post-7.1 wish-list.
Peter Eisentraut wrote: Emmanuel Charpentier writes: 1) Updatable views. You can make rules updateable by attaching appropriate rules to them. The transparent implementation of updateable views would essentially do that. It's a planned feature but I don't know of anyone who has made it his priority. I'd try my hand at it, given enough time ... which I'm awfully short on. Which is one of my reasons to have that feature : not having to do grunt work. 2) External database or table access. Accessing more than one database from a connection will not happen, at least as long has the current mindset of the developers persists. SQL schema support is planned for 7.2, which will address the same area, however. I fail to see how schema support would help me accessing data residing on different servers (that cannot be moved, for a lot of good and bad reasons). Could you please amplify ? -- Emmanuel Charpentier
[HACKERS] Install Failure [7.1beta2 tarballs]
After configuring with ./configure --enable-multibyte --enable-unicode-conversion --enable-odbc --prefix=/usr --sysconfdir=/etc --localstatedir=/var make make install 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. I'll see if I can track down what happened a little later on... -- - Thomas Swan - Graduate Student - Computer Science - The University of Mississippi - - People can be categorized into two fundamental - groups, those that divide people into two groups - and those that don't.
[HACKERS] pgaccess and LIMIT?
Hi, try the following command (Queries/New) in pgaccess from 7.0.3: SELECT * from cols LIMIT 1; It will return the same set of records as: SELECT * from cols; psql works correctly. -- Pavel Jank ml. [EMAIL PROTECTED] http://www.janik.cz
RE: [HACKERS] A post-7.1 wish-list.
I'd try my hand at it, given enough time ... which I'm awfully short on. Which is one of my reasons to have that feature : not having to do grunt work. It should only take a few seconds to write such rules for simple views -- see the examples in the Programmer documentation. /programmer/rules1139.htm#AEN1227 - Andrew
[HACKERS] still no log
Sorry for the insistence, but after looking and looking again, I can't find out why the postgres logs are empty. The postgres database is up and working great, but nothing is getting logged. I'm on a RedHat Linux (6.0 with lot of upgrades) postgres 7.0.3 from rpm (downoaded from the postgres ftp server) Any ideas? -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
[GENERAL] Re: still no log
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? "Martin A. Marques" wrote: Sorry for the insistence, but after looking and looking again, I can't find out why the postgres logs are empty. The postgres database is up and working great, but nothing is getting logged. I'm on a RedHat Linux (6.0 with lot of upgrades) postgres 7.0.3 from rpm (downoaded from the postgres ftp server) Any ideas? -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] A post-7.1 wish-list.
On Mon, 8 Jan 2001, Manuel Cabido wrote: I would like to inquire if in the next release of postgresql the database will have to be compacted into a single file like what Interbase database supports? I find this feature convenient because it will simplify the updating of your database considering that you will be dealing only with one single file. I don't understand how a single file is easier to update. What kind of updates are you talking about? A single file archicture requires that the database system have a storage manager and a pseudo filesystem. It also becomes another thing to configure and monitor. Ask anyone who has delt with Oracle's tablespace and extent management on how complicated this can be. Tom
[HACKERS] Lock on arbitrary string feature
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 processes trying to do GETLOCK "string" will block until the lock is released. This feature can allow applications to better serialize things. For example: inserting unique records. Cooperating applications could just do something like: GETLOCK "mytable.key2=1234"; SELECT count(*) from mytable where key2=1234 for update; if count==0, insert the stuff. elsif count==1 update the stuff instead else something is wrong! The lock will thus only affect applications interested in mytable where key2=1234 In contrast the current alternatives appear to be either LOCK the entire table (preventing ALL inserts and selects), or to create a UNIQUE constraint (forcing complete rollbacks and restarts in event of a collision :( ). Any comments, suggestions or tips would be welcome. It looks like quite a complex thing to do - I've only just started looking at the postgresql internals and the lock manager. Cheerio, Link.
[HACKERS] Re: still no log
El Mi 10 Ene 2001 21:07, escribiste: "Martin A. Marques" wrote: Sorry for the insistence, but after looking and looking again, I can't find out why the postgres logs are empty. The postgres database is up and working great, but nothing is getting logged. I'm on a RedHat Linux (6.0 with lot of upgrades) postgres 7.0.3 from rpm (downoaded from the postgres ftp server) Any ideas? If postmaster is started with -S, nothing gets logged. Is that your problem? Well, I'm not sure. I can't recall checking that in the startup script, but I think it's not there. Any way, why would the instalation make the entries in the logroutate config files and then have a startup script that won't do logging? I'm using the normal startup script in /etc/rc.d/init.d/. Saludos... :-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
RE: [HACKERS] Re: still no log
I just jumped in on this thread so I'm not sure where you're looking for the logging, but postgreSQL has the following option when building (from './configure --help'): --enable-syslog enable logging to syslog I saw that you're installing from RPM's so this won't help and I'm not even sure that this is the logging about which you're talking, but thought I'd post just in case! Cheers, Craig -Original Message- From: Martin A. Marques [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 10, 2001 6:19 PM To: Oliver Elphick Cc: pgsql-general; [EMAIL PROTECTED] Subject: [HACKERS] Re: still no log El Mi 10 Ene 2001 21:07, escribiste: "Martin A. Marques" wrote: Sorry for the insistence, but after looking and looking again, I can't find out why the postgres logs are empty. The postgres database is up and working great, but nothing is getting logged. I'm on a RedHat Linux (6.0 with lot of upgrades) postgres 7.0.3 from rpm (downoaded from the postgres ftp server) Any ideas? If postmaster is started with -S, nothing gets logged. Is that your problem? Well, I'm not sure. I can't recall checking that in the startup script, but I think it's not there. Any way, why would the instalation make the entries in the logroutate config files and then have a startup script that won't do logging? I'm using the normal startup script in /etc/rc.d/init.d/. Saludos... :-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
[HACKERS] PostgreSQL web page
I wonder why http://www.postgresql.org is not updated with news. The latest "Latest News" is from Nov 16. I have to go to http://www.pgsql.com to find some interesting news later than that: 2000-12-22 PostgreSQL, Inc. Releases Open Source Replication Database and2000-12-12 2000 Linux Journal Editor's Choice Award for Best Database In fact I was looking for the Replication server. No mention seems to be available on postgresql.org. Also the mailing list archive for pgsql-sql is not listed here: http://www.postgresql.org/devel-corner/index.html - but you can see it if you write the correct URL yourself. -- Kaare Rasmussen --Linux, spil,--Tlf:3816 2582 Kaki Data tshirts, merchandize Fax:3816 2501 Howitzvej 75 ben 14.00-18.00Email: [EMAIL PROTECTED] 2000 Frederiksberg Lrdag 11.00-17.00 Web: www.suse.dk
