Re: [BUGS] referential integrity requires write permission to atable which only needs to be read
On Wed, 30 Aug 2000 [EMAIL PROTECTED] wrote: > Short Description > referential integrity requires write permission to a table which only needs to be >read Yes, this is a known problem. > And, why is the trigger trying to select WITH UPDATE? (locking?) Yes, if you don't grab a row lock, another transaction can come along and delete the row you're referencing after you've checked it, but before that transaction sees that you've added a referencing row (which could lead to orphened children) > In any case, this is requiring us to grant update permission to this > user group, and we really only want them to have select permission to > the table in question. Right now, the suggested workaround is to do a trigger before updates that prevents the unwanted writes in plpgsql. Not particularly good, but functional until this gets fixed (and I don't know precisely when that'll be)
Re: [BUGS] inconsistent debug log output
[EMAIL PROTECTED] writes: > a transaction from psql shows referential integrity statements in the > output, but a transaction from a client using libpq does not; they are > both using the same backend, PGDEBUG=2: I think you are misinterpreting what you see. The additional queries needed for RI checks are compiled only once per backend (when first invoked), and thereafter cached. The "query:" log entry at debuglevel 2 actually comes from the parser, and so will only appear when the RI check is compiled. Your client trace presumably is from a segment of activity later than first execution of this particular RI check. regards, tom lane
[BUGS] Re: [BUG] calling lo_creat()
"Barnes, Sandy (Sandra)" <[EMAIL PROTECTED]> writes:
> Platform: PostgreSQL 7.0.2 on RedHat6.2 Linux
> Test: Testing the creation of large objects. I was putting the large
> objects into a database table but this
>test program recreates the error for me without having to do that.
> Program Error: Can't create large object
> Database Log Error: FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnum_index
Can anyone else duplicate this? I don't see it on my available boxes
(7.0.2 and current on HPUX and an old Linux box). The test program
is pretty trivial, see attached.
regards, tom lane
/*-
*
* loOid2.c
*test creation of many large objects
*-
*/
#include
#include
#include
#include
#include "libpq-fe.h"
#include "libpq/libpq-fs.h"
static Oid
createOid(PGconn *conn, int i)
{
Oid lobjId;
int lobj_fd;
/*
* create a large object
*/
lobjId = lo_creat(conn, INV_READ | INV_WRITE);
if (lobjId == 0)
{
fprintf(stderr, "can't create large object\n");
exit(1);
}
lobj_fd = lo_open(conn, lobjId, INV_WRITE);
printf("oid [%d] %d\n", lobjId, i);
/* printf("\tfd [%d]", lobj_fd); */
lo_close(conn, lobj_fd);
return lobjId;
}
static void
exit_nicely(PGconn *conn)
{
PQfinish(conn);
exit(1);
}
int
main(int argc, char **argv)
{
char *database;
Oid lobjOid;
PGconn *conn;
PGresult *res;
int i;
database = argv[1];
/*
* set up the connection
*/
conn = PQsetdb(NULL, NULL, NULL, NULL, database);
/* check to see that the backend connection was successfully made */
if (PQstatus(conn) == CONNECTION_BAD)
{
fprintf(stderr, "Connection to database '%s' failed.\n", database);
fprintf(stderr, "%s", PQerrorMessage(conn));
exit_nicely(conn);
}
res = PQexec(conn, "begin");
PQclear(res);
for (i=0; i<100; i++)
{
lobjOid = createOid(conn, i);
}
res = PQexec(conn, "end");
PQclear(res);
PQfinish(conn);
return 0;
}
[BUGS] Page 13 of tutorial has a typo I believe
Chris Green ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description Page 13 of tutorial has a typo I believe Long Description the Cartesian product of domains. such that V1 (is a member of) D1, V1 (is a member of) D1, ... Vk (is a member of) Dk the second V1 should be V2 and D2 I believe Sample Code No file was uploaded with this report
[BUGS] misleading (or perhaps confusing) error messages
Dave E Martin ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description misleading (or perhaps confusing) error messages Long Description When an error is generated as the result of a trigger (or other indirect action) it would be helpful if the error message could somehow indicate the trigger was the cause, rather than the executed statement itself. for instance: insert into NAS values (...); ERROR: nas_make: Permission denied While the error message is technically correct, it tends to leave one scratching one's head, until one remembers or realizes that a trigger was involved. When dealing with a complicated series of statements and/or transactions it may be considerably more difficult to make the required inference from the error message. Sample Code No file was uploaded with this report
