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

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 ther

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

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??

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

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 t

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

Tom Lane wrote: Bruce Momjian 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 basically could be done usi

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

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, filena

[PATCHES] Binary COPY for psql

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 --- src/bin/psql/c

Re: [PATCHES] CREATE SYNONYM ...

Jonah H. Harris wrote: On 3/13/06, *Peter Eisentraut* <[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: http://msdn2.microso

Re: [PATCHES] CREATE SYNONYM ...

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 DD

Re: [PATCHES] Numeric 508 datatype

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

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 occu

Re: [PATCHES] Numeric 508 datatype

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 won

Re: [PATCHES] Numeric 508 datatype

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] [HACKERS] For review: Server instrumentation patch

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 probab

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

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 compatibilit

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

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 pg_file_stat

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

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_l

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

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( SEL

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

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 no

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

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 somethi

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

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'

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

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

Bruce Momjian wrote: I did not include pg_logdir_ls because that was basically pg_ls_dir with logic to decode the log file name and convert it to a timestamp. That seemed best done in the client. IMHO omitting pg_logdir_ls is a bad idea, because the function is intended to hide server inter

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

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

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] [HACKERS] For review: Server instrumentation patch

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 yesterday

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

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 implement

Re: [HACKERS] [PATCHES] Dbsize backend integration

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

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)

Satoshi Nagayasu wrote: >Hi all, > >Here is a first patch to allow these commands. > > > >>ALTER TABLE ENABLE TRIGGER >>ALTER TABLE DISABLE TRIGGER >> >> > >Bruce said to allow them only super-user, >but currently this patch allows also the table owner. > > > It would be convenient if

Re: [HACKERS] [PATCHES] Dbsize backend integration

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

Re: [PATCHES] Server instrumentation

TION_ARGS) { Oid relOid=PG_GETARG_OID(0); HeapTuple tuple; Form_pg_class pg_class; Oid relnodeOid; Oid tblspcOid; tuple = SearchSysCache(RELOID, ObjectIdGetDatum(relOid), 0, 0, 0); if (!HeapTupleIsValid(tuple)) ereport(ERROR, (ERRCODE_UNDEFINED_TABLE, errmsg("relation with OID %u does not exist"

[PATCHES] win32/MSVC fix for libpq

The attached fix reenables libpq compilation with MSVC6. Regards, Andreas Index: fe-connect.c === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.311 diff -u -r1.311 fe-connect.c --- fe-con

Re: [PATCHES] default database creation with initdb

Robert Treat wrote: On Saturday 18 June 2005 04:55, Andreas Pflug wrote: Magnus Hagander wrote: Umm. Tiny item, but your comment still refers to the database as pg_system ;-) What is the purpose of this database? A generalized, shared resource for tool makers and add-on

Re: [PATCHES] default database creation with initdb

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] default database creation with initdb

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 th

[PATCHES] fsync under win32

The latest fsync patch broke win32 build. There's no fsync under win32, so the #define fsync(fd) _commit(fd) which was removed from port/win32.h in version 1.45 is still necessary. Regards, Andreas Index: win32.h === RCS file: /pro

Re: [PATCHES] dbsize backend integration

Bruce Momjian wrote: Andreas Pflug wrote: 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. How does this related to

Re: [PATCHES] Server instrumentation

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

[PATCHES] Server instrumentation

+mult/2) / mult); else { mult *= 1024; if (size < limit*mult) snprintf(VARDATA(result), 50, INT64_FORMAT " MB", (size+mult/2) / mult); else { mult *= 1024; if (size < limit*mult) snprintf(VARDATA(result), 50, INT64

Re: [PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

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 a

Re: [PATCHES] pg_starttime()

Bruce Momjian wrote: Do we want to make this superuser-only? Yes, random seeds or so might be deducted from it. I'd also propose to name this function pg_postmaster_starttime() to clarify its purpose. There's already a function of that name in the (non-contrib) admin package with the very sa

Re: [PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

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 a report of misbehavior so while the code path is

[PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

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] dbsize backend integration

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 ? dbsize-backen

[PATCHES] was: BUG #1466: syslogger issues

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 recursi

Re: [PATCHES] dbsize patch

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;

Re: [PATCHES] dbsize patch

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 indi

[PATCHES] pg_get_viewdef returns one paren too much

[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 or0

[PATCHES] htmlhelp generation

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

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. "fa_

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

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 it

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

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 comm

Re: [PATCHES] New Translation

[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 th

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

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 random

Re: [PATCHES] dbsize contrib

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: /projects/cvsroot/pgsql-server/contrib/dbsize/README

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

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 wit

Re: [PATCHES] dbsize contrib

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()

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. ... con

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

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. We

Re: [PATCHES] Win32 bug fix

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 c

[PATCHES] dbsize contrib

2004 05:06:35 - 1.12 +++ 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: $ + *

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

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 target

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

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 purg

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

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

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

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

Re: [PATCHES] Compiling libpq with VC6

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 broadcast)--

Re: [PATCHES] Compiling libpq with VC6

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 ful

Re: [PATCHES] Compiling libpq with VC6

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 non-concur

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

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-complian

[PATCHES] Compiling libpq with VC6

libpq currently doesn't compile with vc6. The reason is a conflict of prototypes for rename and unlink, which happens when fe-lobj.c includes io.h. The attached patch will redefine unlink and rename only if FRONTEND is not defined. Regards, Andreas Index: port.h ===

Re: [PATCHES] Win32 Event log

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 exampl

Re: [PATCHES] [HACKERS] libpq problem

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

[EMAIL PROTECTED] wrote: Interesting, After repeating 'make distclean;./configure --without-zlib' I have a pg_config.h *with* HAVE_SYMLINK=1. Sorry, mea culpa. I did a simple clean, not a distclean. Works ok. Regards, Andreas ---(end of broadcast)---

Re: [PATCHES] Win32 tablespace

[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

Bruce Momjian wrote: OK, applied. I moved the funciton into port/dirmod.c and cleaned up the interface for Win32. Would someone test this on Win32 in case I broke something? Yes, something's broken, see patch. Second, HAVE_SYMLINK must be defined somewhere (configure?). Third, a junction is a dir

Re: [PATCHES] Win32 tablespace

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] Autovacuum Integration Patch Take 5

Tom Lane wrote: "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: You're headed in the right direction, but I'm afraid we're running out of time. The core committee has chewed this over and agreed that we can't postpone beta for the amount of time we think it will take to make this patch committab

Re: [PATCHES] logger subprocess including win32

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

Re: [PATCHES] logger subprocess including win32

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 thi

Re: [PATCHES] Win32 tablespace

Bruce Momjian wrote: Andreas Pflug wrote: The attached patch implements a symlink for win32 using junctions, and uses that for win32 tablespaces. Wow, that's, uh, amazing! http://www.codeproject.com/w2k/junctionpoints.asp has a good description of the obfuscated REPARSE_DATA_BUFFER whi

[PATCHES] Win32 tablespace

The attached patch implements a symlink for win32 using junctions, and uses that for win32 tablespaces. Regards, Andreas Index: tablespace.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/tablespace.c,v retrieving

[PATCHES] logger subprocess including win32

------ * * syslogger.c * * The system logger (syslogger) is new in Postgres 7.5. It catches all * stderr output from backends, the postmaster and subprocesses by * redirecting to a pipe, and writes it to a logfile and stderr if * configured. * It&#x

Re: [PATCHES] Admin functions contrib

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

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

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 logge

Re: [PATCHES] Admin functions contrib

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: http://www.pse-consulting.de/pgadmin3/pgadmi

Re: [PATCHES] Admin functions contrib

Bruce Momjian wrote: 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 default-on option as soon as I'm able to prove them how it's working. Uh, but it isn't

Re: [PATCHES] Admin functions contrib

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 d

Re: [PATCHES] Admin functions contrib

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 als

Re: [PATCHES] logger subprocess

OG_DESTINATION_FILE 8 /* Other exported functions */ extern void DebugFileOpen(void); /*- * * syslogger.c * * The system logger (syslogger) is new in Postgres 7.5. It catches all * stderr output from backends, the

Re: [PATCHES] logger subprocess

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 issue:

[PATCHES] Admin functions contrib

gfile_rotate' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_logdir_ls() RETURNS setof record AS 'MODULE_PATHNAME', 'pg_logdir_ls' LANGUAGE C VOLATILE STRICT; CREATE VIEW pg_logdir_ls AS SELECT * FROM pg_logdir_ls() AS A (filetime

[PATCHES] logger subprocess

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 rest

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

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] [HACKERS] Function to kill backend

Would you use a kill operation in the way you describe above if you knew that it had, say, a 1% chance of causing a database-wide PANIC each time you used it? Seems there's the need for some connection killing functionality. If it's not present, the whole cluster needs to be shut down, which mak

Re: [PATCHES] logfile subprocess and Fancy File Functions

Tom Lane wrote: Bruce Momjian wrote: Are we done? Nope, the syslogger part of this is still a mess. I don't want any pg_logfile_rotate() function in there at all: its presence is a hangover from a different design philosophy. No. As I mentioned earlier, there might be cases when a superuser wants

Re: [PATCHES] logfile subprocess and Fancy File Functions

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: /projects/cvsroot/pgsql-server/doc/src/sgml/ca

Re: [PATCHES] logfile subprocess and Fancy File Functions

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

NCTION_ARGS); extern Datum pg_tablespace_databases(PG_FUNCTION_ARGS); +extern Datum pg_logfile_rotate(PG_FUNCTION_ARGS); +extern Datum pg_logdir_ls(PG_FUNCTION_ARGS); + +extern Datum pg_file_stat(PG_FUNCTION_ARGS); +extern Datum pg_file_read

Re: [PATCHES] logfile subprocess and Fancy File Functions

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 the

  1   2   >