Greg Smith wrote:
On Tue, 3 Apr 2007, Peter Eisentraut wrote:
Something that is aimed at a user should not be enabled at a debug
level. Debug levels are for debugging, not for very high verbosity.
I asked for feedback about where to log at when I intially sent the
first version of this in
On 5/11/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I agree that debug levels are not suitable for this.
Squid (the (reverse) proxy) has a nice feature for debugging purposes
(admin and developers). It's possible to have different logging level
for different sections of the code. For
Guillaume Smet wrote:
On 5/11/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I agree that debug levels are not suitable for this.
Squid (the (reverse) proxy) has a nice feature for debugging purposes
(admin and developers). It's possible to have different logging level
for different sections
On Fri, 11 May 2007, Heikki Linnakangas wrote:
Printing the messages at LOG-level would bring the code in line with the
documentation, but I don't think we want to fill the log with checkpoint
chatter unless the DBA explicitly asks for that. How about INFO?
In putting that together, I
Fixed the major omissions that made it incomplete.
- Added sgml documentation and \? usage
- Added basic mvcc regression tests using new functionality
- Fixed cursor-mode (FETCH_COUNT) functionality
- Removed \cwait in favour of psql variable ASYNC_DELAY
I'm still not sure it's quite polished
Greg Smith wrote:
On Fri, 11 May 2007, Heikki Linnakangas wrote:
Or we could add a GUC variable similar to log_connections or
log_statement to control if the messages are printed or not, and use LOG.
If the levels for the individual messages are adjusted usefully the
ability to control
Heikki Linnakangas wrote:
We already played the name game on hackers. My original suggestion was
pgforensics. pgdiagfuncs and pginspect were also suggested, among
others. I'm still open to suggestions, though. Have any?
Something involving page would at least explain what you can
Andrew Dunstan [EMAIL PROTECTED] writes:
Attached is my rework of David Fetter's array of composites patch. It
has all the agreed modifications and checks, except altering the name
mangling.
Applied with revisions. There are some loose ends yet:
* I didn't do anything about arrays of
Awhile back I wrote:
I did some tests just now to determine the total number of catalog
entries associated with a simple table definition. Assuming it has
N user columns of built-in types (hence not requiring pg_depend entries
for the datatypes), I count
1 pg_class entry for the table
Tom Lane [EMAIL PROTECTED] writes:
* I'm a bit concerned about dump order. If a user wants to create
types named foo and _foo, he can, but it will only work if he
makes _foo first --- else the derived type for foo is in the way.
Since pg_dump has no clue about that constraint, it might
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's not really the most preferable solution, I think, seeing that it
still leaves the user with the problem of having to create the types in
the right order to start with.
I'm not sure we can
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's not really the most preferable solution, I think, seeing that it
still leaves the user with the problem of having to create the types in
the right order to start with.
I'm not sure we can keep the _foo convention and avoid that.
Tom Lane wrote:
There is *tons* of legacy code that uses _foo, mainly because there was
a time when we didn't support the [] notation in a lot of places where
types can be named. There still are some places, in fact:
regression=# alter type widget[] set schema public;
ERROR: syntax error at
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Auto-rename. I'm working on a patch now, and it doesn't look like it'll
be too awful. Will post it for comments when it's working.
Ok, cool. I look forward to it.
Here's a bare-bones patch (no doc or regression tests). Seems to
Tom Lane wrote:
Perhaps a better solution is to keep MAX_REPORTED_DEPS where it is, and
arrange that when it's exceeded, the *entire* list of dependencies gets
reported to the postmaster log; we can expect that that will work.
We still send the same just-the-count message to the client. We
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
* I'm a bit concerned about dump order. If a user wants to create
types named foo and _foo, he can, but it will only work if he
makes _foo first --- else the derived type for foo is in the way.
Since pg_dump has no clue about that
I posted a doc update a while ago to mention that CLUSTER isn't MVCC-safe:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00137.php
CLUSTER is now MVCC-safe in CVS HEAD, but the documentation for older
releases should still be updated.
--
Heikki Linnakangas
EnterpriseDB
Alvaro Herrera [EMAIL PROTECTED] writes:
Sample output to the client (note: in this test, MAX_REPORTED_DEPS is
set to 10).
...
foo=# drop user foo;
ERROR: role foo cannot be dropped because some objects depend on it
DETAIL: owner of tablespace foo
owner of table a100
owner of table a99
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Auto-rename. I'm working on a patch now, and it doesn't look like it'll
be too awful. Will post it for comments when it's working.
Ok, cool. I look forward to it.
Here's a bare-bones patch
Andrew Dunstan [EMAIL PROTECTED] writes:
Summarising the behaviour as I understand it:
. if you never name a type/table with a name beginning with underscore,
behaviour is as expected - type foo gets array type _foo
. if you create a type foo and then create a type _foo, the array type
for
Tom Lane wrote:
I think I like it. Certainly seems to get round the ordering problem nicely.
At least as far as the user's names are concerned. There's some
ordering dependency for the names that the array types end up with,
but we had that problem already; and AFAIK it shouldn't
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
BTW, why exactly do we need array types to have names at all?
Because typname is part of the primary key for pg_type ...
The only
user-visible way to refer to these types is always by foo[] isn't it?
I think you can use the _foo
Andrew Dunstan [EMAIL PROTECTED] writes:
There will only be an issue if you use table/type names beginning with
underscore, right? And I don't think it will matter because nobody has
been relying on that to date as we haven't had array types for those. We
should probably document that
On 10 May 2007, at 03:09, Alvaro Herrera wrote:
FWIW I think you should still provide dblink_current_query, even if
it's
only a wrapper over current_query(), for backwards compatibility.
Good point. Done as suggested (I think, or did you mean also the
change of instances to use
On Wednesday 09 May 2007 19:41, Guillaume Smet wrote:
On 5/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Any time this happens it's generally a nasty surprise for users.
Really? Running out of work memory is expected on large tables.
Sure. Perhaps we
25 matches
Mail list logo
