[BUGS] BUG #1245: Postgres won't start
The following bug has been logged online: Bug reference: 1245 Logged by: Windows Admin Bug Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Windows 2000 Description:Postgres won't start Details: PostgreSQL won't start because I'm logged on as a user with administrative rights. This is good practice in Linux / Unix circles, but is unacceptable on Windows. Most windows users use accounts that have Administrative priveledges on their machines. The reason for that is so that we can actually install things, and also because prior to Windows XP, you could not log on with another user before logging off. I understand the security reasons for implementing this, but it doesn't make sense to implement extra (and in my opinion, useless) security on an operating system that is inherantly insecure. The windows user model does not work at all like the Linux / Unix user model. Neither do permissions and rights. A study of Windows culture would have shown that windows culture differs greatly from Unix culture and that almost everyone uses a user with administrative rights to log on. I am not asking that you remove this feature, as it highlights security and might make the user think twice before running things as and Admin user, but I really would like to see a command line argument that power users could use to get Postgresql to run even when I'm logged on as a user in the Administrative group. I am a developer and would have liked to use PostgreSql as a database. If I can't get it to run from the command line on my machine, it goes straight into the recycle bin, no matter how good it is. Sorry :) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1245: Postgres won't start
> PostgreSQL won't start because I'm logged on as a user with administrative > rights. That has be discussed in great detail during the pre-beta period. All the arguments you do provide are quite correct and all of them have been considered and discussed. I myself did argue for "PostgreSQL as Admin on windows", with similiar arguments as you. core developers of PostgreSQL made it clear that PostgreSQL as Admin will not happen in the official distribution. The arguments where compelling and correct: MS itself is going that way of "non Admin" and security So your options are threefold: a) create a user with limited privileges and run postgresql as this user. (HINT: You can also runas /user:lowpriv cmd.exe and you will have a suitable commandline( [a is recommended] The PostgreSQL MSI Binary installer is doing this job for you quite well. b) patch the source to allow postgresql as Admin [not recommended] c) dump postgresql [also not recommended] Best wishes Harald ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1246: not exist pltcl.so in postgresql rpm package
The following bug has been logged online: Bug reference: 1246 Logged by: Christian Gonzalez Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.3 Operating system: Redhat 9 and Redhat EL 3 Description:not exist pltcl.so in postgresql rpm package Details: Hi, I am trying to migrating to PostgreSQL 7.4.5 from 7.4.2, but I have a problem with pltcl.so library. I am finding this library on rpm package of PostgreSQL 7.4.5 and does exist. Where I can find the pltcl.so library?... I am migrating using a dump/restore. Thanks in advance. Best regards. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] PosgreSQL is crashing with a signal 11 - Bug?
Rafael Martinez <[EMAIL PROTECTED]> writes: > I send you the information you ask for. This is really interesting. Looking at tuple 44 in the pg_filedump output: > Item 44 -- Length: 88 Offset: 4016 (0x0fb0) Flags: USED > XID: min (34365810) CMIN|XMAX: 0 CMAX|XVAC: 0 > Block Id: 174 linp Index: 44 Attributes: 6 Size: 28 > infomask: 0x0913 > (HASNULL|HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_INVALID) > t_bits: [0]: 0x2f > 0fb0: 72610c02 ae00 ra.. > 0fc0: 2c000600 13091c2f 0cb70404 0c00 ,../ > 0fd0: 0400 4869 0c00 0300 ..Hi > 0fe0: 9681 0c00 0300 1002 > 0ff0: 0c00 0200 1230 0c00 ...0 > 1000: 0200 1730...0 whereas what we saw in the gdb output was: > (gdb) x/10 3054556648 > 0xb610d5e8: 0x2f0c 0x0002 0x3017 0x020c6172 > 0xb610d5f8: 0x 0x 0x00ae 0x0006002b > 0xb610d608: 0x2f1c0913 0x0404b70b This evidently corresponds to data starting at offset 0ffc on the disk page (the last few bytes of the gdb output match the start of tuple 43, which is in the next higher part of the page --- note that the bytes are being printed in opposite orders by pg_filedump and gdb). So somehow, the byte at page offset 0fff got changed from 00 to 2f in memory, though not on disk. If you still have the core dump, would you look at the area surrounding address 3054556648 and see if there are any other discrepancies between that and what is on disk? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1246: not exist pltcl.so in postgresql rpm package
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > Where I can find the pltcl.so library?... Should be in the postgresql-pl RPM. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1246: not exist pltcl.so in postgresql rpm package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 8 Sep 2004, "PostgreSQL Bugs List" <[EMAIL PROTECTED]> wrote: Where I can find the pltcl.so library?... [EMAIL PROTECTED] devrim]$ rpm -ql postgresql-pl|grep pltcl.so /usr/lib/pgsql/pltcl.so It's in the postgresql-pl rpm. Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBP2DYtl86P3SPfQ4RAj53AJ485JTifpH/sJijaXKSa0CRhSaBHwCgt0sO ajC1sTPOVdCeNBDU4bjSIDg= =ZAN9 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1247: pltcl.so does not exist in postgresql-pl RPM package
The following bug has been logged online: Bug reference: 1247 Logged by: Christian Gonzalez Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.3 Operating system: Redhat 9 and rhel3.0 Description:pltcl.so does not exist in postgresql-pl RPM package Details: I am executing "rpm -qpl postgresql-pl-7.4.5-1PGDG.i686.rpm" for redhat 9 and rhel3.0 RPM package, and the output command is: [EMAIL PROTECTED] rhel3]# rpm -qpl postgresql-pl-7.4.5-1PGDG.i686.rpm /usr/lib/pgsql/plperl.so /usr/lib/pgsql/plpython.so pltcl.so isn't into this RPM package!, I am finding into others RPM packages for the version 7.4.5 and plptcl.so library does not exist!. My questions is: where is this? excuse me for my persistence. regards, Christian Gonzalez ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] PosgreSQL is crashing with a signal 11 - Bug?
Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes: > [Tom Lane]: >> So somehow, the byte at page offset 0fff got changed >> from 00 to 2f in memory, though not on disk. > indeed interesting. IMHO 0x0fff sounds more like a write to -1 > (relative to the next page) than a random memory error. Note though that that offset is only special with respect to locations on disk; it was not a special address in memory. I'm wondering about transient flakiness in your disk drive controller causing it to sometimes return bad data. Have you run any read/write disk tests? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #1248: pg_dump produces grants with concatonated elements
The following bug has been logged online: Bug reference: 1248 Logged by: Timothy LoGrasso Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: SunOS 5.9 Description:pg_dump produces grants with concatonated elements Details: pg_dump produces the following grants: GRANT INSERTSELECTUPDATE ON TABLE camp_score TO mn; Obviously there are no commas or spaces seperating the different privs. I'm actually running the following version: PostgreSQL 7.3.6 on i386-pc-solaris2.8, compiled by cc -fast -xarch=386 -Xa Attached is the ddl to create the table and grant permissions. CREATE USER mn PASSWORD 'mn'; CREATE USER mnview PASSWORD 'mnview'; CREATE USER mgr PASSWORD 'mgr'; CREATE USER mndb PASSWORD 'mndb'; CREATE TABLE camp_score ( ipr_number character varying(15) NOT NULL, performed_by character(6), score_date date, hs_comp smallint, hs_tech smallint, hs_hyg smallint, hs_safe smallint, hs_fire smallint, hs_hp smallint, hs_crit smallint, hs_infr smallint, ew_comp smallint, ew_tech smallint, ew_liq smallint, ew_sol smallint, ew_air smallint, ew_min smallint, ew_rest smallint, ew_corr smallint, ew_infr smallint, ss_comp smallint, ss_tech smallint, ss_snm_acc smallint, ss_snm_prot smallint, ss_class_prot smallint, ss_prop_prot smallint, ss_hostile_prot smallint, ss_infr smallint, mi_comp smallint, mi_tech smallint, mi_bb smallint, mi_mission smallint, mi_asset smallint, mi_natl smallint, mi_infr smallint ); -- -- TOC entry 8 (OID 37311) -- Name: camp_score; Type: ACL; Schema: public; Owner: postgres -- REVOKE ALL ON TABLE camp_score FROM PUBLIC; GRANT INSERT, SELECT, UPDATE ON TABLE camp_score TO mn; GRANT ALL ON TABLE camp_score TO mndb; GRANT SELECT ON TABLE camp_score TO mgr; GRANT INSERT, SELECT, UPDATE ON TABLE camp_score TO mnview; ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1247: pltcl.so does not exist in postgresql-pl RPM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 8 Sep 2004, PostgreSQL Bugs List wrote: PostgreSQL version: 7.4.3 Operating system: Redhat 9 and rhel3.0 Description:pltcl.so does not exist in postgresql-pl RPM package Details: I am executing "rpm -qpl postgresql-pl-7.4.5-1PGDG.i686.rpm" for redhat 9 and rhel3.0 RPM package, and the output command is: [EMAIL PROTECTED] rhel3]# rpm -qpl postgresql-pl-7.4.5-1PGDG.i686.rpm /usr/lib/pgsql/plperl.so /usr/lib/pgsql/plpython.so pltcl.so isn't into this RPM package!, I am finding into others RPM packages for the version 7.4.5 and plptcl.so library does not exist!. I've rebuilt packages for 7.4.5 (latest stable one on 7.4 branch) with tcl support for rhel3 and Red Hat 9. They will be on the main ftp site in an hour. They are labeled as -2PGDG. In addition to the previous set of RPMs, we again have -tcl package, and -pl package has pltcl.so. I haven't rebuilt rpms for 7.4.3 (your version), so it's time for an upgrade for you ;) Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBP4Kotl86P3SPfQ4RApZUAJ9ReFQ3RrEtrC3ErzpuivAnHGHThwCgqYes Ejp+YhFFbikDUnfx7imQoNo= =FtMv -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1248: pg_dump produces grants with concatonated elements
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> pg_dump produces the following grants:
> GRANT INSERTSELECTUPDATE ON TABLE camp_score TO mn;
Doesn't happen for anybody else...
> Obviously there are no commas or spaces seperating the different privs. I'm
> actually running the following version: PostgreSQL 7.3.6 on
> i386-pc-solaris2.8, compiled by cc -fast -xarch=386 -Xa
I'm wondering about a buggy compiler. The code involved is much too
simple to be broken: it's repeated calls to this:
static void
AddAcl(char *aclbuf, const char *keyword)
{
if (*aclbuf)
strcat(aclbuf, ",");
strcat(aclbuf, keyword);
}
If *aclbuf contains zero on entry, then why isn't the strcat overwriting
instead of appending? Looks like a compiler bug to me. What is "-fast"
and does the problem go away if you don't use it?
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [BUGS] PosgreSQL is crashing with a signal 11 - Bug?
[Tom Lane]: > > Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes: > > indeed interesting. IMHO 0x0fff sounds more like a write to -1 > > (relative to the next page) than a random memory error. > > Note though that that offset is only special with respect to > locations on disk; it was not a special address in memory. I'm > wondering about transient flakiness in your disk drive controller > causing it to sometimes return bad data. Have you run any > read/write disk tests? well, the hardware RAID1 controller claims the disks are healthy, but of course it would. I was unable to find any software to do such testing, the closest I got was badblocks(8), but it only wants to work on a block device. I hacked good old bonnie to write blocks of a random byte, then read them back and see if they match. I'll run a few such processes concurrently, we'll see if it suffices to trigger (and discover) any hardware bugs. -- Kjetil T. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] 8.0 incompatibility
Hi all, I'm observing that this piece of code doesn't work anymore in postgres 8.0 DECLARE quota RECORD; BEGIN FOR quota IN SELECT quota FROM foo LOOP END LOOP; the table foo have the field quota The error reported is: ERROR: record "quota" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is indeterminate. and is clear to me why. Shall not this be inserted in the release note ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Build failure: TIMEZONE_GLOBAL undeclared
A build of the latest CVS sources fails when compiling pgtz.c: gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -DFRONTEND -I../../src/include -I/usr/local/ssl/include -c -o pgtz.o pgtz.c pgtz.c: In function `get_timezone_offset': pgtz.c:99: error: `TIMEZONE_GLOBAL' undeclared (first use in this function) PostgreSQL 8.0.0beta2 (CVS) Solaris 9 gcc 3.4.1 gmake 3.80 src/timezone/pgtz.c 1.28 src/include/port.h 1.60 -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Permissions problem with sequences
On Mon, Sep 06, 2004 at 11:41:48PM -0400, Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > >> Given that pg_dump does put out GRANT/REVOKE operations on the sequence, > >> it's certainly aware that the sequence exists. I suspect this is just a > >> fixable bug (ie, suppression of output of the sequence CREATE command is > >> being done at the wrong place). > > > I'm trying to think of the solution here. > > One way is to allow the ArchiveEntry to be created (ie, suppress the > discrimination against owned sequences at pg_dump.c:7306) and instead > discriminate at the point of emitting the CREATE or DROP from the > ArchiveEntry ... but not when emitting an ALTER OWNER from it. I raised a question in my original post that I haven't seen discussed: Is failing to change the sequence ownership a bug in pg_dump, or should changing a table's ownership also change the ownership of implicitly-created sequences? That seems the most reasonable behavior to me: I'd expect that the cases where you wouldn't want this to happen would be the exception, not the rule. DROP TABLE cascades to implictly-created sequences -- why shouldn't ALTER TABLE OWNER TO cascade as well? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Permissions problem with sequences
Michael Fuhr <[EMAIL PROTECTED]> writes: > ... DROP TABLE cascades to implictly-created sequences -- why > shouldn't ALTER TABLE OWNER TO cascade as well? Hmm ... I hadn't thought of that approach, but it seems pretty reasonable offhand ... comments? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Permissions problem with sequences
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> Hmm ... I hadn't thought of that approach, but it seems pretty >> reasonable offhand ... comments? > What if they change the owner of the serial sequence independently > anyway? I suppose a complete solution would involve forbidding that. We don't allow you to alter the owner of an index independently of its parent table ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Permissions problem with sequences
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > I've got a mostly working fix for the bug that involves alter owner on > the sequence, but let me know if you want me to finish it. Please. We need to see the alternatives ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Build failure: TIMEZONE_GLOBAL undeclared
Michael Fuhr wrote: > A build of the latest CVS sources fails when compiling pgtz.c: > > gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations > -DFRONTEND -I../../src/include -I/usr/local/ssl/include -c -o pgtz.o pgtz.c > pgtz.c: In function `get_timezone_offset': > pgtz.c:99: error: `TIMEZONE_GLOBAL' undeclared (first use in this function) > > PostgreSQL 8.0.0beta2 (CVS) > Solaris 9 > gcc 3.4.1 > gmake 3.80 > src/timezone/pgtz.c 1.28 > src/include/port.h 1.60 Wow, that is confusing. How could TIMEZONE_GLOBAL not be defined? Is there some way port.h is not being included? If so I can't see it, and it compiles here fine, which is strange. Your file version numbers match mine though so you have all the versions I have. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
