[HACKERS] \c connects as another user instead I want in psql
This may be a reported bug. 7.1beta4. I use user names mostly as numbers. E.g. 1050, 1060, 1092. Sometimes I got strange result when I try to reconnect: tir= \c - 1022 You are now connected as new user 1022. tir= select user; current_user -- 1022 (1 row) (It's OK.) tir= \c - 1060 You are now connected as new user 1060. tir= select user; current_user -- 1092 (1 row) This is the problematic point. Is this a solved bug? TIA, Zoltan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, Apr 29, 2001 at 08:17:28PM -0700, Alfred Perlstein wrote: Sort of, if that flat file is in the form of: 123456;tablename 33;another_table Or better yet, since the flat file is unlikely to be large, you could just do this dance: 1) open file for reading 2) flock() file exclusively, non-blocking. 3) If 2 failed, sleep a bit, then go back to 1, otherwise open new file for writing 4) Write out new file 5) rename() the temp file over the new file 6) close files, etc That way, you'll never have the race of 2 programs trying to write the file at a time (therefore losing changes), and you get total atomicity of the writing. You could also do it with an open(O_EXCL) on a fixed temp file, instead of the flock() call. The semantics should be the same. Of course, you could always fork() a child to handle this in the background, as it's hardly important to the running of the database. (Or if it is, it can become part of the transaction, which means that at rename() time, there must be no room for other failures, but it mustn't be too late to roll back) -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] v7.1.1 branched and released on Tuesday ...
On Mon, Apr 30, 2001 at 07:12:16PM -0400, Tom Lane wrote: There will surely be a 7.1.2. I vote against waiting for it. Possibly, but one hopes 7.1.2 will be a few months away ... Is there a chance for the %TYPE patch for PL/pgSQL to make it into 7.1.2? -Roberto -- +| http://fslc.usu.edu USU Free Software GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer Junior, quit playing with your floppy! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Fsync Slashdot discussion
I am reading an interesting discussion about fsync() and disk flush on Slashdot. The discussion starts about log-based file systems, then moves to disk fsync about 20% into the discussion. Look for: Real issue is HARD DRIVE CACHEs All this discussion relates to WAL and our use of fsync(). There is also a mention of PostgreSQL: I just tried both about 3 weeks ago. I first tried reieserfs. Worked fine until I tried to load a postgresql database. Never finished after running all night--it realy thrashed the drive (I also run a RAID level 0 on the filesystem). Switched to xfs and everything ran great (db loaded in a few hours). Been running xfs ever since. I'd like to see xfs get put into the stock kernel along with reiserfs. It's possible my problems with reiserfs have since been fixed. Also, in reading the thread, it seems xfs is much more log-based than Reiser, so we may only have WAL/fsync() performance problems on xfs. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] New Linux xfs/reiser file systems
I was talking to a Linux user yesterday, and he said that performance using the xfs file system is pretty bad. He believes it has to do with the fact that fsync() on log-based file systems requires more writes. With a standard BSD/ext2 file system, WAL writes can stay on the same cylinder to perform fsync. Is that true of log-based file systems? I know xfs and reiser are both log based. Do we need to be concerned about PostgreSQL performance on these file systems? I use BSD FFS with soft updates here, so it doesn't affect me. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Thanks, naming conventions, and count()
Yes, I like that idea, but the problem is that it is hard to update just one table in the file. why not have just one ever-growing file that is only appended to and that has lines of form OID, type (DB/TABLE/INDEX/...), name, time so when you need tha actual info you grep for name and use tha last line whose file actually exists. Not too convenient but useful enough when you really need it. Yes, that is one idea, but it is hard to undo a change. You would have to write to the file only on a commit. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thanks, naming conventions, and count()
Bruce Momjian wrote: I can even think of a situation, as unlikely as it can be, where this could happen ... run out of inodes on the file system ... last inode used by the table, no inode to stick the symlink onto ... If you run out of inodes, you are going to have much bigger problems than symlinks. Sort file creation would fail too. its a remote situation, but I've personally had it happen ... I'd personally prefer to see some text file created in the database directory itself that contains the mappings ... so that each time there is a change, it just redumps that data to the dext file ... less to maintain overall ... Yes, I like that idea, but the problem is that it is hard to update just one table in the file. why not have just one ever-growing file that is only appended to and that has lines of form OID, type (DB/TABLE/INDEX/...), name, time so when you need tha actual info you grep for name and use tha last line whose file actually exists. Not too convenient but useful enough when you really need it. --- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] New Linux xfs/reiser file systems
The problem with log based filesystems is that they most likely do not know the consequences of a write so an fsync on a file may require double writing to both the log and the real portion of the disk. They can also exhibit the problem that an fsync may cause all pending writes to require scheduling unless the log is constructed on the fly rather than incrementally. Yes, this double-writing is a problem. Suppose you have your WAL on a separate drive. You can fsync() WAL with zero head movement. With a log based file system, you need two head movements, so you have gone from zero movements to two. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Collation order for btree-indexable datatypes
To avoid getting into states where a btree index is corrupt (or appears that way), it is absolutely critical that the datatype provide a unique, consistent sort order. In particular, the operators = = = had better all agree with each other and with the 3-way-comparison support function about the ordering of any two non-NULL data values. After tracing some Assert failures in the new planner statistics code I'm working on, I have realized that several of our existing datatypes fail to meet this fundamental requirement, and therefore are prone to serious misbehavior when trying to index weird values. In particular, type NUMERIC does not return consistent results for comparisons involving NaN values, and several of the date/time types do not return consistent results for comparisons involving INVALID values. (Example: numeric_cmp will assert that two NaNs are equal, whereas numeric_eq will assert that they aren't. Worse, numeric_cmp will assert that a NaN is equal to any non-NaN, too. The date/time routines avoid the latter mistake but make the former one.) I am planning to fix this by ensuring that all these operations agree on an (arbitrarily chosen) sort order for the weird values of these types. What I'm wondering about is whether to insert the fixes into 7.1.1 or wait for 7.2. In theory changing the sort order might break existing user indexes, and should therefore be avoided until an initdb is needed. But: any indexes that contain these values are likely broken already, since in fact we don't have a well-defined sort order right now for these values. A closely related problem is that the current time special value supported by several of the date/time datatypes is inherently not compatible with being indexed, since its sort order relative to ordinary time values keeps changing. We had discussed removing this special case, and I think agreed to do so, but it hasn't happened yet. What I'm inclined to do is force consistency of the comparison operators now (for 7.1.1) and then remove current time for 7.2, but perhaps it'd be better to leave the whole can of worms alone until 7.2. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] v7.1 error ... SELECT converted to a COPY?
The Hermit Hacker wrote: On Mon, 30 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Okay, maybe this query isn't quite as simple as I think it is, but does this raise any flags for anyone? How did I get into a COPY? It appears re-creatable, as I've done it twice so far ... eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber; Backend sent D message without prior T Backend sent D message without prior T At a guess, you're running out of memory on the client side for the SELECT results (did you really want a not-equal rather than equal constraint there!?) Yup, want to figure out which ones are in the egi table that I hadn't transfer'd over yet ... tried it with a NOT IN ( SELECT ... ) combination, but an explain of that showed two sequential searches on the tables, did you do it as select e.idnumber,e.password from egi e where e.idnumber not in (select idnumber from auth_info a where e.idnumber = a.idnumber) ; to smarten up the optimizer about using a join ? I guess that it can be done using outer joins and testing the outer2 part for IS NULL in 7.1 --- Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Linux xfs/reiser file systems
* Bruce Momjian [EMAIL PROTECTED] [010502 14:01] wrote: I was talking to a Linux user yesterday, and he said that performance using the xfs file system is pretty bad. He believes it has to do with the fact that fsync() on log-based file systems requires more writes. With a standard BSD/ext2 file system, WAL writes can stay on the same cylinder to perform fsync. Is that true of log-based file systems? I know xfs and reiser are both log based. Do we need to be concerned about PostgreSQL performance on these file systems? I use BSD FFS with soft updates here, so it doesn't affect me. The problem with log based filesystems is that they most likely do not know the consequences of a write so an fsync on a file may require double writing to both the log and the real portion of the disk. They can also exhibit the problem that an fsync may cause all pending writes to require scheduling unless the log is constructed on the fly rather than incrementally. There was also the problem that was brought up recently that certain versions (maybe all?) of Linux perform fsync() in a very non-optimal manner, if the user is able to use the O_FSYNC option rather than fsync he may see a performance increase. But his guess is probably nearly as good as mine. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html ---(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
[HACKERS] CVSUP - Problems?
I am unable to connect to the cvsup server. Are there problems? .. Otto Otto Hirr OLAB Inc. [EMAIL PROTECTED] 503 / 617-6595 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Collation order for btree-indexable datatypes
I am planning to fix this by ensuring that all these operations agree on an (arbitrarily chosen) sort order for the weird values of these types. What I'm wondering about is whether to insert the fixes into 7.1.1 or wait for 7.2. In theory changing the sort order might break existing user indexes, and should therefore be avoided until an initdb is needed. But: any indexes that contain these values are likely broken already, since in fact we don't have a well-defined sort order right now for these values. What I'm inclined to do is force consistency of the comparison operators now (for 7.1.1) and then remove current time for 7.2, but perhaps it'd be better to leave the whole can of worms alone until 7.2. Comments anyone? Assuming that the changes are reasonably safe, I think you're right. What parts of the changes would require an initdb, would new functions need to be added or the index ops need to change or would it be fixes to the existing functions (if the latter, wouldn't a recompile and dropping/recreating the indexes be enough?) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] XFS File systems and PostgreSQL
I have been using PostgreSQL and XFS file systems on SGI's for many years, and PostgreSQL is fast. Dumping and loading 100GB of table files takes less than one day elapsed (provided there is no other activity on that database -- large amounts of transactional activity will slow things down). I always turn off fsync. Most of my experience has been with 6.5.3, although I've been using 7.1 and I don't see much of a difference in performance. I don't know if the Linux version of XFS is substantially different than the SGI version, but XFS is a wonderful filesystem to use and administer (at least on SGI's). +--++ | Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383| | President, Congenomics, Inc. | Fax: 609 737 7528| | 114 W Franklin Ave, Suite K1,4,5 | email: [EMAIL PROTECTED]| | P.O. Box 314 | URL: http://www.congen.com/~bruc | | Pennington, NJ 08534 || +--++ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] \c connects as another user instead I want in psql
Kovacs Zoltan [EMAIL PROTECTED] writes: tir= \c - 1060 You are now connected as new user 1060. tir= select user; current_user -- 1092 (1 row) Is it possible that 1060 and 1092 have the same usesysid in pg_shadow? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] XFS File systems and PostgreSQL
I have been using PostgreSQL and XFS file systems on SGI's for many years, and PostgreSQL is fast. Dumping and loading 100GB of table files takes less than one day elapsed (provided there is no other activity on that database -- large amounts of transactional activity will slow things down). I always turn off fsync. Most of my experience has been with 6.5.3, although I've been using 7.1 and I don't see much of a difference in performance. I don't know if the Linux version of XFS is substantially different than the SGI version, but XFS is a wonderful filesystem to use and administer (at least on SGI's). Yes, but you turn off fsync. It is with fsync on that XFS will be slow. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Collation order for btree-indexable datatypes
On Wed, 2 May 2001, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: What parts of the changes would require an initdb, would new functions need to be added or the index ops need to change or would it be fixes to the existing functions (if the latter, wouldn't a recompile and dropping/recreating the indexes be enough?) Yes, dropping and recreating any user indexes that contain the problematic values would be sufficient to get you out of trouble. We don't need any system catalog changes for this, AFAICS. Looking back, I misread the original message. I thought you were saying that it needed to wait for an initdb and so would be bad in a dot release, but it was just the breaking of indexes thing, but since they're already pretty broken, I don't see much of a loss by fixing it. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] XFS File systems and PostgreSQL
[EMAIL PROTECTED] (Robert E. Bruccoleri) writes: I have been using PostgreSQL and XFS file systems on SGI's for many years, and PostgreSQL is fast. Dumping and loading 100GB of table files takes less than one day elapsed (provided there is no other activity on that database -- large amounts of transactional activity will slow things down). I always turn off fsync. ^^^ Then your performance numbers are largely useless for those of us that like our data. ;) The point at issue is the performance of fsync() on journaling filesystems... -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] New Linux xfs/reiser file systems
* Bruce Momjian [EMAIL PROTECTED] [010502 15:20] wrote: The problem with log based filesystems is that they most likely do not know the consequences of a write so an fsync on a file may require double writing to both the log and the real portion of the disk. They can also exhibit the problem that an fsync may cause all pending writes to require scheduling unless the log is constructed on the fly rather than incrementally. Yes, this double-writing is a problem. Suppose you have your WAL on a separate drive. You can fsync() WAL with zero head movement. With a log based file system, you need two head movements, so you have gone from zero movements to two. It may be worse depending on how the filesystem actually does journalling. I wonder if an fsync() may cause ALL pending meta-data to be updated (even metadata not related to the postgresql files). Do you know if reiser or xfs have this problem? -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Collation order for btree-indexable datatypes
Stephan Szabo [EMAIL PROTECTED] writes: What parts of the changes would require an initdb, would new functions need to be added or the index ops need to change or would it be fixes to the existing functions (if the latter, wouldn't a recompile and dropping/recreating the indexes be enough?) Yes, dropping and recreating any user indexes that contain the problematic values would be sufficient to get you out of trouble. We don't need any system catalog changes for this, AFAICS. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] XFS File systems and PostgreSQL
[EMAIL PROTECTED] (Robert E. Bruccoleri) writes: I have been using PostgreSQL and XFS file systems on SGI's for many years, and PostgreSQL is fast. Dumping and loading 100GB of table files takes less than one day elapsed (provided there is no other activity on that database -- large amounts of transactional activity will slow things down). I always turn off fsync. ^^^ Then your performance numbers are largely useless for those of us that like our data. ;) The point at issue is the performance of fsync() on journaling filesystems... Yes, the irony is that a journaling file system is being used to have fast, reliable restore after crash bootup, but with no fsync, the db is probably hosed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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: [HACKERS] XFS File systems and PostgreSQL
Bruce Momjian [EMAIL PROTECTED] writes: Yes, the irony is that a journaling file system is being used to have fast, reliable restore after crash bootup, but with no fsync, the db is probably hosed. It just struck me--is it necessarily true that we get the big performance hit? On a non-data-journaling FS (like ext3), since WAL files are preallocated (right?), a WAL sync shouldn't involve any metadata updates. So we just write the WAL data to a (hopefully contiguous) chunk of data blocks. On an FS that journals data AND metadata, fsync() can return once the updates are committed to the log--it doesn't have to wait until the log is back-flushed (or whatever you call it) to the main filesystem. The above is theoretical, and I don't know enough about Reiser or XFS to know how they behave. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] XFS File systems and PostgreSQL
Dear Bruce, Yes, the irony is that a journaling file system is being used to have fast, reliable restore after crash bootup, but with no fsync, the db is probably hosed. There is no irony in these cases. In my systems, which are used for bioinformatics, the updating process is generally restartable. I normally have lots of data to load or many records to change, and the quantities are much more than any reasonable sized transaction. Some jobs run for days. If I lose some data because of a crash, I just restart the jobs, and they'll delete some of the last data to be loaded, and then resume. Furthermore, the SGI's that I run on are highly reliable, and they rarely crash. So, I might have to clean up a big mess rarely (I've had one really big one in two years), but performance otherwise is really good. I should also point out that most of my work has been with PostgreSQL 6.5.3 which doesn't have the WAL. If I have some time, I will try the experiment of loading a database of mine into PG 7.1 using -F or not and I'll report the timing. +--++ | Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383| | President, Congenomics, Inc. | Fax: 609 737 7528| | 114 W Franklin Ave, Suite K1,4,5 | email: [EMAIL PROTECTED]| | P.O. Box 314 | URL: http://www.congen.com/~bruc | | Pennington, NJ 08534 || +--++ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] XFS File systems and PostgreSQL
Bruce Momjian [EMAIL PROTECTED] writes: Yes, the irony is that a journaling file system is being used to have fast, reliable restore after crash bootup, but with no fsync, the db is probably hosed. It just struck me--is it necessarily true that we get the big performance hit? On a non-data-journaling FS (like ext3), since WAL files are preallocated (right?), a WAL sync shouldn't involve any metadata updates. So we just write the WAL data to a (hopefully contiguous) chunk of data blocks. On an FS that journals data AND metadata, fsync() can return once the updates are committed to the log--it doesn't have to wait until the log is back-flushed (or whatever you call it) to the main filesystem. The above is theoretical, and I don't know enough about Reiser or XFS to know how they behave. Theoretically, yes, all these log-based file system just log metadata changes, not user data, so it should not affect it. I just don't know how well the fsync's are implemented on these things. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Collation order for btree-indexable datatypes
Bruce Momjian [EMAIL PROTECTED] writes: Comparing NaN/Invalid seems so off the beaten path that we would just wait for 7.2. That and no one has reported a problem with it so far. Do you consider vacuum analyze on the regression database to be off the beaten path? How about creating an index on a numeric column that contains NaNs, or a timestamp column that contains Invalid? Unless you believe these values are not being used in the field at all, there's a problem. (And if you do believe that, you shouldn't be worried about my changing their behavior ;-)) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Permissions problem
Hi,
There seems to be a minor bug related to permissions. If you create a
table and grant permissions on that table to someone else, you lose your
own permissions (note: do this as a non-dbadmin account):
testdb= create table tester ( test int4 );
CREATE
testdb= insert into tester values ('1');
INSERT 17109139 1
testdb= grant select on tester to someone;
CHANGE
testdb= insert into tester values ('2');
ERROR: tester: Permission denied.
testdb=
From postgres/sql-grant.htm:
Description
GRANT allows the creator of an object to give specific permissions to
all users (PUBLIC) or to a certain user or group. Users other than
the creator don't have any access permission unless the creator
GRANTs permissions, after the object is created.
Once a user has a privilege on an object, he is enabled to exercise
that privilege. There is no need to GRANT privileges to the creator
of an object, the creator automatically holds ALL privileges, and can
also drop the object.
It's not behaving as documented (There is no need to GRANT privileges
to the creator of an object).
This is in postgresql-7.0.3, but it's possible this is fixed in a more
recent version - can someone try this and see what happens ?
Cheers,
Chris.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Permissions problem
Chris Dunlop [EMAIL PROTECTED] writes: There seems to be a minor bug related to permissions. If you create a table and grant permissions on that table to someone else, you lose your own permissions (note: do this as a non-dbadmin account): This is fixed in 7.1. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
