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.
r
If you feel strongly about it, go ahead. I didn't see any problem
reports on it, and it seemed kind of iffy, so I thought we should hold
it.
> 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 ha
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 val
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 i
> 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
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
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
> [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 --
> > 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 fi
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 enoug
* 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 ex
[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 amoun
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
>
> 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 do
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
> 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 th
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 al
> 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
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.ht
* 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 B
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, a
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 a
> 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
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
> > 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 g
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 per
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 fsyn
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
--
+
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
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 - 1
30 matches
Mail list logo
