[HACKERS] Suggested fix for pg_dump
The problem with pg_dump and renamed primary key attrs can be fixed by using the indkey attribute of pg_index to lookup attrs in pg_class - this is what pg_dump does when it dumps indexes. If I am going to make this change, I would also like to split the PK definition out from the table definition, so we would have: Create Table fred(f1 int); Alter Table fred add constraint primary key(f1); instead of: Create Table fred(f1 int, primary key(f1)); The reason for this is that it will improve load performance, and begin to allow pg_restore to separate constraints from tables. Is this OK? Or inappropriate for beta? Needless to say, I don't really want to revisit this piece of code in 3 months time, so I'd like to do it now. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[HACKERS] Quite strange crash
Hi, Does anyone seen this on PostgreSQL 7.0.3? FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. Server process (pid 1008) exited with status 6 at Sun Jan 7 04:29:07 2001 Terminating any active server processes... Server processes were terminated at Sun Jan 7 04:29:07 2001 Reinitializing shared memory and semaphores -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] Suggested fix for pg_dump
On Sun, 7 Jan 2001, Philip Warner wrote: The problem with pg_dump and renamed primary key attrs can be fixed by using the indkey attribute of pg_index to lookup attrs in pg_class - this is what pg_dump does when it dumps indexes. If I am going to make this change, I would also like to split the PK definition out from the table definition, so we would have: Create Table fred(f1 int); Alter Table fred add constraint primary key(f1); instead of: Create Table fred(f1 int, primary key(f1)); The reason for this is that it will improve load performance, and begin to allow pg_restore to separate constraints from tables. Is this OK? Or inappropriate for beta? Needless to say, I don't really want to revisit this piece of code in 3 months time, so I'd like to do it now. From Tatsuo's example, it looks critical enough that it should be fixed before release, and since its a 'support program' issue, not a 'core server' issue, ramifications of fixing it aren't as big as if it was a 'core server' issue ... go for it
[HACKERS] A post-7.1 wish-list.
Dear list, According to this list's content, the upcoming 7.1 release appears to be in good progress. This version will bring a *lot* on necessary features for some database work : unions and subselects in views, and the long-awaited outer joins. In other words, while 7.0 was a large step in *performance* terms, 7.1 will be a huge advance in *competence*. These advances will allow me to use PostgreSQL for some work I had to do until now with (gasp !) MS-Access (which has poor performance but good competence). And get rid of the damn MS-Windows envoronment for good ! This leads me to express two whishes for future PotgreSQL developments. These ideas are inpired by my daily work and might or might not be of great usefulness for other uses. My daily work (biostatistics) involves managing a lot of small but complex databases : those are mainly medical records, created for a study's purposes, wich have a low volume (a dozen or two of tables having some dozens to some thousands rows) but might have a deeply nested and irregular structure (not all patients recorded need to have records of all histories and procedures involved). As a consequence, I am much more interested in competence than in performance, and so is my wishlist. Keep that in mind when reading what follows. 1) Updatable views. == 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. I know that computing the "updatability" of a view is not a trivial problem. Furthermore, even when a view is indeed updatable, the update/append algorithm is not easy to compute. These problems are even harder in multi-user mode. And I do not have any idea of the feasibility of such updates in an OO database, where inheritance concerns will interfere. However, such updatable views would greatly simplify the end-user work for creating and maintaining these records (at least when no inheritance is involved. I am not able to state the usefulness of such "updatable views" in more mainstream applications. I note, however, that most "brand-name" RDBMSes ofer that. Your thoughs ? 2) External database or table access. 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 in PostgreSQL. Furthermore, most applications will use only one or two views of the thesaurus, while the thesaurus might be both large and complex. 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 ability to "attach" (MS-Access parlance) a table or a view from another database is quite helpful. And I think that it has a lot of applications outside my (quite limited) realm. For example, two different departments of the same company might have needs for two different management applications, while having to use/update the same company-wide accounting records. I don't se the "replication" solution as a good one (data duplication should be considered harmful in any circumstances). This could be implemented in different ways. From the easiest to the hardest : - Attachment of Postgres databases running on the same server : relatively easy. The data structures (internal representation) are known, there is a guarantee of consistency in user identification, security information is also consistent. - Attachment of Postgres databases running on another server. There, while the data structures are known, the user and security informations can be inconsistent and have to be managed "by hand". - Attachment of other databases. Ouch : this one is hard. One have to rely on the information made available by the other database server. And there lies a problem : there is no universal standard for this. ... or there is ? Two bridges come to mind. Using ODBC or JDBC, provided the "other" RDBMS has that, allows to use some standard information : at the very minimum, table names, attribute names and type, and updatability. In most cases, you will also be able to know whether indices are available for such and such columns. This minimal set of information allows you to use these external tables in your own joins. And, provided that you have update rights, the ability to use them as "native" tables. Of course, the use of these bridges involve some (maybe quite serious) performance loss. But then again, I'm less interested in performance than in competence ... What do you think ? Emmanuel Charpentier -- Emmanuel Charpentier
Re: [HACKERS] Re: Beta2 ... ?
Emmanuel Charpentier wrote: Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. -- 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 "Blessed are the pure in heart, for they shall see God."Matthew 5:8
Re: [HACKERS] pg_restore options issues
Peter Eisentraut wrote: pg_restore has some options that are supposed to allow restoring some or all indexes/tables/triggers/etc. For example pg_restore --table restores all tables and pg_restore --table=my_table restores only the named table. The equivalent short option is -t but it does not allow restoring all tables, since it requires an argument. I suggest that an argument of '*' also means to restore all tables. I don't like that; it will need to be escaped with \ or the shell will substitute the contents of the current directory for the *. Why not use `-t all' or `-A'? You should also change the help text a bit: -t [table], --table[=table]dump for this table only gives no hint that omitting `=table' will restore all tables. -- 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 "Blessed are the pure in heart, for they shall see God."Matthew 5:8
Re: [HACKERS] pg_restore options issues
Oliver Elphick writes: I don't like that; it will need to be escaped with \ or the shell will substitute the contents of the current directory for the *. Why not use `-t all' Because there might be a table called "all". (Okay, there could be a table called "*", but really...) or `-A'? We'd need an option letter for tables, triggers, indexes, functions, etc. You should also change the help text a bit: -t [table], --table[=table] dump for this table only gives no hint that omitting `=table' will restore all tables. Okay, when we decide how to handle it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Quite strange crash
Denis Perchine [EMAIL PROTECTED] writes: Does anyone seen this on PostgreSQL 7.0.3? FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. Were there any errors before that? I've been suspicious for awhile that the system might neglect to release buffer cntx_lock spinlocks if an elog() occurs while one is held. This looks like it might be such a case, but you're only showing us the end symptom not what led up to it ... regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
"Oliver Elphick" [EMAIL PROTECTED] writes: I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. In that case you may as well say that there will be no beta debs, and Debian users can forget about being part of the beta test process. We do not make a guarantee of "no more initdbs" until final release. The severity of bug needed to make us do one goes up considerably with each beta, but there will not be a guarantee on *any* beta. If there were such a guarantee, it'd be final not beta. regards, tom lane
Re: [HACKERS] Suggested fix for pg_dump
On Sun, 7 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: On Sun, 7 Jan 2001, Philip Warner wrote: Is this OK? Or inappropriate for beta? From Tatsuo's example, it looks critical enough that it should be fixed before release, and since its a 'support program' issue, not a 'core server' issue, ramifications of fixing it aren't as big as if it was a 'core server' issue ... go for it I concur. This is not a new feature, but a bug fix, and therefore it's appropriate to do it during beta. We don't require beta-period bug fixes to be the smallest possible change that cures the problem. They should be good fixes if practical. One issue however is how confident are we of the alter table add constraint code? I'm not sure it's been exercised enough to justify making pg_dump rely on it ... is anyone willing to spend some time testing that statement? Since its obvious that pg_dump isn't working now, we wouldn't be breaking it any further if the constraint code has a problem with it ... and we should be able to find out relatively quickly *if* the contraint code has a problem if its used for something like this ... Essentially, worst case scenario, we are going from 'broken-broken' ...
Re: [HACKERS] Suggested fix for pg_dump
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 understood the thread correctly). But Philip is proposing to change pg_dump to rely on alter table add constraint for *all* PRIMARY KEY constructs. So if alter table add constraint fails, it could break cases that had nothing to do with either foreign keys or renamed columns. I'm not really arguing not to make the change. I am saying there's an area here that we'd better take care to test during beta cycle... regards, tom lane
Re: [HACKERS] Suggested fix for pg_dump
On Sun, 7 Jan 2001, 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 understood the thread correctly). But Philip is proposing to change pg_dump to rely on alter table add constraint for *all* PRIMARY KEY constructs. So if alter table add constraint fails, it could break cases that had nothing to do with either foreign keys or renamed columns. I'm not really arguing not to make the change. I am saying there's an area here that we'd better take care to test during beta cycle... Agreed ... we almost need a regression test for pg_dump itself :)
Re: [HACKERS] CVS regression test failure on OBSD
A few problems came up with 7.1CVS for i86 OpenBSD. Here is a writeup on what I learned and how I solved the problems. - Brandon b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 Added gmake and gettext. (if you don't have it) Added bison and replaced /usr/bin/yacc with /usr/local/bin/bison get source (make sure you don't ./configure before you update yacc) (these above points should ONLY effect the CVS version, not a snapshot) ./configure gmake gmake check - fast make check failed when I had too much else going on. (too many other postgres owned apps). On a fast machine, this will really break fast since some of the postgres instances don't return before others start up and we hit max process (64). edited: /etc/login.conf Changed: default:\ :maxproc-max=128:\ :maxproc-cur=64:\ :openfiles-cur=64:\ to default:\ :maxproc-max=256:\ :maxproc-cur=256:\ :openfiles-cur=256:\ Be warned, however, this this could cause other problems on the machine. Now other processes will get locked out and will no be able to run. This is a safe high number for a box that is ONLY RUNNING POSTGRESQL. Tweak as necessary. - make check with postmaster running (on a non 5432 port) This bombs with: pgql: connectDBStart() -- connect() failed: No such file or directory Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? createdb: database creation failed pg_regress: createdb failed When I am running the regression test and I try to start up postmaster, I get: $ bin/postmaster -p -i -D data IpcSemaphoreCreate: semget(key=002, num=17, 03600) failed: No space left on device This error does *not* mean that you have run out of disk space. It occurs either because system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Look into the PostgreSQL documentation for details. Time to change this in the kernel. I added the following 2 lines to a 'GEN.postgres' config (just copied GENERAL to the new name): option SEMMNI=256 option SEMMNS=2048 and recompiled the kernel. Using these settings I am able to run 6 instances of postmaster on a celeron 300 w/ 96M ram before seeing that problem arise again. ** Note that once those 6 are running, make check will again break since it will not be able to have enough SEMMNI/SEMMNS. Also, please note that though 6 are running, we have no idea how many files are open and how this will effect the function of client connections, etc. (5 postmasters + make check DID with this setup on my machine) ** Please mail me any other information that any other people come up with regarding this problem (like what SEMMNI/SEMMNS and ulimits cap out at, etc). Brandon Palmer [EMAIL PROTECTED]
Re: [HACKERS] Re: Beta2 ... ?
Oliver Elphick wrote: Emmanuel Charpentier wrote: Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. Well, it bit me too -- which is one of the lesser reasons why I have been reluctant to release RPM's before a release candidate. However, if someone wants to beta test the packaging (which, incidentally, is made substantially easier with 7.1) of the new release, then they should expect the results -- for instance, Red Hat doesn't guarantee that you will be able to upgrade from their public beta test OS releases to any future release (more than likely you _will_ be able to, but not necessarily). Only official releases are 'upgradeable'. I would suggest, as I am doing myself, to release beta-grade packages for testing _only_, with the proper disclaimers. But, I don't see how debs are harder to produce than RPMs -- and while I do have some help from RedHat, SuSE, and others, that help seems to be more towards their distribution rather than towards PostgreSQL -- ie, they go their own way for the most part. Each distribution using RPM's has its own arcane rules -- and some of those rules make little sense from the PostgreSQL point of view. And, I don't blame them one whit for that -- they are, after all, employed for the purpose of making a distribution, not a PostgreSQL package. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] heap_update is broken in current sources
heap_update() currently ends with
if (newbuf != buffer)
{
LockBuffer(newbuf, BUFFER_LOCK_UNLOCK);
WriteBuffer(newbuf);
}
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
WriteBuffer(buffer);
/* invalidate caches */
RelationInvalidateHeapTuple(relation, oldtup);
RelationMark4RollbackHeapTuple(relation, newtup);
return HeapTupleMayBeUpdated;
This is broken because WriteBuffer releases our refcounts on the buffer
pages that are holding the old and new tuples. By the time
RelationInvalidateHeapTuple gets to do its thing, some other backend may
have swapped a new disk page into the shared buffer that oldtup points
at. catcache.c will then be using the wrong data to compute the hash
index of the old tuple. This will at minimum result in failure to
invalidate the old tuple out of our catcache (because we'll be searching
the wrong hashchains), and can lead to a flat-out crash or Assert
failure due to invalid data being fed to the hashing code.
I have seen several nonrepeatable failures in the parallel regress tests
in recent weeks, which I now believe are all traceable to this error.
I will commit a fix for this error shortly, and have recommended to Marc
that he re-roll the beta2 tarball before announcing it...
regards, tom lane
Re: [HACKERS] CVS regression test failure on OBSD
bpalmer writes: A few problems came up with 7.1CVS for i86 OpenBSD. Here is a writeup on what I learned and how I solved the problems. Can you check http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC to see if the description for FreeBSD is also applicable (at least in similar form) to OpenBSD? I'm currently writing up a section about the process and file limit issue, which will end up nearby the section linked to above. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] CVS regression test failure on OBSD
Can you check http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC to see if the description for FreeBSD is also applicable (at least in similar form) to OpenBSD? Close enough. I'm currently writing up a section about the process and file limit issue, which will end up nearby the section linked to above. I still don't know how to know what the max allowed (by the system) are. Anyone? - b b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5
[HACKERS] patch: contrib/pgcrypto sanity
The KAME files md5.* and sha1.* have the following changelog
entry:
revision 1.2
date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines:
+18 -18
Eliminate some of the more blatant platform-dependencies ... it
builds here now, anyway ...
Which basically changes u_int*_t - uint*_t, so now it does not
compile neither under Debian 2.2 nor under NetBSD 1.5 which
is platform independent all right. Also it replaces $KAME$
with $Id$ which is Bad Thing. PostgreSQL Id should be added as a
separate line so the file history could be seen.
So here is patch:
* changes uint*_t - uint*. I guess that was the original
intention
* adds uint64 type to include/c.h because its needed
[somebody should check if I did it right]
* adds back KAME Id, because KAME is the master repository
* removes stupid c++ comments in pgcrypto.c
* removes sys/types.h from the code, its not needed
--
marko
Index: pgsql/contrib/pgcrypto/md5.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/contrib/pgcrypto/md5.c,v
retrieving revision 1.2
diff -u -r1.2 md5.c
--- pgsql/contrib/pgcrypto/md5.c2000/12/04 01:20:38 1.2
+++ pgsql/contrib/pgcrypto/md5.c2001/01/07 16:45:13
@@ -1,4 +1,5 @@
/* $Id: md5.c,v 1.2 2000/12/04 01:20:38 tgl Exp $ */
+/* $KAME: md5.c,v 1.3 2000/02/22 14:01:17 itojun Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
@@ -30,7 +31,6 @@
*/
#include postgres.h
-#include "pgcrypto.h"
#include "md5.h"
@@ -91,7 +91,7 @@
#define MD5_D0 0x10325476
/* Integer part of 4294967296 times abs(sin(i)), where i is in radians. */
-static const uint32_t T[65] = {
+static const uint32 T[65] = {
0,
0xd76aa478, 0xe8c7b756, 0x242070db, 0xc1bdceee,
0xf57c0faf, 0x4787c62a, 0xa8304613, 0xfd469501,
@@ -114,7 +114,7 @@
0xf7537e82, 0xbd3af235, 0x2ad7d2bb, 0xeb86d391,
};
-static const uint8_t md5_paddat[MD5_BUFLEN] = {
+static const uint8 md5_paddat[MD5_BUFLEN] = {
0x80, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
@@ -125,7 +125,7 @@
0, 0, 0, 0, 0, 0, 0, 0,
};
-static void md5_calc (uint8_t *, md5_ctxt *);
+static void md5_calc (uint8 *, md5_ctxt *);
void md5_init(ctxt)
md5_ctxt *ctxt;
@@ -141,7 +141,7 @@
void md5_loop(ctxt, input, len)
md5_ctxt *ctxt;
- uint8_t *input;
+ uint8 *input;
unsigned int len; /* number of bytes */
{
unsigned int gap, i;
@@ -155,7 +155,7 @@
md5_calc(ctxt-md5_buf, ctxt);
for (i = gap; i + MD5_BUFLEN = len; i += MD5_BUFLEN) {
- md5_calc((uint8_t *)(input + i), ctxt);
+ md5_calc((uint8 *)(input + i), ctxt);
}
ctxt-md5_i = len - i;
@@ -207,7 +207,7 @@
}
void md5_result(digest, ctxt)
- uint8_t *digest;
+ uint8 *digest;
md5_ctxt *ctxt;
{
/* 4 byte words */
@@ -227,24 +227,24 @@
}
#if BYTE_ORDER == BIG_ENDIAN
-uint32_t X[16];
+uint32 X[16];
#endif
static void md5_calc(b64, ctxt)
- uint8_t *b64;
+ uint8 *b64;
md5_ctxt *ctxt;
{
- uint32_t A = ctxt-md5_sta;
- uint32_t B = ctxt-md5_stb;
- uint32_t C = ctxt-md5_stc;
- uint32_t D = ctxt-md5_std;
+ uint32 A = ctxt-md5_sta;
+ uint32 B = ctxt-md5_stb;
+ uint32 C = ctxt-md5_stc;
+ uint32 D = ctxt-md5_std;
#if BYTE_ORDER == LITTLE_ENDIAN
- uint32_t *X = (uint32_t *)b64;
+ uint32 *X = (uint32 *)b64;
#endif
#if BYTE_ORDER == BIG_ENDIAN
/* 4 byte words */
/* what a brute force but fast! */
- uint8_t *y = (uint8_t *)X;
+ uint8 *y = (uint8 *)X;
y[ 0] = b64[ 3]; y[ 1] = b64[ 2]; y[ 2] = b64[ 1]; y[ 3] = b64[ 0];
y[ 4] = b64[ 7]; y[ 5] = b64[ 6]; y[ 6] = b64[ 5]; y[ 7] = b64[ 4];
y[ 8] = b64[11]; y[ 9] = b64[10]; y[10] = b64[ 9]; y[11] = b64[ 8];
Index: pgsql/contrib/pgcrypto/md5.h
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/contrib/pgcrypto/md5.h,v
retrieving revision 1.2
diff -u -r1.2 md5.h
--- pgsql/contrib/pgcrypto/md5.h2000/12/04 01:20:38 1.2
+++ pgsql/contrib/pgcrypto/md5.h2001/01/07 16:45:13
@@ -1,4 +1,5 @@
/* $Id: md5.h,v 1.2 2000/12/04 01:20:38 tgl Exp $ */
+/* $KAME: md5.h,v 1.3 2000/02/22 14:01:18 itojun Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
@@ -36,8 +37,8 @@
typedef struct {
union {
- uint32_tmd5_state32[4];
- uint8_t md5_state8[16];
+ uint32
Re: [HACKERS] patch: contrib/pgcrypto sanity
Marko Kreen [EMAIL PROTECTED] writes: date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18 Eliminate some of the more blatant platform-dependencies ... it builds here now, anyway ... Which basically changes u_int*_t - uint*_t, so now it does not compile neither under Debian 2.2 nor under NetBSD 1.5 which is platform independent¸ all right. Well, that's annoying. I guess those platforms are out of step with the C99 standard, which specifies uint*_t not u_int*_t (cf. C99 7.4.1.1). I agree with your solution of switching to Postgres-supplied typenames. Also it replaces $KAME$ with $Id$ which is Bad Thing. PostgreSQL Id should be added as a separate line so the file history could be seen. I didn't know what $KAME$ was, and took it for some national-language variant of $Id$ that our CVS server didn't know about. Who/what is KAME anyway? * adds back KAME Id, because KAME is the master repository Is that a good idea? If we are deliberately deviating from whatever "master repository" this is, I'm not sure that we should continue to label the code with their revision ID. regards, tom lane
RE: [HACKERS] Suggested fix for pg_dump
Create Table fred(f1 int); Alter Table fred add constraint primary key(f1); Has support for the above statement (add constraint PK) been added in 7.1? If so, then what other alter table add constraints have been added? CHECK? NOT NULL? Thanks, Chris
[HACKERS] ALL, ANY bug?
It seems ALL and ANY (SOME) have problems with the parser. test=# select * from t1 where i all(0,1); ERROR: parser: parse error at or near "0" test=# select * from t1 where i = any (0,1); ERROR: parser: parse error at or near "0" test=# select version(); version PostgreSQL 7.1beta2 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66 (1 row) Note that if (0,1) is a subselect, it works fine. -- Tatsuo Ishii
Re: [HACKERS] patch: contrib/pgcrypto sanity
On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18 Eliminate some of the more blatant platform-dependencies ... it builds here now, anyway ... Which basically changes u_int*_t - uint*_t, so now it does not compile neither under Debian 2.2 nor under NetBSD 1.5 which is platform independent all right. Well, that's annoying. I guess those platforms are out of step with the C99 standard, which specifies uint*_t not u_int*_t (cf. C99 7.4.1.1). I agree with your solution of switching to Postgres-supplied typenames. Well, actually they do. glibc in stdint.h and NetBSD in sys/inttypes.h which is a mess, all rigth. Problem is that postgres.h does not know about this. I guess that C99 forgot to specify _where_ they should be defined. But the point is, what are the standard types in PostgreSQL? C99 ones are not, because there would be lots of noise raised already. If you think that the C99 should be standard someday, then postgres.h should also provide them, because older platforms definitely do not provide them. Also it replaces $KAME$ with $Id$ which is Bad Thing. PostgreSQL Id should be added as a separate line so the file history could be seen. I didn't know what $KAME$ was, and took it for some national-language variant of $Id$ that our CVS server didn't know about. Who/what is KAME anyway? KAME is the project that provides IPv6 to all the free BSD's. (www.kame.net) * adds back KAME Id, because KAME is the master repository Is that a good idea? If we are deliberately deviating from whatever "master repository" this is, I'm not sure that we should continue to label the code with their revision ID. I think it is. I think they are more competent on maintaining crypto than PostgreSQL team (at least they devote more time on it). This makes tracking changes easier. This (special Id's) are widely used practice in BSD's, this makes clear whether a file is 'original' or 'imported'; and from where. -- marko
Re: [HACKERS] ALL, ANY bug?
Tatsuo Ishii [EMAIL PROTECTED] writes: It seems ALL and ANY (SOME) have problems with the parser. I see no problem here. Those are only defined for sub-selects. SQL92 8.7 says: quantified comparison predicate ::= row value constructor comp op quantifier table subquery quantifier ::= all | some all ::= ALL some ::= SOME | ANY and that is the only appearance of ANY in the grammar ... regards, tom lane
Re: [HACKERS] Quite strange crash
On Monday 08 January 2001 00:08, Tom Lane wrote: Denis Perchine [EMAIL PROTECTED] writes: Does anyone seen this on PostgreSQL 7.0.3? FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. Were there any errors before that? No... Just clean log (I redirect log from stderr/out t file, and all other to syslog). Here it is just from the begin: DEBUG: Data Base System is starting up at Sun Jan 7 04:22:00 2001 DEBUG: Data Base System was interrupted being in production at Thu Jan 4 23:30:22 2001 DEBUG: Data Base System is in production state at Sun Jan 7 04:22:00 2001 FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting. Server process (pid 1008) exited with status 6 at Sun Jan 7 04:29:07 2001 Terminating any active server processes... Server processes were terminated at Sun Jan 7 04:29:07 2001 Reinitializing shared memory and semaphores - As far as you can see it happends almost just after start. I can give you full list of queries which was made by process 1008. But basically there was only queries like this: select message_id from pop3 where server_id = 6214 insert into pop3 (server_id, mailfrom, mailto, subject, message_id, sent_date, sent_date_text, recieved_date, state) values (25641, 'virtualo.com', '[EMAIL PROTECTED]', 'Joao roque Dias I have tried them allthis one is for real!', '[EMAIL PROTECTED]', '2001-01-07 04:06:23 -00', 'Sat, 06 Jan 2001 23:06:23 -0500', 'now', 1) And the last query was: Jan 7 04:27:53 mx postgres[1008]: query: select message_id from pop3 where server_id = 22615 I've been suspicious for awhile that the system might neglect to release buffer cntx_lock spinlocks if an elog() occurs while one is held. This looks like it might be such a case, but you're only showing us the end symptom not what led up to it ... Just say me what can I do. Unfortunatly I can not reproduce the situation... -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] patch: contrib/pgcrypto sanity
On Mon, Jan 08, 2001 at 04:06:09AM +0200, Marko Kreen wrote: On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: Which basically changes u_int*_t - uint*_t, so now it does not compile neither under Debian 2.2 nor under NetBSD 1.5 which is platform independent all right. Well, that's annoying. I guess those platforms are out of step with the C99 standard, which specifies uint*_t not u_int*_t (cf. C99 7.4.1.1). I agree with your solution of switching to Postgres-supplied typenames. Well, actually they do. glibc in stdint.h and NetBSD in sys/inttypes.h which is a mess, all rigth. Problem is that postgres.h does not know about this. I guess that C99 forgot to specify _where_ they should be defined. Correction, they both have inttypes.h which probably is the right location for this. * adds back KAME Id, because KAME is the master repository Is that a good idea? If we are deliberately deviating from whatever "master repository" this is, I'm not sure that we should continue to label the code with their revision ID. I think it is. I think they are more competent on maintaining crypto than PostgreSQL team (at least they devote more time on it). This makes tracking changes easier. This (special Id's) are widely used practice in BSD's, this makes clear whether a file is 'original' or 'imported'; and from where. The "master" only means that occasionally somebody (e.g. I) can check if their revision is increased and then can merge changes into our sources, if needed. Also _I_ know where I got these sources but this makes it easier for others too. -- marko
Re: [HACKERS] ALL, ANY bug?
You are right. However, SQL92 spec allows: select * from t1 where i all values(0,1); which is not allowed in PostgreSQL... -- Tatsuo Ishii Tatsuo Ishii [EMAIL PROTECTED] writes: It seems ALL and ANY (SOME) have problems with the parser. I see no problem here. Those are only defined for sub-selects. SQL92 8.7 says: quantified comparison predicate ::= row value constructor comp op quantifier table subquery quantifier ::= all | some all ::= ALL some ::= SOME | ANY and that is the only appearance of ANY in the grammar ... regards, tom lane
