Can we enable syslog support by default for 7.3?
AFAIR, we agreed to flip the default some time ago, we just didn't
want to do it late in the 7.2 cycle. Go for it.
I think if no one complains about the lack of syslog on his machine we
should just remove the option in 7.3+1.
My experience has been that logging to syslog makes postgres much
slower.
Can anyone confirm or refute this ?
Do you use synchronous write with syslog? Try to add a dash in
/etc/syslog.conf
e.g.
instead of
local3.* /var/log/syslog.postgres
use
On Fri, 2002-04-19 at 08:15, Tatsuo Ishii wrote:
Can we enable syslog support by default for 7.3?
AFAIR, we agreed to flip the default some time ago, we just didn't
want to do it late in the 7.2 cycle. Go for it.
I think if no one complains about the lack of syslog on his
On Thu, 18 Apr 2002, mlw wrote:
The days when head movement is relevant are long over. Not a single drive
sold today, or in the last 5 years, is a simple spindle/head system.
The assumption that sequentially reading a file from a modern disk drive means
that the head will move less
On Thu, 18 Apr 2002, Michael Loftis wrote:
mlw wrote:
The supposed advantage of a sequential read over an random read, in
an active multitasking system, is a myth. If you are executing one
query and the system is doing only that query, you may be right.
Execute a number of queries at the
On Fri, 2002-04-19 at 08:15, Tatsuo Ishii wrote:
Can we enable syslog support by default for 7.3?
AFAIR, we agreed to flip the default some time ago, we just didn't
want to do it late in the 7.2 cycle. Go for it.
I think if no one complains about the lack of syslog
On Thu, 18 Apr 2002, Alexandre Dulaunoy wrote:
Yes, I have read the faq. The 1.2 is not responding why the modified
Berkeley-style BSD license was choosen. There is only a respond :because
is like that...
You would have to ask the Regents of the University of California at
Berkeley, not us.
Tom Lane wrote:
Andreas Scherbaum [EMAIL PROTECTED] writes:
On the other hand, i copied some parts from contrib/noupdate (there'e no
licence in the readme) and now i think, this is contributed under BSD
licence.
I'm sure or i'm wrong? I think, i have to change the licence.
Who is the
Hi all,
I see there's a TODO item for large object security, it's a feature I'd really like to
see. I'm willing to put in the time to write a patch, but know far to little about
postgres internals and history to just dive in. Has there been any discussion on this
list about what this
On 04/18/2002 12:41:15 PM tycho wrote:
Don't know if the optimizer takes this into consideration, but a query that
uses a primary and/or unique key in the where-clause, should always choose to
use
the related indices (assuming the table size is above a certain threshold).
Since a
would'nt it be much better to expand pg_largeobject to have another column src_oid
(or similar), containing the OID of the referencing table from pg_class, and when
accessing large objects take the privilieges from the referencing class?
-Ursprüngliche Nachricht-
Von: Damon Cokenias
As some may know I will be talking about PostgreSQL on LinuxTag (6th of
June - 9th of June) in Karlsruhe, Germany. In particular I want to
address:
- The functionality of PostgreSQL
- Its stability and capability of handling large databases, ideally by
some case studies.
- Comparison to other
Tatsuo Ishii [EMAIL PROTECTED] writes:
In my understanding we are going to turn on the --enable-syslog
*configure* option by default (or remove the configuration option
completely), but not change the syslog option in postgresql.conf
(currently default to 0: that means not output to syslog).
Curt Sampson [EMAIL PROTECTED] writes:
Note also that one of the big problems we experienced was with clause
three of BSD-style licenses (the attribution clause).
Fortunately, Berkeley had already stopped using the advertising clause
when they tossed Postgres over the fence. Our version does
Mario Weilguni [EMAIL PROTECTED] writes:
would'nt it be much better to expand pg_largeobject to have another
column src_oid (or similar), containing the OID of the referencing
table from pg_class,
What referencing table? The existing LO implementation has no idea
where you are keeping the
Hi Tom,
One of the things I'd like this mechanism to do is answer the request
we've heard so often about preventing users from creating new tables.
If the DBA revokes write access on the public namespace from a particular
user, and doesn't create a personal schema for that user, then under
At 12:11 PM +0200 4/19/02, Mario Weilguni wrote:
would'nt it be much better to expand pg_largeobject to have another column src_oid
(or similar), containing the OID of the referencing table from pg_class, and when
accessing large objects take the privilieges from the referencing class?
It's
I've been poking at the scanner a bit using the large literal test case
from the other day
http://archives.postgresql.org/pgsql-hackers/2002-04/msg00811.php
I've been able to reduce the wall-clock run time of that test from 3:37
min to 2:13 min and the base_yylex() per-call time from 137ms to
Alvaro Herrera [EMAIL PROTECTED] writes:
http://archives.postgresql.org/pgsql-general/2001-09/msg00234.php
Nobody opposed to the idea of name ordering in that thread.
Okay, I've committed the fixes that implement this.
But note that this is on TODO:
* Allow user to control trigger firing
Tom Lane wrote:
Yeah. As of CVS tip, to reshuffle the order of existing triggers you
must (a) do a manual UPDATE pg_trigger SET tgname = 'something' ...
then (b) restart your backend(s), because the relcache code does not
notice that you did that, so it'll keep using the trigger data it
COMMENT ON DATABASE db IS 'Comment';
Now switch databases. Comment is gone.
Of course, adding the comments to template1 will carry comments
forward (in pg_description) to future DBs. Not fatal, but quite
annoying.
I suppose in order to add a comment field to pg_database it would need
to be
The problem with this is that the existing functionality of LOs allows
you to share a single LO across multiple tables. There may not be a
single source, but multiple. Since LOs just use an OID as a FK to the
LO, you can store that OID in multiple different tables.
--Barry
Mario Weilguni
Rod Taylor [EMAIL PROTECTED] writes:
COMMENT ON DATABASE db IS 'Comment';
Now switch databases. Comment is gone.
Yeah, it's not very helpful. I'm not sure why we bothered to implement
that in the first place.
I suppose in order to add a comment field to pg_database it would need
to be
Joe Conway wrote:
Tom Lane wrote:
Yeah. As of CVS tip, to reshuffle the order of existing triggers you
must (a) do a manual UPDATE pg_trigger SET tgname = 'something' ...
then (b) restart your backend(s), because the relcache code does not
notice that you did that, so it'll keep using
Peter Eisentraut [EMAIL PROTECTED] writes:
I've used 'flex -8 -CFa' and restructured the code to avoid looping over
and copying the input string half a dozen times. For instance, instead of
scanstr(), the escape sequences are resolved as the input is scanned, and
instead of the myinput()
Dear all,
I've been looking at tidying up some of the repeated code which now
resides in tablecmds.c - in particular the ALTER TABLE ALTER COLUMN
code.
Most of these routines share common code:
1) AccessExclusive Lock on relation.
2) Relation is a table, not a system table, user is owner.
3)
John Gray [EMAIL PROTECTED] writes:
Sequences still seem to work after they've had attributes renamed, but I
see little value in being able to do this. Is it OK to prohibit the
renaming of sequence columns?
That seems like an error to me. Setting defaults, constraints, etc on a
sequence is
John Gray wrote:
and two macros:
RECURSE_OVER_CHILDREN(relid);
AlterTableDoSomething(childrel,...);
RECURSE_OVER_CHILDREN_END;
(this seems more straightforward than passing the text of the function
call as a macro parameter).
Suggestion:
RECURSE_OVER_CHILDREN(inh, relid)
{
Joe Conway [EMAIL PROTECTED] writes:
There is already a RenameStmt node which is currently only used to
rename tables or table column names. Is there any objection to modifying
it to handle trigger names (and possibly other things in the future) also?
You'd need to add a field so you could
On Fri, 19 Apr 2002, Sander Steffann wrote:
I can't think of a reason that [creation of] temp tables should
be prevented.
Maybe to keep hostile users from filling up your disk?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new
At 10:48 AM 4/18/02 -0400, mlw wrote:
Bruce Momjian wrote:
Have you tried reducing 'random_page_cost' in postgresql.conf. That
should solve most of your problems if you would like more index scans.
My random page cost is 1 :-)
What happens when you set random page cost to 1? Between an
Curt Sampson [EMAIL PROTECTED] writes:
On Fri, 19 Apr 2002, Sander Steffann wrote:
I can't think of a reason that [creation of] temp tables should
be prevented.
Maybe to keep hostile users from filling up your disk?
That does come to mind --- but if you've let hostile users into
your
Lincoln Yeoh [EMAIL PROTECTED] writes:
...By the way, are updates treated the same as selects by the optimizer?
Yeah. The writes must occur in any case, so I see no reason why the
optimizer should worry about them. All it needs to consider are the
cycles used by the various alternatives for
Tom Lane writes:
I had the idea that -CF would enlarge the lexer tables quite a bit ---
what's the change in executable size?)
+150 kB
I've also looked at -CFe, which is supposedly the next slowest level, but
it doesn't do nearly as well.
--
Peter Eisentraut [EMAIL PROTECTED]
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
I had the idea that -CF would enlarge the lexer tables quite a bit ---
what's the change in executable size?)
+150 kB
I've also looked at -CFe, which is supposedly the next slowest level, but
it doesn't do nearly as well.
Ouch;
35 matches
Mail list logo
