Jim C. Nasby wrote:
Same with pgAdmin3.
Is there a list of specific projects? I'm pretty sure we can't just say
"work on (pgp)PgAdmin...
Our TODO list has some.
Regards,
Andreas
---(end of broadcast)---
TIP 1: if posting/reading thr
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a good SoC project, but should it also be added to the TODO list?
I may as well put up phpPgAdmin for it. We have plenty of projects
available in phpPgAdmin...
Same with pgAdmin3.
R
Jim C. Nasby wrote:
On Thu, Apr 13, 2006 at 04:39:59AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Bruno Almeida do Lago wrote:
After that night, I started to ask myself if PostgreSQL should not have a
control file to check if expected datafiles are where they shoul
Eric Lauzon wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Merlin Moncure
Sent: 12 avril 2006 12:22
To: Neil Conway
Cc: Tom Lane; David Fetter; Jim C. Nasby; Joshua D. Drake;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKE
Tom Lane wrote:
Martijn van Oosterhout writes:
1. Changing it to always return (void*), irrespective of SSL
...
Personally, I'm in favour of 1, because then we can get rid of the
#include for openssl, so users don't have to have openssl headers
installed to compile postgresql programs.
I li
Dave Page wrote:
Keeping PostgreSQL as secure as possible out of the box pretty much
requires us to do the same in my mind - if an major feature such as
pl/pgsql is easy for the user to enable should they want it, then it
should be disabled by default to minimise the number of attack vectors
Thomas Hallgren wrote:
Luke Lonergan wrote:
Tom,
On 3/17/06 9:59 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
This would buy what exactly?
I guess you didn't read the other 80% of the post.
In short, faster performance through more aggressive runtime
compilation. A
JIT for the database k
Ben Chelf wrote:
Hello PostgreSQL Developers,
I'm the CTO of Coverity, Inc., a company that does static source code
analysis to look for defects in code. You may have heard of us or of our
technology from its days at Stanford (the "Stanford Checker"). The
reason I'm writing is because we ha
Albe Laurenz wrote:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set,
A little off-topic, but related: PeterE recently complained about an
option in pgAdmin which is called "service". Its na
Peter Eisentraut wrote:
Am Mittwoch, 22. Februar 2006 09:06 schrieb Dave Page:
As an example, pgAdmin uses this info to automatically register any
local installations.
Curiously enough, pgAdmin already has a "Service" field in its connection
dialog, but I guess that isn't the same thing. T
Mark Woodward wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt
Tino Wildenhain wrote:
Figuring out the correct values for some of the buffers and costs
is still a bit tough. Otoh, I guess there is no easy way to predict
all these.
pgAdmin has a mechanism to suggest values (currently for autovacuum and
listen_address only), which waits for expansion :-)
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
would take little work (basically removing the AI_NUMERICHOST flag
passed
Tom Lane wrote:
Martijn van Oosterhout writes:
Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new f
Martijn van Oosterhout wrote:
So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's "best practice" on windows in
this area.
When removing the application (in this case: pgsql), you'd remove that
old lib as well if it's the only app u
Peter Eisentraut wrote:
Letting createuser.c hash the password would be the biggest win.
Both of these things are now done, and I have sent notices to pgadmin
and phppgadmin asking for equivalent adjustments.
Um, didn't receive a notice.
I'm a little uncomfortable using an arbitrary md5 al
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
There wasn't any obvious bang for the buck in rewriting it.
Well a non-binary copy could take as much as 5 times as much as a binary
copy. I hit this when COPYing 1.5GB of data, getting a 6.6GB file. Thi
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Dec 13, 2005 at 11:33:20PM -0500, Tom Lane wrote:
and I don't even see the argument for doing it via a table rather
than via the postmaster log.
Simple. Postmaster logs can roll over or otherwise be lost without
damaging th
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Examining why psql won't do sensible stuff with COPY BINARY, I realized
that psql still uses PQgetline, which is marked obsolete since 7.4.
Is this intentional or just a "never reviewed because it works"?
The
Examining why psql won't do sensible stuff with COPY BINARY, I realized
that psql still uses PQgetline, which is marked obsolete since 7.4.
Is this intentional or just a "never reviewed because it works"?
Unfortunately, psql/copy.c also states "if you want to use copy in your
app, this is the co
Alvaro Herrera wrote:
Andreas Pflug wrote:
Alvaro Herrera wrote:
The problem with the original coding was that it used the table Oid to
look up the file name, which is wrong. (Test it with a table that has
been clustered or an index that has been reindexed.)
Um, can't test at the m
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
You have to have a lock to ensure that the table even exists, let alone
that you are looking at the right set of disk files.
This would require a lock on pg_class, not table foo, no?
No, the convention i
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
That's only possible if Slony is taking AccessExclusive lock; if so,
your gripe is properly directed to the Slony folks, not to
pg_relation_size which is acting as a good database citizen should.
More pr
Alvaro Herrera wrote:
The problem with the original coding was that it used the table Oid to
look up the file name, which is wrong. (Test it with a table that has
been clustered or an index that has been reindexed.)
Um, can't test at the moment. The oldcode used pg_class->relfilnode,
which d
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Nonsense.
Ahem.
I'm running Slony against a big replication set. While slon runs COPY
foo(colnamelist) FROM STDIN, I can't execute pg_relation_size(foo_oid).
pg_locks will show that the Access
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Until recently, pg_relation_size used SearchSysCache to locate the
relation to examine, and calculated the file location from that
information. Starting with dbsize.c V1.5 (committed after Beta2),
relation_open(.., AccessShareLo
Until recently, pg_relation_size used SearchSysCache to locate the
relation to examine, and calculated the file location from that
information. Starting with dbsize.c V1.5 (committed after Beta2),
relation_open(.., AccessShareLock) is used. This is very unfortunate
because it will not allow to
Magnus Hagander wrote:
For pgadmin, one hint said "is the 8th July" instead of "8th of July"
You'll have to talk to the pgadmin guys about that.
Yup, teach 'em correct English :-)
Fixed in svn.
Regards,
Andreas
---(end of broadcast)---
TIP
Bruno Wolff III wrote:
On Tue, Nov 22, 2005 at 10:57:19 +0100,
[EMAIL PROTECTED] wrote:
Just out of curiosity. Is there someone involved with ToDo item “%Allow
pg_hba.conf settings to be controlled via SQL”?
pgAdmin with the admin81 functions can handle this...
Regards,
Andreas
--
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
So postmaster doesn't clean up pg_listener,
It never has. If you're complaining about this patch
http://archives.postgresql.org/pgsql-committers/2005-10/msg00073.php
you ought to say so, rather than expecting us
-- Crossposting to pgsql-hackers --
Jan Wieck wrote:
For the record,
Slony-I uses a pg_listener entry as a locking mechanism to prevent
multiple concurrent slon processes serving the same node. The function
Async_Unlisten() is used in a backend function that is called during
slon startup i
Tom Lane wrote:
Patrick Bakker <[EMAIL PROTECTED]> writes:
It would be useful if you could toggle SQL statement logging without
restarting PostgreSQL and additionally if you could turn on selective SQL
logging. Additionally, it would be great if you could log SQL statements to
a separate fil
David Fetter wrote:
Dept of second thoughts: actually, perhaps see if you can generate
the pg_description entries from the C comments in the
include/catalog header files. There's already a strong motivation
to hold those to shorter-than-a-line length, whereas the column
descriptions in catalogs
Dave Page wrote:
Oh no, what have I started!! :-)
In order to keep traffic on this list low, both of us should be
excluded...;-)
Regards,
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.
Tom Lane wrote:
As against that, changing them back now might just confuse matters even
more. And I tend to agree with Neil's judgment that the new definitions
are cleaner in themselves.
When talking about cleanliness of the definition, a name like
"pg_stat_file" seems quite unfortunate sinc
Apparently, there's currently no way to perform conditional compiling
dependent on the version of pgsql. Currently we're facing the problem
that ParseDateTime changed its parameters between 8.0.3 and 8.0.4,
breaking backward compatibility (for good reasons in this case).
IMHO it's quite helpfu
In-time for PostgreSQL 8.1 gold, The pgAdmin Developer Team will release
pgAdmin III V1.4, which has a new Guru hint feature that tries to give
users helpful hints on typical beginner's pitfalls.
The current set of hints is at
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/docs/en_US
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- query is truncated due to UDP restrictions.
Are you confusing the logs with pg_stat_activity?
Not confused. I'm talking about the case where statement logging is
enabled, I could have mentioned that...
Regar
David Fetter wrote:
Folks,
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
exam
Tom Lane wrote:
Hm, so the proposal is "round unless that would produce 24:00:00, in
which case truncate"? Seems a bit ugly but it would follow the letter
of the spec, and avoid rejecting inputs that we used to accept. It's
still not very clear what to do with '23:59:60.9' though.
I'd handl
Tom Lane wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If T
Magnus Hagander wrote:
I thought we'd more or less dropped that idea based on Andreas'
responses.
I've heard no argument against renaming
pg_complete_relation_size() to
pg_total_relation_size()
Having spent days, no, weeks deciding on that name on list I
do not want to see it change thi
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
While we're on the subject, the units used by pg_size_pretty() are
incorrect, at least according to the IEC: for example, "MB" is
strictly-speaking one million bytes, not 1024^2 bytes. 1024^2 b
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
(2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all
return an int indicating success (1) or failure (0). Why shouldn't these
functions return a boolean?
I would have used boolean as return code for success and failure
Alvaro Herrera wrote:
Unfortunately, it's not at all obvious how to accomplish that :-(.
I don't think it can be easily done with the current code. This is
plpgsql code, right? There are some ways to cause recompilation for
those, at least on the 8.1 code I'm looking at.
Well at least w
Hannu Krosing wrote:
On P, 2005-08-28 at 22:23 +0200, Andreas Pflug wrote:
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes committed
and all backends in
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes committed
and all backends in state, I'm getting
"relation with OID xxx does not exist" when I'm trying to add a path.
Christopher Kings-Lynne wrote:
PQstatus perhaps?
http://www.postgresql.org/docs/8.0/interactive/libpq-status.html
This only returns the last status, not the current.
pgAdmin uses SELECT 1 for this.
Regards,
Andreas
---(end of broadcast)---
TIP
Bruce Momjian wrote:
Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
GUCs with pg_settings is the GUC like a table, but with comments that
exceed config_generic.long_desc.
Well, pg_hba.conf is ordered,
From a text editor user's view, postgresql.conf is ordered too
Bruce Momjian wrote:
Dave Page wrote:
The problem is, pg_hba.conf might be editted via the OS unlike the text
version of pg_shadow which is only editted via the server, which would
make appropriate locking nigh-on impossible afaics.
Unless you're advocating only allowing pg_hba modifications
Bruce Momjian wrote:
o ...
o recycle log files
o ...
All these items are on the TODO list already.
Didn't find this on the TODO, what does it mean? Is it what
pg_logfile_rotate() does since my very first logger subprocess posts?
Regards,
Andreas
--
Bruce Momjian wrote:
I think the group generally would like a
higher-level API that allows something like:
SET GLOBAL log_statement = 'mod';
This is the typical Core point of view. Any function not usable from
psql can't be ok. So until psql isn't enabled to SET GLOBAL, the rest of
Christopher Kings-Lynne wrote:
They usually claim to be the world's most POPULAR open source database...
Zillions of flies can't be wrong :o)
Regards,
Andreas
---(end of broadcast)---
TIP 6: explain analyze is your friend
Andrew Dunstan wrote:
It could be argued that there should be provision for a limitation on
the locations in which COPY can write (and maybe read) files.
Please note that the genfile functions are already restricted.
Regards,
Andreas
---(end of broadcast)-
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 23 July 2005 20:01
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
This patch looks good. The only question I ha
Bruce Momjian wrote:
Andreas Pflug wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new version of this patch coming?
Yup,
Bruce Momjian wrote:
Yea, but then we have toast and we would need another name. I suggested
pg_storage_size() because it relates to a storage unit (index, toast,
etc), and not a real object or relation.
I'm not really happy that all functions change their names (more
versioning handling i
Dave Page wrote:
As per Bruce's request, here's a copy of Andreas' server instrumentation
patch for review. I've separated out the dbsize stuff and
pg_terminate_backend is also not included.
This version was generated against CVS today.
As far as I can tell from review of comments made back to
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 21:07
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] DBSize backend integration
So drop total_relation_size(),
relation_size_components(), and wh
Michael Paesold wrote:
Andreas Pflug wrote:
For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.
I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?
Why is e.g. thi
Bruce Momjian wrote:
Dave Page wrote:
The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed lik
Bruce Momjian wrote:
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
But it still requires me to send some data (such as a dummy query) to
the backend before it exits. This is because server side libpq blocks
when reading and ignores signals at this time. I believe the fix for
t
Bruce Momjian wrote:
Dave Page wrote:
Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.
Extending the logging was to get a means of reading the lo
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If it's a server-side failure it should have a SQLSTATE code.
Specifically, I'm talking about
"no pg_hba.conf entry for ",
ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION
&q
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Fallback is a fine idea, but this brings up another problem I'm
currently facing: how to identify the problem the connection has from
libpq? If the problem is a wrong password, we certainly don't want to
try agai
Andrew Dunstan wrote:
The decision which files should be changed must be taken. e.g.
createdb, dropdb will use template1 hardcoded. Is it acceptable that
those tools fail if the "postgres" database isn't present any more?
How about template1 as a fallback?
Fallback is a fine idea,
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Can't tell whether I could find time for reviewing the docs the next
days (more interesting for feature freeze is having fixed the
implementation anyway).
Of the sixty-odd files that mention template1 in current CVS, only
Dave Page wrote:
Whether or not users should write to the default db is another issue
altogether, and one that I'd rather not see causing this idea to be
rejected or get delayed past freeze.
+1
If 'default' is writeable, then
so what if users use it? It won't stop pgAdmin from working,
Juan Pablo Espino wrote:
I want to register in an audit table the date and time of the
login/logout of a database user. I have been looking for some function
in the code but I didn't find something like that.
This is the kind of functionality I'd expect to go to the pg_system (or
however it i
Tom Lane wrote:
[ redirected back to hackers, since it seems this is far from a finished
discussion ]
Robert Treat <[EMAIL PROTECTED]> writes:
What is the purpose of this database? A generalized, shared resource for tool
makers and add-on packages to store information in PostgreSQL, or a wor
Magnus Hagander wrote:
I was gradually drifting toward this idea. Do we really need
the blessing of the postgresql core to make this happen? ISTM
we don't.
I think not, but I would perhaps make things easier ;-)
But what if we all just agreed that we would use a common
database called "
Andrew Dunstan wrote:
It strikes me that these names just might have some significance to
developers but will have none at all for users. I don't heve a better
alternative ... maybe because the purpose has been expressed somewhat
fuzzily.
I'd define the purpose like this:
- being a db
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I particularly dislike the name "default" for that database, because
we'd have to expect users to place their user data there regularly (as
in the public schema), which is just what should *not* happen.
Why
Tom Lane wrote:
One argument against this is that it'd mean another copy of the system
catalogs in a standard installation. That's been running three to five
megabytes over the last few releases. Disk space is pretty cheap these
days, but we do get occasional complaints from people who wish th
Magnus Hagander wrote:
I dislike the name pg_system because it implies that that DB
is somehow special from the point of view of the system ...
which is exactly what it would *not* be.
That I can certainly agree with.
I suggested the name to indicate that it's a db used by system tools
Christopher Kings-Lynne wrote:
Probably, though the create db issue is a good reason not to use
template1.
Create db issue?
CREATE TABLE (implicitely using TEMPLATE template1) often fails because
template1 has connections exceeding the current one.
So may I propose to have a pg_system d
Christopher Kings-Lynne wrote:
In phpPgAdmin the default db to connect to can be specified
per-server in the config file. It defaults to template1. It
actually is not relevant at all which db it is, so long as they can
connect to it.
I wonder how many users actually change that value for p
Christopher Kings-Lynne wrote:
In phpPgAdmin the default db to connect to can be specified per-server
in the config file. It defaults to template1. It actually is not
relevant at all which db it is, so long as they can connect to it.
I wonder how many users actually change that value for
Magnus Hagander wrote:
fer enhanced functionality in the client.
To overcome this, a alternative database created by initdb
would be very useful. This would be roughly the equivalent of
SQL Server's 'msdb'
database and would allow:
- A default non-template database for apps to connect to ini
Qingqing Zhou wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is having the
postmaster spawn t
Andrew Dunstan wrote:
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single poi
Josh Berkus wrote:
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like pgAgent being built into the backend, istm that the
majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty m
Matthew T. O'Connor wrote:
Right, I think if VACUUM is improved than the semantics of AV in the
backend might change, but I think there will always be a need for some
maintenance, and a daemon that monitors the maintenance needs of your
database and fires off appropriate maintenance commands
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
pg_terminate_backend()
exposing kill -SIGTERM to the client
The objections to this have not changed since last year; in fact they
are stronger because we have at least one report of actual trouble
with retail SIGTERMs.
I
Abhijit Menon-Sen wrote:
Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe?
I'll be at the booth.
Regards,
Andreas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Andrew - Supernews wrote:
On 2005-05-12, Andreas Pflug <[EMAIL PROTECTED]> wrote:
relpages is updated from the value of RelationGetNumberOfBlocks(rel) which
is definitive (it gets the value from smgr which gets it from the physical
file sizes); the only inaccuracy is that it is correct only
Marc G. Fournier wrote:
'k, now i'm confused ... what are you looking at here, in contrib, as
being 'admintools'? Right now, anything in contrib is 'add-on' anyway,
so they'd still be as confused, I'd think ...
Well at least it would be contained in the full tarball, not coming from
a 3rd site
Marc G. Fournier wrote:
... but stuff like admintools should be on pgfoundry ...
This is a quite *ix centric attitude. Please note that probably >90 % of
win32 installations have them installed by default (from the win32
installer). People moving to Linux because they need better performance
(wh
Magnus Hagander wrote:
Not kill -9. Kill -9 is "safe" because it causes a complete restart of
the postmaster (it's the same as a backend crash, really). Kill -INT is
also safe, because it does a simlpe query cancel.
I don't recall exactly; AFAIR this was discussed between Dave and Tom.
Actually
Andrew - Supernews wrote:
dbsize looks at the actual size of files on disk; newsysviews does not,
it shows estimated sizes as taken from relpages.
Which shows *net* size only, not actual size because non-vacuumed rows
are not covered. It is correct after a vacuum full only.
newsysviews doesn't
al
Josh Berkus wrote:
- dbsize has been in contrib for a long time, though it appears to me as
quite a basic functionality to find out about storage needs.
Although not needed so much if the new system views are approved; we have a
view that calculates database size.
First, as some other msg states
Tom Lane wrote:
Josh Berkus writes:
- The superuser only generic file functions in the admin package have
been posted for 8.0, but where (more or less ) silently dropped. These
functions allow pgadmin to display the server logs, as well as editing
pg_hba.conf and postgresql.conf without console ac
There's still a lengthy discussion going on whether it's a good idea to
add a forth way to read pgsql's schema (pg_* tables, pg_* views,
information_schema, did I miss one?), but I'd like to see helper
functions for issues *not* covered in the core package.
- dbsize has been in contrib for a lo
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Aside from that, it's currently rather silly that every admin tool has
to code up a very complex set of queries to get info from the system
catalog. It makes much more sense to put that complexity into a set of
system views that are maintai
Christopher Kings-Lynne wrote:
The unimaginable craziness of currently trying to support multiple
versions of postgresql is pretty bad,
Hu? So you suggest version specific admin tools? *scratch head*
Just for curiosity:
pgAdmin CVS currently has 80 version checked pieces of code to support
7.3/7.4
Josh Berkus wrote:
And, as an increasing number of 3rd-party tools support PostgreSQL (like
Embarcadero) they need a simple comprehensible API for system objects -- more
objects than are included in the information_schema.
There are only two choices: Creating a minimal subset tool, which will
re
Josh Berkus wrote:
Frankly, this is sounding a lot like "Who needs OpenOffice.org? Use vi!"
Frankly, this is sounding a lot like "Who needs
pgadmin/phppgadmin/pgaccess/younameit? use SELECT * FROM pg_somewot in
psql instead".
As Dave already pointed out, serious admin tools will avoid views. We
Bruce Momjian wrote:
You might remember that when we released 8.0, the plan was to have a
12-month development cycle for 8.1, unless there were Win32 problems
that required complex fixes, in which case we would have a shorter 8.1
cycle.
Well the good news is that there have been almost no Win32 pro
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Good god - how old was that email? 2002???
Yep, and been in my mailbox since then, waiting for me to process it
into a TODO entry.
Exciting what one can find wiping the floor of the mailbox :-)
Regards,
Andreas
---(end of
101 - 200 of 518 matches
Mail list logo
