Re: [PATCHES] Patch for UUID datatype (beta)

2006-09-18 Thread Andreas Pflug
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

Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run

2006-08-15 Thread Andreas Pflug
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

Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run

2006-08-15 Thread Andreas Pflug
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

Re: [PATCHES] Patch for - Allow server logs to be remotely read

2006-06-09 Thread Andreas Pflug
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,

Re: [PATCHES] Patch for - Allow server logs to be remotely read

2006-06-09 Thread Andreas Pflug
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

[PATCHES] Binary COPY for psql

2006-05-25 Thread Andreas Pflug
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 ---

Re: [PATCHES] CREATE SYNONYM ...

2006-03-13 Thread Andreas Pflug
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:

Re: [PATCHES] CREATE SYNONYM ...

2006-03-08 Thread Andreas Pflug
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

Re: [PATCHES] Numeric 508 datatype

2005-11-18 Thread Andreas Pflug
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

Re: [PATCHES] Numeric 508 datatype

2005-11-18 Thread Andreas Pflug
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

Re: [PATCHES] Numeric 508 datatype

2005-11-17 Thread Andreas Pflug
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

Re: [PATCHES] Numeric 508 datatype

2005-11-17 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-14 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-14 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-13 Thread Andreas Pflug
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(

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-13 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-13 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-12 Thread Andreas Pflug
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?

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-12 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-12 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-12 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-11 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-01 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] For review: Server instrumentation patch

2005-08-01 Thread Andreas Pflug
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

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-05 Thread Andreas Pflug
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

Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-03 Thread Andreas Pflug
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

Re: [PATCHES] Dbsize backend integration

2005-07-02 Thread Andreas Pflug
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,

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Andreas Pflug
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

Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-29 Thread Andreas Pflug
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

[PATCHES] default database creation with initdb

2005-06-18 Thread Andreas Pflug
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

Re: [PATCHES] default database creation with initdb

2005-06-18 Thread Andreas Pflug
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

[PATCHES] Server instrumentation

2005-06-10 Thread Andreas Pflug
); } /*- * * genfile.c * * * Copyright (c) 2004, PostgreSQL Global Development Group * * Author: Andreas Pflug [EMAIL PROTECTED] * * IDENTIFICATION * $PostgreSQL: $ * *- */ #include postgres.h #include sys/file.h

Re: [PATCHES] Server instrumentation

2005-06-10 Thread Andreas Pflug
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

Re: [PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

2005-06-07 Thread Andreas Pflug
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

[PATCHES] dbsize backend integration

2005-06-01 Thread Andreas Pflug
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 ?

[PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

2005-06-01 Thread Andreas Pflug
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

[PATCHES] was: BUG #1466: syslogger issues

2005-02-21 Thread Andreas Pflug
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

Re: [PATCHES] dbsize patch

2005-01-28 Thread Andreas Pflug
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

Re: [PATCHES] dbsize patch

2005-01-27 Thread Andreas Pflug
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

[PATCHES] pg_get_viewdef returns one paren too much

2004-12-10 Thread Andreas Pflug
[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

[PATCHES] htmlhelp generation

2004-11-22 Thread Andreas Pflug
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

Re: [PATCHES] New Translation

2004-09-13 Thread Andreas Pflug
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.

Re: [PATCHES] New Translation

2004-09-12 Thread Andreas Pflug
[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

Re: [PATCHES] [pgsql-hackers-win32] VC++ psql build broken

2004-09-12 Thread Andreas Pflug
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

Re: [PATCHES] [pgsql-hackers-win32] VC++ psql build broken

2004-09-12 Thread Andreas Pflug
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

Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32

2004-09-08 Thread Andreas Pflug
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

Re: [PATCHES] dbsize contrib

2004-09-02 Thread Andreas Pflug
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:

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-31 Thread Andreas Pflug
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

Re: [PATCHES] dbsize contrib

2004-08-30 Thread Andreas Pflug
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

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-29 Thread Andreas Pflug
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

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-29 Thread Andreas Pflug
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

[PATCHES] dbsize contrib

2004-08-29 Thread Andreas Pflug
+++ 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

Re: [PATCHES] Win32 bug fix

2004-08-29 Thread Andreas Pflug
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

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-29 Thread Andreas Pflug
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.

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-29 Thread Andreas Pflug
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. ...

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-28 Thread Andreas Pflug
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

Re: [PATCHES] log_filename_prefix -- log_filename + strftime()

2004-08-27 Thread Andreas Pflug
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

Re: [PATCHES] Compiling libpq with VC6

2004-08-18 Thread Andreas Pflug
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

Re: [PATCHES] Compiling libpq with VC6

2004-08-18 Thread Andreas Pflug
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

Re: [PATCHES] Compiling libpq with VC6

2004-08-18 Thread Andreas Pflug
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

Re: [PATCHES] [pgsql-hackers-win32] libpq build problem with io.h

2004-08-17 Thread Andreas Pflug
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

Re: [PATCHES] Win32 Event log

2004-08-12 Thread Andreas Pflug
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

Re: [PATCHES] [HACKERS] libpq problem

2004-08-11 Thread Andreas Pflug
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

Re: [PATCHES] Win32 tablespace

2004-08-08 Thread Andreas Pflug
[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:

Re: [PATCHES] Win32 tablespace

2004-08-06 Thread Andreas Pflug
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

Re: [PATCHES] logger subprocess including win32

2004-08-05 Thread Andreas Pflug
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

Re: [PATCHES] logger subprocess including win32

2004-08-05 Thread Andreas Pflug
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

[PATCHES] logger subprocess including win32

2004-08-04 Thread Andreas Pflug
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

Re: [PATCHES] Admin functions contrib

2004-07-31 Thread Andreas Pflug
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

Re: [PATCHES] Admin functions contrib

2004-07-31 Thread Andreas Pflug
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

Re: [PATCHES] Admin functions contrib

2004-07-31 Thread Andreas Pflug
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.

Re: [PATCHES] Admin functions contrib

2004-07-30 Thread Andreas Pflug
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:

Re: [PATCHES] Admin functions contrib

2004-07-29 Thread Andreas Pflug
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

Re: [PATCHES] Admin functions contrib

2004-07-29 Thread Andreas Pflug
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

Re: [PATCHES] logger subprocess

2004-07-28 Thread Andreas Pflug
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

[PATCHES] logger subprocess

2004-07-27 Thread Andreas Pflug
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

[PATCHES] Admin functions contrib

2004-07-27 Thread Andreas Pflug
() AS A (filetime timestamp, pid int4, filename text); /*- * * genfile.c * * * Copyright (c) 2004, PostgreSQL Global Development Group * * Author: Andreas Pflug [EMAIL PROTECTED] * * IDENTIFICATION * $PostgreSQL

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Andreas Pflug
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

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-23 Thread Andreas Pflug
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:

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-22 Thread Andreas Pflug
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

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-21 Thread Andreas Pflug
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

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-20 Thread Andreas Pflug
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

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-20 Thread Andreas Pflug
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

Re: [PATCHES] logfile subprocess and Fancy File Functions

2004-07-18 Thread Andreas Pflug
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

[PATCHES] logfile subprocess and Fancy File Functions

2004-07-17 Thread Andreas Pflug
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

Re: [PATCHES] serverlog rotation/functions

2004-07-14 Thread Andreas Pflug
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

Re: [PATCHES] serverlog rotation/functions

2004-07-14 Thread Andreas Pflug
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

Re: [PATCHES] serverlog rotation/functions

2004-07-13 Thread Andreas Pflug
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

Re: [PATCHES] serverlog rotation/functions

2004-07-13 Thread Andreas Pflug
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

Re: [PATCHES] pg_autovacuum integration attempt #2

2004-07-12 Thread Andreas Pflug
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

Re: [PATCHES] serverlog rotation/functions

2004-07-06 Thread Andreas Pflug
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

Re: [PATCHES] pg_tablespace_databases

2004-07-02 Thread Andreas Pflug
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 +

Re: [PATCHES] patch queue reminder

2004-06-30 Thread Andreas Pflug
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

[PATCHES] serverlog rotation/functions

2004-06-28 Thread Andreas Pflug
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:

Re: [PATCHES] pg_tablespace_databases

2004-06-28 Thread Andreas Pflug
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

Re: [PATCHES] Compiling libpq with VisualC

2004-06-20 Thread Andreas Pflug
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

Re: [PATCHES] Tablespace patch review

2004-06-19 Thread Andreas Pflug
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

Re: [PATCHES] Tablespace patch review

2004-06-19 Thread Andreas Pflug
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

Re: [PATCHES] Tablespace patch review

2004-06-19 Thread Andreas Pflug
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,

Re: [PATCHES] Tablespace patch review

2004-06-19 Thread Andreas Pflug
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   2   >