Gevik Babakhani wrote:
- new_guid() function is supported. This function is based on V4 random
uuid value. It generated 16 random bytes with uuid 'variant' and
'version'. It is not guaranteed to produce unique values
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even Microsoft can't be that stupid.
And I can't find any suggestion that they've
Bruce Momjian wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even Microsoft can't be that stupid
Alvaro Herrera wrote:
Bruce Momjian wrote:
Uh, I just added /contrib/adminpack a few weeks ago to CVS, which does
this, and more. Sorry I forgot to mark the TODO item as completed.
Huh, how do you read files with adminpack?
try
select * from pg_logdir_ls() as (filetime timestamp,
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I wonder if we should take pg_read_file (and the rest of genfile.c)
back out of the backend and stick them into contrib/adminpack.
I thought about that but what we have in the backend now is read-only
which
The attached patch enables psql to copy binary data in and out.
Regards,
Andreas
Index: src/bin/psql/copy.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/copy.c,v
retrieving revision 1.60
diff -u -r1.60 copy.c
---
Jonah H. Harris wrote:
On 3/13/06, *Peter Eisentraut* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Does any SQL-like database system other than Oracle have this feature?
I know that SQL Server, DB2, SAP DB/MAX DB, and Mimer have it.
Introduced in MSSQL2005:
Neil Conway wrote:
I'm still unconvinced that this feature would be sufficiently useful to
justify the maintenance burden, in addition to the added complexity:
even if it is implemented in a way that imposes minimal *runtime*
overhead, new features add complexity: introducing a bunch of new
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
upgrade just won't work, ISTM.
We have talked about batching on-disk changes so that they'd only occur
Alvaro Herrera wrote:
Is anybody working or considering to work on pg_upgrade, or is all this
hypothetical? Our past history has seen lots of people offering to work
on pg_upgrade, and none has produced a working version. Is it fair or
useful to impose restrictions on development just because
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes savings are worth the trouble.
Regards,
Andreas
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes
Tom Lane wrote:
I removed the separate pg_file_length() function, as it doesn't have any
significant notational advantage anymore; you can do
Please note that there are pg_file_length functions in use for 8.0 on
probably 95 % of win32 installations, so you're breaking backwards
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I removed the separate pg_file_length() function, as it doesn't have any
significant notational advantage anymore; you can do
Please note that there are pg_file_length functions in use for 8.0 on
probably 95
Bruce Momjian wrote:
True, but that is more for the application. I don't imagine a user
looking at that from psql would have a problem.
However, you asked for a query that looks like pg_ls_logdir() and here
it is:
SELECT pg_ls_dir
FROM(
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, if they mix log files and non-log files in the same directory, we
would have to filter based on the log_filename directive in the
application, or use LIKE in a query.
.. which is what pg_logdir_ls does
Bruce Momjian wrote:
Also, do we have a way to return columns from a system-installed
function? I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
As in pg_settings:
SELECT length, mtime FROM
Bruce Momjian wrote:
BTW, it surprised me that one of the functions (don't remember
which one) expected the log files to be named in a very specific
fashion. So there's no flexibility for changing the log_prefix.
Probably it's not so bad, but strange anyway. Is this for
security reasons?
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
So how would your query to display all all available _logfiles_
look like?
I think it's perfectly reasonable to assume that all the files in the
log directory are logfiles --- more so than assuming that the admin
hasn't exercised his
Bruce Momjian wrote:
I don't assume people using psql will care about the current log files ---
Hm. Probably because you think these users will have direct file access?
Which in turn means they can edit *.conf directly too and don't need an
interface for that either.
it would be
Bruce Momjian wrote:
I don't see how listing the log files relates to editing the confuration
files.
Both are remote administration. While we've seen the discussion that one
aspect (config file editing) should be performed in psql, you assume the
other aspect (viewing the logfile) to be
Bruce Momjian wrote:
Dave Page wrote:
The only part I didn't like about the patch is the stat display:
test= select pg_file_stat('postgresql.conf');
pg_file_stat
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 03:26
To: Dave Page
Cc: PostgreSQL-patches
Subject: Re: [HACKERS] For review: Server instrumentation patch
Dave Page wrote:
[Resent as the list seems to have rejected
Dave Page wrote:
pg_dir_ls isn't necessary for reading the logfiles;
pg_logdir_ls will do
this.
Err, yes, sorry - that was a thinko.
The list isn't complete. pgadmin uses these three functions for logfile
tracking:
- pg_logdir_ls to list logfiles
- pg_file_length to check for changes
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
From a user's view, a trigger
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,
Satoshi Nagayasu wrote:
Hi all,
Here is a first patch to allow these commands.
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
Bruce said to allow them only super-user,
but currently this patch allows also the table owner.
It would be
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
As per discussion on -hackers the attached patch creates the 'default'
database at initdb time as a default target for initial connections to
keep template1 free from connections and available as template source.
I consider this DB a system object, so it's created before
make_template0 sets
Magnus Hagander wrote:
Umm. Tiny item, but your comment still refers to the database as
pg_system ;-)
:-)
Regards,
Andreas
Index: src/bin/initdb/initdb.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving
);
}
/*-
*
* genfile.c
*
*
* Copyright (c) 2004, PostgreSQL Global Development Group
*
* Author: Andreas Pflug [EMAIL PROTECTED]
*
* IDENTIFICATION
* $PostgreSQL: $
*
*-
*/
#include postgres.h
#include sys/file.h
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
pg_terminate_backend()
exposing kill -SIGTERM backendpid 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
Bruce Momjian wrote:
Andreas Pflug wrote:
Bruce Momjian wrote:
Andreas Pflug wrote:
This patch reenables pg_terminate_backend, allowing (superuser only, of
course) to terminate a backend. As taken from the discussion some weeks
earlier, SIGTERM seems to be used quite widely, without
As a start for a bunch of instrumentation functions that should be
included in the backend as discussed previously, here are the dbsize
functions. The dbsize.c file should go to the usual place,
src/backend/utils/adt.
Regards,
Andreas
? GNUmakefile
? config.log
? config.status
?
This patch reenables pg_terminate_backend, allowing (superuser only, of
course) to terminate a backend. As taken from the discussion some weeks
earlier, SIGTERM seems to be used quite widely, without a report of
misbehaviour so while the code path is officially not too well tested,
in practice
Magnus Hagander wrote:
There is special code in the send_message_to_server_log
function to make
sure it's written directly to the file.
If the logger is complaining, it's quite possibly because it's
unable to
write to its file. Now that you mention it, doesn't this code go into
infinite
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Hm, these are all implementable as SQL functions, do we need these hard
coded too?
e.g.
create function aggregate_relation_size(oid) returns int8 as $CODE$
select sum(pg_relation_size(indexrelid)) from pg_index where indrelid=$1;
$CODE
Neil Conway wrote:
On Tue, 2005-01-25 at 16:49 -0700, Ed L. wrote:
The attached dbsize patch:
+ makes relation_size(relname) include toast tables;
+ adds aggregate_relation_size(relname) to count table data and indices;
+ adds indices_size(relname) to report the size of
[EMAIL PROTECTED] noticed a problem with pg_get_viewdef
in prettyprint mode.
create table gnrcitm (gnrcitmid int);
create table gnrcitmothrref (idntfyrefid int, gnrcitmid int);
create table other_ref(idntfyrefid int, catnmeclssid text, actvle text);
CREATE OR REPLACE VIEW test_view AS
SELECT
The attached Makefile patch together with stylesheet-hh.xsl allows make
htmlhelp. stylesheet-hh.xsl is derived from stylesheet.xsl, after some
advise from PeterE.
The result isn't perfect, but quite usable.
Regards,
Andreas
Index: Makefile
Peter Eisentraut wrote:
Tom Lane wrote:
Nonetheless, it would also be good to have some consistency between
the core PG server and related projects. I tend to agree that we
should honor pgadmin's precedent here; it's not a strong argument but
the argument for fa over fa_IR seems even weaker.
[EMAIL PROTECTED] wrote:
hello,
we are starting a new language translation in postgresql.
I send the pg_controldata message translation in Farsi language.
I sended it to the Peter Eisentraut with the name fa_IR.po. He said that
Is there any use of fa outside of IR? Else I would just call the
Bruce Momjian wrote:
How does your Win32 system rename prototype differ from what is in
port.h?
What is the need of *any* special file handling functions for client tools?
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Bruce Momjian wrote:
Andreas Pflug wrote:
Bruce Momjian wrote:
How does your Win32 system rename prototype differ from what is in
port.h?
What is the need of *any* special file handling functions for client tools?
We could avoid it but it does give us Unix semantics so it seemed good
to keep
Dave Page wrote:
cube
seg
patch attached. Compiles, but not tested.
miscutil
Needs review; includes some deprecated stuff (backend_pid)
pg_logger
deprecated; use redirect_stderr (BTW, is it default on win32 now?)
pgcrypto
misses -lws2_32. According to README, it needs some tuning concerning
Bruce Momjian wrote:
Patch applied. Thanks.
Can I get some documentation in the README for all the new
functionality.
Here it is.
Regards,
Andreas
Index: README.dbsize
===
RCS file:
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
I don't have the time now to review the impact, but this might make
interpreting the log filename difficult or impossible, effectively
corrupting pg_logdir_ls.
So if you want to use that, you use a format that it can cope with.
you
Gavin Sherry wrote:
The attached patch contributes:
- database_size(name)
- relation_size(text)
I sent in a dbsize patch to make these functions tablespace aware...
AFAIR your patch was applied, but it misses tables in non-default
tablespaces.
Regards,
Andreas
---(end of
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
The DBA isn't necessarily also root.
Interesting this argument comes from you.. :-)
Tasks like purging old log
Bruce Momjian wrote:
Are we going to change this before beta2? I have not seen a final
patch yet.
Can we have pg_logdir_ls in the backend first so any related changes to
the log filename are reflected in both places?
Otherwise displaying the logfile on the client continues to be a moving
+++ dbsize.c 29 Aug 2004 10:12:11 -
@@ -1,157 +1,285 @@
+/*
+ * dbsize.c
+ * object size functions
+ *
+ * Copyright (c) 2004, PostgreSQL Global Development Group
+ *
+ * Author: Andreas Pflug [EMAIL PROTECTED]
+ *
+ * IDENTIFICATION
+ * $PostgreSQL: $
+ *
+ */
+
+
#include postgres.h
Maksim Likharev wrote:
Compiled and tried,
seems much better, no more WAIT_FAIL errors.
but I have some questions:
1. Is there a any possibility to assign server log file ( option -l,--log )
when PG runs as a service,
I wasn't able to do that, dump everything into stderror or eventlog just
not
Jan Wieck wrote:
but allows to setup a
configuration that automatically overwrites files in a rotating manner,
if the DBA so desires.
... which can't work because it will overwrite the logfile on server
start, and thus will overwrite the very latest logfile when performing
multiple restarts.
Tom Lane wrote:
at logger startup or size-based
rotation, the rule would be to append.
which then has a problem when you startup the postmaster after 10 hours
of downtime ... hmmm.
Doesn't seem like a big problem --- at worst that logfile will get to be
double the size it normally would.
...
Tom Lane wrote:
It's definitely creeping featurism ... but
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
A potential problem is what about size-driven rotation? If the hourly
output exceeds log_rotation_size then you'd truncate and
Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive.
+ changes the default log filename to exclude the PID;
This would be better stated as makes it impossible to use the PID
Bruce Momjian wrote:
The problem with this approach is that it has us using the non-reliable
libc rename/unlink rather than our own in libpq.
Not really. The backend will still use the reliable pg_ functions.
Frontends continue to use the libc functions, which are totally
sufficient in
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Andreas Pflug wrote:
Not really. The backend will still use the reliable pg_ functions.
Frontends continue to use the libc functions, which are totally
sufficient in non-concurrent access situations.
I would like to keep full Unix semantics
Tom Lane wrote:
Hm. Given that we now support a native Windows port, do we care about
building libpq with VC6 anymore?
Yes please!
I just tried:
I renamed libpq.a to libpq.lib. pgAdmin links with that, but will crash.
Regards,
Andreas
---(end of
Bruce,
I posted the attached patch 4 days ago, with the comment
The attached patch will redefine unlink and rename only if FRONTEND is
not defined..
I still believe this a good way to fix it.
Tom Lane wrote:
To put that in a more positive light: we like to think that our code is
Posix-compliant
Dave Page wrote:
Dave Page [EMAIL PROTECTED] writes:
The attached patch directs FATAL and PANIC elog's to the
event log as
well as their normal destination.
I don't think this is a good idea. In the first place, FATAL
errors are not necessarily serious or out-of-the-ordinary ---
an example
Andreas Pflug wrote:
Some recent change in libpq seems to interfere with gtk.
After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show waiting
[EMAIL PROTECTED] wrote:
(create/drop tablespace works too)
I can *not* confirm this; after configure; make clean; make; make
install I got tablespace not supported. pg_config.h lacks HAVE_SYMLINK=1.
Regards,
Andreas
---(end of broadcast)---
TIP 8:
Dave Page wrote:
This is obviously win2k+ only though -
There's a chance it might work on NT4 with =SP4, because AFAIR the
updated NTFS driver already understands the W2K format.
until now we've tried to support NT4 as well, although it seems that we
can't get initdb to work as we'd like in the
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Attached the patch, an orgy in #ifdefs, decorated with various indents
and crlf line ends (glad we have pgindent).
I spent a fair amount of time fooling with this, trying to extract
something that I trusted enough to apply at this late date
Tom Lane wrote:
if (!ReadFile(...))
{
DWORD error = GetLastError();
if (error == ERROR_HANDLE_EOF)
exit(0);
Got it. And there's no reason that the pipe thread can't do exit(0)
for itself?
Not really. All threads are equivalent.
BTW, should there be a last NOTICE syslogger shutting
and a new one is created (rotated).
* The logfiles are stored in a subdirectory (configurable in
* postgresql.conf), using an internal naming scheme that mangles
* creation time and current postmaster pid.
*
* Author: Andreas Pflug [EMAIL PROTECTED]
*
* Copyright (c) 2004, PostgreSQL Global
Bruce Momjian wrote:
Do people want the server file logging/rotating patch applied if it is
Unix-only? Right now the patch is ifdef'ed so Win32 use of it is
disabled.
Andreas is asking.
Please commit ASAP. Is I stated several times, I'll do the win32 as soon
as I get a chance to. It's not a
Peter Eisentraut wrote:
Bruce Momjian wrote:
Do people want the server file logging/rotating patch applied if it
is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is
disabled.
How is logging typically handled on Windows?
It is done using the eventlog service (which is supported as
Tom Lane wrote:
Do people want the server file logging/rotating patch applied if it is
Unix-only? Right now the patch is ifdef'ed so Win32 use of it is
disabled.
I'm slightly worried that we might be painting ourselves into a corner,
ie implementing functionality that will never work on Windows.
Dave Page wrote:
As Bruce has seen, this is some pretty nice functionality that
Andreas has added to pga3, and is one of the few areas that we
lag behind SQL Server etc. in on the management front.
If you're curious what Bruce has seen, it was this:
Bruce Momjian wrote:
I talked to Tom about this today. First, I want to apologize for
running you around in circles in this. I don't think we are giving it
the attention it needs because of our schedule. I also think the
functionality is drifting into the new features territory and this is
also
Bruce Momjian wrote:
Basically I think we are converging on an answer that we can't do any of
this for 7.5.
If it's not going into the distribution as contrib or core, I'll package
that as additional admin pack. I'm quite sure I can convince the win32
installer packager guys to include that as
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Do not apply.
I'm investigating issues under win32.
Main
This is the known patch, with following changes:
- realStdErr handed over for EXEC_BACKEND, but still not tested
- Sometimes EMFILE is received in the logger's process queue, when a
backend ended after a SSL connection was interrupted. This is ignored
now (previously it forced an exit(1) and
() AS A
(filetime timestamp, pid int4, filename text);
/*-
*
* genfile.c
*
*
* Copyright (c) 2004, PostgreSQL Global Development Group
*
* Author: Andreas Pflug [EMAIL PROTECTED]
*
* IDENTIFICATION
* $PostgreSQL
Tom Lane wrote:
If you don't mind plastering a use at your own risk sign on it, then
go for it.
killing a backend is obviously much more at your own risk than a
descent function.
Taken from your mail, I understand that a killed backend might leave
some loose ends, eg. open locks, which would
Bruce Momjian wrote:
Are we done? Seems pg_file_stat() works fine. Do we need other
adjustments?
Here are the documentation changes.
Regards,
Andreas
Index: catalogs.sgml
===
RCS file:
Bruce Momjian wrote:
Here is what you can do:
SELECT filename,
(SELECT file_len FROM pg_file_stat(filename)),
(SELECT file_ctime FROM pg_file_stat(filename)),
(SELECT file_mtime FROM pg_file_stat(filename)),
(SELECT file_atime FROM pg_file_stat(filename))
FROM pg_dir_ls('/etc') AS
Bruce Momjian wrote:
Andreas Pflug wrote:
OK, new idea. Forget about modifying pg_dir_ls(). Instead add
pg_file_stat the returns the file size, times. You can then easily use
that for file size and times. Also, if you want, add an is_dir boolean
so people can write functions that walk
Bruce Momjian wrote:
Andreas Pflug wrote:
Very nice. You did a nice trick of reading the log filenames into a
timestamp field:
count = sscanf(de-d_name, %04d-%02d-%02d_%02d%02d%02d_%05d.log, yea$
You only process files that match that pattern for pg_logfiles_ls()
(perhaps this should
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Andreas Pflug wrote:
How should the prefix be named? pgsql_ ?
Make the file names configurable.
He has code to interpret the file names as timestamps that can be
used in queries. If we allowed full user
are reached or passed, the
* current logfile is closed and a new one is created (rotated).
* The logfiles are stored in a subdirectory (configurable in
* postgresql.conf), using an internal naming scheme that mangles
* creation time and current postmaster pid.
*
* Author: Andreas Pflug [EMAIL
in
* postgresql.conf), using an internal naming scheme that mangles
* creation time and current postmaster pid.
*
* Author: Andreas Pflug [EMAIL PROTECTED]
*
* Copyright (c) 2004, PostgreSQL Global Development Group
*
*
* IDENTIFICATION
* $PostgreSQL
Tom Lane wrote:
That struck me as not only useless but the deliberately hard way to do
it. To use that in the real world, you'd have to set up a cron job to
trigger the rotation,
Still on my radar...
which means a lot of infrastructure and privilege;
whereas ISTM the point of this feature was to
Bruce Momjian wrote:
Also there are no documenttion changes.
Here are the missing docs, freshly created against cvs.
Regards,
Andreas
Index: func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving
Bruce Momjian wrote:
How is this patch supposed to work? Do people need to modify
postgresql.conf and then sighup the postmaster? It seems more logical
for the super-user to call a server-side function.
I assume calling pg_logfile_rotate() to be the standard way. calling
pg_logfile_rotate
Tom Lane wrote:
That was something that bothered me too. I think in the patch as given,
the GUC parameter determining the logfile name would have to be
PGC_POSTMASTER, ie, you could not change it on the fly because the
backends wouldn't all switch together.
In my original posting it was
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have added this patch plus your later comments to the patch queue.
The autovacuum process still uses libpq to send its queries, which is
not the idea behind backend integration.
Can we consider this a non-fatal bug that has to be solved
Updated version.
Only timestamp of fresh logfile in shared mem, with sanity checks.
On SIGHUP, timestamp is checked if rotation was issued, as well as
changed log_filename setting from postgresql.conf.
Regards,
Andreas
Index: src/backend/postmaster/postmaster.c
Joe Conway wrote:
Attached is the patch I plan to apply. There are a couple of changes
from what was posted.
1) You must have meant tablespace instead of namespace here:
+ row
+
Fabien COELHO wrote:
Dear patchers,
I have two minor patches that are being submitted but which do not appear
yet in the official patch queue on the web site:
http://momjian.postgresql.org/cgi-bin/pgpatches
That site is maintained by Bruce, who is out to Armenia until next week,
with
The attached patch includes serverlog rotation with minimal shared
memory usage as discussed and functions to access it.
Regards,
Andreas
Index: doc/src/sgml/func.sgml
===
RCS file:
Andreas Pflug wrote:
From an idea of Bruce, the attached patch implements the function
pg_tablespace_databases(oid) RETURNS SETOF oid
which delivers as set of database oids having objects in the selected
tablespace, enabling an admin to examine only the databases affecting
the tablespace
Tom wrote:
It's there to declare struct timeval, and I'm fairly certain that diking
it out of the header would break things on some platforms. Where does
Windows define struct timeval?
struct timeval is defined in winsock.h under vc6.
I'm checking for _MSC_VER now.
Agreed. We define
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
As for the authentication-is-expensive issue, what of it? You *should*
have to authenticate yourself in order to look inside another person's
database. The sort of cross-database inspection being proposed here
would
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bruce Momjian
Sent: Sat 6/19/2004 1:05 AM
To: Andreas Pflug
Cc: Tom Lane; Gavin Sherry; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
We can build a gui on top of the command-line tool
Bruce Momjian wrote:
I don't see why an admin tool can't connect to each database and get a
listing of what is in each tablespace. I don't think connecting to 100
databases to get that information will be slow.
Well, whatever you call slow or not slow.
I checked it; connecting 10 databases,
Dave Page wrote:
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Sat 6/19/2004 6:40 PM
To: Bruce Momjian
Cc: Dave Page; Tom Lane; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
Well, whatever you call slow or not slow.
I checked it; connecting
1 - 100 of 140 matches
Mail list logo