Well, we should *at least* provide it from the source
build. Since it
does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab
completion!
(which the gui tools don't do either, from what I can tell.
At least
pgadmin doesn't.
On Mon, 2006-01-02 at 16:48 -0500, Tom Lane wrote:
The two compromises that were made in the original stats design to make
it fast were (1) stats updates lag behind reality, and (2) some updates
may be missed entirely. Now that we have a couple of years' field
experience with the code, it
On Thu, 2005-12-22 at 12:12 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Currently, CTAS optimization requires a heap_sync during ExecEndPlan. It
would be easy enough to extend this so that it also works for INSERT,
UPDATE and DELETE.
If you tried to do it that way you'd
On Thu, Dec 29, 2005 at 11:24:28AM -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Andrew Dunstan wrote:
I an horribly scared that this will be used as a performance boost for
normal use. I would at least like to see some restrictions that make it
harder to mis-use.
On Fri, Dec 30, 2005 at 12:58:15PM -0500, Bruce Momjian wrote:
Andrew Dunstan wrote:
My concern is more about making plain that this is for special operations,
not normal operations. Or maybe I have misunderstood the purpose.
Rephrase that as full ownership rights must be
If nothing else, this should at least be documented in
http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL
On Fri, Dec 30, 2005 at 07:32:18PM +0100, Magnus Hagander wrote:
Haven't seen this discussed in a while, but I do recall it being
mentioned sometime before...
On Sun, Jan 01, 2006 at 09:03:00PM +0100, Andreas Pflug wrote:
Marc G. Fournier wrote:
On Sun, 1 Jan 2006, Tom Lane wrote:
I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php
While I haven't tried it, I suspect that allowing a DNS host name
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
I dislike restricting to super-user, and to some extent even table
owner. The reason is that if you have some automated batch process, you
don't want that process running as a superuser. Also, it is often
awkward to require that the user running that
Jim C. Nasby [EMAIL PROTECTED] writes:
Dumb question: if the ALTER is done inside a transaction, and then
reverted at the end of the transaction, does that mean that no other
transactions would have those permissions? I think the general use-case
is that you only one the session doing the
On Sun, Jan 01, 2006 at 08:37:02PM -0500, Tom Lane wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
On Sun, 1 Jan 2006, Tom Lane wrote:
Aren't they all known issues? You need to be a lot clearer about what
distinction you intend to draw, and why it's so important that it
deserves to be the
Stephen Frost [EMAIL PROTECTED] writes:
In general, I do prefer that permissions be seperably grantable. Being
able to grant 'truncate' permissions would be really nice. Is the only
reason such permission doesn't exist due to no one working on it, or is
there other disagreement about it?
On Tue, Jan 03, 2006 at 09:40:53AM +, Simon Riggs wrote:
On Mon, 2006-01-02 at 16:48 -0500, Tom Lane wrote:
We can also save lots of cycles on the current statement overhead, which
is currently the worst part of the stats, performance-wise. That
definitely needs redesign. AFAICS we only
On Tue, Jan 03, 2006 at 11:29:02AM -0500, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
In general, I do prefer that permissions be seperably grantable. Being
able to grant 'truncate' permissions would be really nice. Is the only
reason such permission doesn't exist due to no
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Dumb question: if the ALTER is done inside a transaction, and then
reverted at the end of the transaction, does that mean that no other
transactions would have those permissions? I think the
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Such an ALTER would certainly require exclusive lock on the table,
so I'm not sure that I see much use-case for doing it like that.
You'd want to do the ALTER and commit so as not to lock other
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
In general, I do prefer that permissions be seperably grantable. Being
able to grant 'truncate' permissions would be really nice. Is the only
reason such permission doesn't exist due to no one working on it, or
--- Jim C. Nasby [EMAIL PROTECTED] escreveu:
I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be
looked
up from /etc/hosts, but not from generic DNS. AFAIK that would
eliminate
the possibility of spoofing.
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
Yeah, I hadn't thought about that. I agree; if you trust some process
enough to have MVCC-affecting rights then you should be able to trust it
with full ownership rights.
About that, I have to disagree. :) I've got a case where this isn't
true, see my
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Such an ALTER would certainly require exclusive lock on the table,
so I'm not sure that I see much use-case for doing it like that.
You'd want to do the ALTER and commit so as
Euler Taveira de Oliveira wrote:
--- Jim C. Nasby [EMAIL PROTECTED] escreveu:
I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be
looked
up from /etc/hosts, but not from generic DNS. AFAIK that would
Stephen Frost [EMAIL PROTECTED] writes:
The problem is that you might want to grant 'truncate' to people who
*aren't* particularly trusted. For truncate, at least I have a
real-world use-case for it.
I don't find this use-case particularly convincing. If the users are
allowed to delete all
Andrew Dunstan [EMAIL PROTECTED] writes:
One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit.
A possible answer to that is to *not* look up
On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could
Tom Lane schrieb:
Andrew Dunstan [EMAIL PROTECTED] writes:
One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit.
A possible answer to
[EMAIL PROTECTED] writes:
On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
I'm not sure about the relative usefulness of this compared to the
forward-lookup case, nor whether it's riskier or less risky from a
spoofing point of view. But something to consider.
I think it's riskier.
The issue is folks that DON'T set reverse DNS, I.E. have generic rDNS
set on their IP's.
I've seen (in my ISP days, and on my mailserver) LOTS of folks that
can't/won't update
Their rDNS, even though it's a STATICLY assigned address.
And, as an example, my house IP changes when the PPPoE moves,
* Tom Lane ([EMAIL PROTECTED]) wrote:
I don't find this use-case particularly convincing. If the users are
allowed to delete all data in a given table, then that table must be
dedicated to them anyway; so it's not that easy to see why you can't
risk giving them ownership rights on it. The
I fixed the patch and now it compiles in windows.
The first one did not compile because there were some problems in the
Makefile.
It is currently available for download at
http://gorda.di.uminho.pt/community/pgsqlhooks/.
Regards,
Alfranio
---(end of
I just noticed that the stats buffer process is consuming 100% cpu as
soon as a backend is started, and continues after that backend is ended:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
15150 postgres 25 0 27004 948 508 S 99.9 0.0 0:30.97 postmaster
# ps -ef
Interesting. Here is the patch I just applied:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.116r2=1.117
The only guess I have is that select() is modifying the timeout
structure on return, but I didn't think it did that, does it?
Googling
On Tue, 3 Jan 2006, Tino Wildenhain wrote:
One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit.
A possible answer to that is to *not* look up
Bruce Momjian pgman@candle.pha.pa.us writes:
The only guess I have is that select() is modifying the timeout
structure on return, but I didn't think it did that, does it?
You shouldn't assume so; I think it does on some platforms. The Single
Unix Spec says
On successful completion,
On Tue, Jan 03, 2006 at 12:08:05PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Such an ALTER would certainly require exclusive lock on the table,
so I'm not sure that I see much use-case
Jim C. Nasby wrote:
I don't think it should (which implies that EXCLUSIVE is a bad name).
Agreed, EXCLUSIVE was used to mean an _exclusive_ writer. The new words
I proposed were PRESERVE or STABLE.
This seems to seriously limit the usefulness, though. You'll only want
to use
On Tue, Jan 03, 2006 at 04:20:47PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
I don't think it should (which implies that EXCLUSIVE is a bad name).
Agreed, EXCLUSIVE was used to mean an _exclusive_ writer. The new words
I proposed were PRESERVE or STABLE.
This seems to
I am writing to you all just to inform you of a bug(probably), that I
came across while trying to install PostgreSQL 8.1.0-2 and 8.1.1-1 on
WinXP with SP2, using the PostgreSQL installer.
I had done a windows clean install and then installed straight away
PostgreSQL 8.0.4. It was the only
On Tue, Jan 03, 2006 at 12:08:46 -0600,
Larry Rosenman [EMAIL PROTECTED] wrote:
The issue is folks that DON'T set reverse DNS, I.E. have generic rDNS
set on their IP's.
I've seen (in my ISP days, and on my mailserver) LOTS of folks that
can't/won't update
Their rDNS, even though it's a
Bruno Wolff III wrote:
On Tue, Jan 03, 2006 at 12:08:46 -0600,
Larry Rosenman [EMAIL PROTECTED] wrote:
The issue is folks that DON'T set reverse DNS, I.E. have generic
rDNS set on their IP's.
I've seen (in my ISP days, and on my mailserver) LOTS of folks that
can't/won't update Their
Jim C. Nasby wrote:
We would be creating a new lock type for this.
Sorry if I've just missed this in the thread, but what would the new
lock type do? My impression is that as it stands you can either do:
BEGIN;
ALTER TABLE EXCLUSIVE;
...
ALTER TABLE SHARE; --fsync
COMMIT;
Which
On Fri, 2005-12-30 at 16:14 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
The implications of EXCLUSIVE are:
- there will be a check on each and every I, U, D to check the state of
the relation
- *every* operation that attempts a write lock will attempt to acquire
an EXCLUSIVE full
On Tue, 2006-01-03 at 16:20 -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
Idealistically, if EXCLUSIVE/PRESERVE/STABLE does it's thing by only
appending new pages, it would be nice if other backends could continue
performing updates at the same time, assuming there's free space
On Tue, 2006-01-03 at 17:38 -0500, Bruce Momjian wrote:
Right, the DML will be single-threaded and fsync of all dirty pages will
happen before commit of each transaction.
heap_sync() would occur at end of statement, as it does with CTAS. We
could delay until EOT but I'm not sure I see why; in
Jim C. Nasby [EMAIL PROTECTED] writes:
I would argue that minutes is too long, but of course this could be
user-adjustable. I suspect that even waiting just a second could be a
huge win, since this only matters if you're executing a lot of
statements and you won't be doing that if those
On Sat, 2005-12-31 at 12:59 +0100, Michael Paesold wrote:
Bruce Momjian wrote:
The --single-transaction mode would apply even if the dump was created
using an earlier version of pg_dump. pg_dump has *not* been altered at
all. (And I would again add that the idea was not my own)
I
On Thu, 2005-12-29 at 11:37 -0500, Bruce Momjian wrote:
Having COPY behave differently because it is
in a transaction is fine as long as it is user-invisible, but once you
require users to do that to get the speedup, it isn't user-invisible
anymore.
Since we're agreed on adding ALTER TABLE
Bruce,
Basically meaning your idea of update while
EXCLUSIVE/PRESERVE/STABLE is happening is never going to be
implemented because it is just too hard to do, and too prone to
error.
What I figured. Never hurts to ask though. :):)
Actually, it does hurt because it generates
Folks,
Just got tripped up by this:
GRANT SELECT ON table1 TO someuser;
GRANT SELECT ON table1_id_seq TO someuser;
both work
However,
GRANT SELECT ON TABLE table1 TO someuser;
... works, while
GRANT SELECT ON SEQUENCE table1_id_seq TO someuser;
... raises an error.
This is
Folks,
I just stumbled across a little problem that looks like this:
CREATE TABLE foo (
id SERIAL PRIMARY KEY,
f_text TEXT NOT NULL
);
CREATE UNIQUE INDEX uniq_foo_f_text ON foo(LOWER(TRIM(f_text)));
COPY foo(f_text) FROM stdin;
a
b
c
\.
Oh, shucks. I'd like to permute these. Lemme
David Fetter said:
Is there some way to make the index check INITIALLY DEFERRABLE the way
a regular column/table constraint could be?
I'd much appreciate any insights into this :)
The docs say: Only foreign key constraints currently accept this clause.
All other constraint types are not
--- Josh Berkus josh@agliodbs.com escreveu:
However,
GRANT SELECT ON TABLE table1 TO someuser;
... works, while
GRANT SELECT ON SEQUENCE table1_id_seq TO someuser;
... raises an error.
This is inconsistent. Do people agree with me that the parser
should
accept SEQUENCE there,
On Jan 3, 2006, at 19:45 , David Fetter wrote:
Dang! Everything was going to be kosher at the end of the
transaction, but I never got a chance.
Is there some way to make the index check INITIALLY DEFERRABLE the way
a regular column/table constraint could be?
Happy New Year, David!
I've
On 12/26/05 11:04, Qingqing Zhou wrote:
Gregor Zeitlinger [EMAIL PROTECTED] wrote
Also, I was wondering whether it is always safe to copy the current WAL
file, i.e. may the current WAL file be invalid in any circumstance?
If you mean current WAL file is the xlog segment in use, then it is
Andrew Dunstan [EMAIL PROTECTED] writes:
David Fetter said:
Is there some way to make the index check INITIALLY DEFERRABLE the way
a regular column/table constraint could be?
The TODO list has: Allow DEFERRABLE UNIQUE constraints?
send in a patch ;-)
This is definitely on the wish-list,
Josh Berkus wrote:
Bruce,
Basically meaning your idea of update while
EXCLUSIVE/PRESERVE/STABLE is happening is never going to be
implemented because it is just too hard to do, and too prone to
error.
What I figured. Never hurts to ask though. :):)
Actually, it does
On Tue, Jan 03, 2006 at 11:17:16PM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
David Fetter said:
Is there some way to make the index check INITIALLY DEFERRABLE
the way a regular column/table constraint could be?
The TODO list has: Allow DEFERRABLE UNIQUE
How about:
use Online backup or Hot backup to refer to either method of back
since they are both done while the system is online or hot.
If you want to get specific refer to doing a sql dump etc for using
pg_dump
Then use Incremental backup to refer to the whole process of the
WAL
I think it would all make more sense if we described the use of
archive_command = something as being in WAL Archive Mode. That would
then allow us to say:
You can only take Online Backups while in WAL Archive Mode.
If you ever wish to perform PITR, you must use WAL Archive Mode.
If you backed-up
I would certainly like some instructions on this as well.
On Jan 3, 2006, at 8:41 PM, Zach Bagnall wrote:
On 12/26/05 11:04, Qingqing Zhou wrote:
Gregor Zeitlinger [EMAIL PROTECTED] wrote
Also, I was wondering whether it is always safe to copy the
current WAL file, i.e. may the current WAL
58 matches
Mail list logo
