Re: [PATCHES] eventlog fix
Hello,
I just looking under CVS web interface what is stored in pgevent directory
and what is missing.
The files attached with this mail have to be stored in pgevent directory.
MSG01.bin is a bin files, result of Microsoft MC compiler. MC compiler
can be downloaded for free with MS Core SDK but it is not included with MSYS
tools and I didn't find a alternative way to compile MC file.
To summarize MC pgmsgevent.mc command generates pgmsgevent.h pgmsgevent.rc
and MSG1.bin files.
In MC file, we declare a string with %s format, so we can write anything we
want in the future without need to change the definition of this string.
To finish, because DllUnregisterServer and DllRegisterServer are system
defined entry point, we need to export these two functions with their names
without decoration, so we cannot uses auto generated .def files without
handy modifications.
regards
Laurent Ballester
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Laurent Ballester [EMAIL PROTECTED]
Cc: Alvaro Herrera [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Saturday, June 19, 2004 7:13 AM
Subject: Re: [PATCHES] eventlog fix
OK, I have created the following diff to document the pgevent
installation instructions. However, you didn't send me a Makefile for
creating the DLL, and I am not sure how to do that. Would you send me a
`Makefile for src/bin/pgevent? Thanks.
LANGUAGE 0x9,0x1
1 11 MSG1.bin
Makefile
Description: Binary data
MSG1.bin
Description: Binary data
/*-
*
* pgevent.c
* Defines the entry point for pgevent dll.
* The DLL defines event source for backend
*
*
* IDENTIFICATION
*$PostgreSQL$
*
*-
*/
#include windows.h
#include olectl.h
#include string.h
/* Global variables */
HANDLE g_module = NULL; /* hModule of DLL */
/* Prototypes */
STDAPI DllRegisterServer(void) ;
STDAPI DllUnregisterServer(void);
BOOL WINAPI DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved );
/*
* DllRegisterServer --- Instructs DLL to create its registry entries
*/
STDAPI DllRegisterServer(void)
{
HKEY key;
DWORD data;
char buffer[_MAX_PATH];
/* Set the name of DLL full path name. */
if (!GetModuleFileName((HMODULE)g_module, buffer, sizeof(buffer)))
{
MessageBox(NULL, Could not retrieve DLL filename, PostgreSQL
error, MB_OK|MB_ICONSTOP);
return SELFREG_E_TYPELIB;
}
/* Add PostgreSQL source name as a subkey under the Application
key in the EventLog registry key. */
if ( RegCreateKey(HKEY_LOCAL_MACHINE,
SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\PostgreSQL, key) )
{
MessageBox(NULL, Could not create the registry key., PostgreSQL error,
MB_OK|MB_ICONSTOP);
return SELFREG_E_TYPELIB;
}
/* Add the name to the EventMessageFile subkey. */
if (RegSetValueEx(key,
EventMessageFile,
0,
REG_EXPAND_SZ,
(LPBYTE) buffer,
strlen(buffer) + 1))
{
MessageBox(NULL, Could not set the event message file., PostgreSQL error,
MB_OK|MB_ICONSTOP);
return SELFREG_E_TYPELIB;
}
/* Set the supported event types in the TypesSupported subkey. */
data = EVENTLOG_ERROR_TYPE | EVENTLOG_WARNING_TYPE | EVENTLOG_INFORMATION_TYPE;
if (RegSetValueEx(key,
TypesSupported,
0,
REG_DWORD,
(LPBYTE) data,
sizeof(DWORD)))
{
MessageBox(NULL, Could not set the supported types., PostgreSQL error,
MB_OK|MB_ICONSTOP);
return SELFREG_E_TYPELIB;
}
RegCloseKey(key);
return S_OK;
}
/*
* DllUnregisterServer --- Instructs DLL to remove only those entries created through
DllRegisterServer
*/
STDAPI DllUnregisterServer(void)
{
/* Remove PostgreSQL source name as a subkey under the Application
key in the EventLog registry key. */
if ( RegDeleteKey(HKEY_LOCAL_MACHINE,
SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\PostgreSQL) )
{
MessageBox(NULL, Could not delete the registry key., PostgreSQL
error, MB_OK|MB_ICONSTOP);
return SELFREG_E_TYPELIB;
}
return S_OK;
}
/*
* DllMain --- is an optional entry point into a DLL.
*/
BOOL WINAPI DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
if (
Re: [PATCHES] Tablespace patch review
-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, no? No, we can't. Don't forget, everything we do in pgAdmin is via libpq. Regards, Dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Tablespace patch review
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 be a big security hole in many people's view. Accessing pg_class et al using the current sysuseid with acl checking should be ok and satisfy security demands, no? No. If the other user has you locked out from connecting to his database at all, he's probably not going to feel that he should have to disable your access to individual objects inside it. Well he's using my tablespace, so I'd like to know at least the object name. This has some connections to the discussions we periodically have about preventing Joe User from looking at the system catalogs. If we make any changes in this area at all, I would expect them to be in the direction of narrowing access, not widening it to include being able to see other databases' catalogs. Superuser/tablespace owner isn't quite Joe User, I believe. Actually, there seem quite some other cross database/shared table issues (schema default tablespace, dropping user who owns objects) which make it desirable to have superuser readonly access to pg_catalog tables. Maybe a todo for 7.6... Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Tablespace patch review
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, no? No, we can't. Don't forget, everything we do in pgAdmin is via libpq. Yeah, gui on top of cmd line is nasty and a pain in regarding portability. It's not exactly challenging to implement it directly either, that's what I'll do in absence of a serverside solution. I'll redirect all pgadmin user speed complaints about this to Toms personal mailbox ;-) Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pgxs: build infrastructure for extensions v1
Fabien COELHO wrote: Please find attached a patch which provides a working infrastructure for pg extensions such as new gist-based indexes, functions, types... Comments: - Regarding GNUmakefile.in changes: files in directory foo/ must be handled by a makefile in directory foo/, so these changes must be moved to a makefile in config/. - Please don't invent new targets like light-install, install-local. Just install everything in the install target. - The uninstall target may only remove what it installed, not *. - Don't invent new installation directories; there are enough already. Platform dependent data files (which these are) go into/under $(pkglibdir). - Referring to the renaming of all makefiles under contrib/: I'm not in favor of naming makefiles Makefile.foo; it should be foo.mk. This makes it easier for tools that recognize files by extension. - I think this is a good approach PGXS := $(shell pg_config --pgxs) include $(PGXS)/pgxs.mk but why not PGXS := $(shell pg_config --pgxs) include $(PGXS) - Incidentally, the above will fail if pg_config is not installed (yet), so it can't be used in the contrib/ directories. (The contrib directories are at least cleaned by the top-level makefile, this this is a must-fix failure.) - In Makefile.global: -L$(pkglibdir) is not necessary. There are not libraries to link at build time in there. - -I$(includedir) and -L$(libdir) cannot be used. In an average installation that resolves to -I/usr/include and -L/usr/lib, which breaks GCC and other compilers. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] stderr win32 admin check
I plan to resubmit this patch shortly (hopefully during the weekend) including supprot for detecting if running as a service (and thus pick eventlog support). From what I can tell, the rest should be Ok to go, so expect a new one shortly. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Magnus, where are we on this refactoring process. --- Magnus Hagander wrote: * Created function write_stderr(const char *fmt, ...), used before elog can be used. This function will write to stderr on unix and on win32 fconsole. It will write to the eventlog on win32 when running as a service. * Changed all (most? I think I got all) fprintf(stderr,...) to use this function instead. That way, we gain the ability to put all the other preivously-stderr-messages to the eventlog as well. I'm not sure this is a good idea. The remaining uses of stderr were that way for a reason, not because someone had forgot to change them into elog calls. It would be a lot less invasive to just move the privilege check as you originally intended. I figured as long as nothing dangerous (e.g. using memory allocations etc) is done in the function, it should be just as safe as fprintf. On Unix, it does nothing more than a simple fprintf anyway (one call deeper). The only difference in practice is that we can put them in the eventlog on win32 (again, only using calls that are safe in this context). If we do it the other way, we are going to lose these other messages when running as a service on win32 (since we specifically are not using ereport(), per what you say above). Also, this would remove the check so you could do initdb and other operations that are blocked today (that don't go through postmaster.c) when being root, I assumed that was not good either... //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Admin guide tablespace docs
Attached. Thanks, Gavin tablespace-docs.diff.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgxs: build infrastructure for extensions v1
Dear Peter, Thanks a lot for all these comments. I'll try to update my patch in the coming week, or maybe this weekend. Some responses to some of your comments: - Please don't invent new targets like light-install, install-local. Just install everything in the install target. The current status is that there are two targets: install and server-install. As I think that server-install should be the default, I renamed it install, but I wanted to let the old install still available, thus I had to find a name for it, hence light-install. It is the install a packager would like to chose, to have a separate -dev package. - Referring to the renaming of all makefiles under contrib/: I'm not in favor of naming makefiles Makefile.foo; it should be foo.mk. This makes it easier for tools that recognize files by extension. Ok. Actually, the Makefile.pgxs is the template example makefile, so its status is different from others that are to be included. Thanks again, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] eventlog fix
Woh, we aren't requring MS C to compile this feature. Can't it be created by mingw? If not, I don't see what value an MS C compile is going to do for us. --- Laurent Ballester wrote: Hello, I just looking under CVS web interface what is stored in pgevent directory and what is missing. The files attached with this mail have to be stored in pgevent directory. MSG01.bin is a bin files, result of Microsoft MC compiler. MC compiler can be downloaded for free with MS Core SDK but it is not included with MSYS tools and I didn't find a alternative way to compile MC file. To summarize MC pgmsgevent.mc command generates pgmsgevent.h pgmsgevent.rc and MSG1.bin files. In MC file, we declare a string with %s format, so we can write anything we want in the future without need to change the definition of this string. To finish, because DllUnregisterServer and DllRegisterServer are system defined entry point, we need to export these two functions with their names without decoration, so we cannot uses auto generated .def files without handy modifications. regards Laurent Ballester - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Laurent Ballester [EMAIL PROTECTED] Cc: Alvaro Herrera [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 19, 2004 7:13 AM Subject: Re: [PATCHES] eventlog fix OK, I have created the following diff to document the pgevent installation instructions. However, you didn't send me a Makefile for creating the DLL, and I am not sure how to do that. Would you send me a `Makefile for src/bin/pgevent? Thanks. [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] eventlog fix
We require the MS MC compiler to build the BIN file (note - this is not C - this is the Message Compiler). The Ccode should compile fine in mingw. Not requiring it is the reason we'd include the .BIN file in CVS. MC is only needed to *rebuild* it. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Woh, we aren't requring MS C to compile this feature. Can't it be created by mingw? If not, I don't see what value an MS C compile is going to do for us. --- Laurent Ballester wrote: Hello, I just looking under CVS web interface what is stored in pgevent directory and what is missing. The files attached with this mail have to be stored in pgevent directory. MSG01.bin is a bin files, result of Microsoft MC compiler. MC compiler can be downloaded for free with MS Core SDK but it is not included with MSYS tools and I didn't find a alternative way to compile MC file. To summarize MC pgmsgevent.mc command generates pgmsgevent.h pgmsgevent.rc and MSG1.bin files. In MC file, we declare a string with %s format, so we can write anything we want in the future without need to change the definition of this string. To finish, because DllUnregisterServer and DllRegisterServer are system defined entry point, we need to export these two functions with their names without decoration, so we cannot uses auto generated .def files without handy modifications. regards Laurent Ballester - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Laurent Ballester [EMAIL PROTECTED] Cc: Alvaro Herrera [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 19, 2004 7:13 AM Subject: Re: [PATCHES] eventlog fix OK, I have created the following diff to document the pgevent installation instructions. However, you didn't send me a Makefile for creating the DLL, and I am not sure how to do that. Would you send me a `Makefile for src/bin/pgevent? Thanks. [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] eventlog fix
There is also this message compiler - I have no idea of the quality: http://www.volny.cz/xnavara/SimpleMC.zip I believe the WINE project also has one. Putting the .bin file in CVS doesn't seem too horrible to me. cheers andrew Magnus Hagander wrote: We require the MS MC compiler to build the BIN file (note - this is not C - this is the Message Compiler). The Ccode should compile fine in mingw. Not requiring it is the reason we'd include the .BIN file in CVS. MC is only needed to *rebuild* it. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Woh, we aren't requring MS C to compile this feature. Can't it be created by mingw? If not, I don't see what value an MS C compile is going to do for us. --- Laurent Ballester wrote: Hello, I just looking under CVS web interface what is stored in pgevent directory and what is missing. The files attached with this mail have to be stored in pgevent directory. MSG01.bin is a bin files, result of Microsoft MC compiler. MC compiler can be downloaded for free with MS Core SDK but it is not included with MSYS tools and I didn't find a alternative way to compile MC file. To summarize MC pgmsgevent.mc command generates pgmsgevent.h pgmsgevent.rc and MSG1.bin files. In MC file, we declare a string with %s format, so we can write anything we want in the future without need to change the definition of this string. To finish, because DllUnregisterServer and DllRegisterServer are system defined entry point, we need to export these two functions with their names without decoration, so we cannot uses auto generated .def files without handy modifications. regards Laurent Ballester - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Laurent Ballester [EMAIL PROTECTED] Cc: Alvaro Herrera [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 19, 2004 7:13 AM Subject: Re: [PATCHES] eventlog fix OK, I have created the following diff to document the pgevent installation instructions. However, you didn't send me a Makefile for creating the DLL, and I am not sure how to do that. Would you send me a `Makefile for src/bin/pgevent? Thanks. [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Tablespace patch review
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, retrieving tablespace dependencies (pg_class union pg_schema) and closing takes about one second over an ssl connection, 0.2 seconds with non-ssl. This was a trusted connection, can't check what will happen with md5, krb or so. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Tablespace patch review
-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 10 databases, retrieving tablespace dependencies (pg_class union pg_schema) and closing takes about one second over an ssl connection, 0.2 seconds with non-ssl. This was a trusted connection, can't check what will happen with md5, krb or so. Don't suppose you happened to try it on Win32 did you? Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] eventlog fix
Magnus Hagander [EMAIL PROTECTED] writes: We require the MS MC compiler to build the BIN file (note - this is not C - this is the Message Compiler). So is this tool readily available? What does one have to do/buy to lay hands on it? Not requiring it is the reason we'd include the .BIN file in CVS. MC is only needed to *rebuild* it. I'd prefer to avoid having derived files like this in CVS. We do not keep any other derived files in CVS (except configure, which decision seems more and more like a historical artifact). regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Tablespace patch review
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 10 databases, retrieving tablespace dependencies (pg_class union pg_schema) and closing takes about one second over an ssl connection, 0.2 seconds with non-ssl. This was a trusted connection, can't check what will happen with md5, krb or so. Don't suppose you happened to try it on Win32 did you? This was from a win32 workstation (pgadmin3) to a Linux server. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] eventlog fix
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: 19 June 2004 20:03 To: Magnus Hagander Cc: Bruce Momjian; Laurent Ballester; [EMAIL PROTECTED] Subject: Re: [PATCHES] eventlog fix Magnus Hagander [EMAIL PROTECTED] writes: We require the MS MC compiler to build the BIN file (note - this is not C - this is the Message Compiler). So is this tool readily available? What does one have to do/buy to lay hands on it? Download it from http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ (dunno how that'll render outside of IE - it's part of an active setup thingy). It's included with the Windows Platform SDK (which is free). Not requiring it is the reason we'd include the .BIN file in CVS. MC is only needed to *rebuild* it. I'd prefer to avoid having derived files like this in CVS. We do not keep any other derived files in CVS (except configure, which decision seems more and more like a historical artifact). It's a very large download to get the SDK (180MB) - that's a lot of bandwidth for one little derived file that will almost certainly never change. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Compiling libpq with VisualC
Two minor tweaks: sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it isn't used in Linux either; libpq will compile without it. All usages of gettimeofday throughout the backend don't seem connection related, so libpq-be.h seems an odd place to include it. ERROR in elog.h has conflicts with a win32 defined macro; #undef WIN32 solves the conflict (or not including elog.h for libpq purposes would do too) Regards, Andreas Index: include/libpq/libpq-be.h === RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v retrieving revision 1.45 diff -u -r1.45 libpq-be.h --- include/libpq/libpq-be.h21 May 2004 05:08:04 - 1.45 +++ include/libpq/libpq-be.h19 Jun 2004 19:46:52 - @@ -18,7 +18,10 @@ #ifndef LIBPQ_BE_H #define LIBPQ_BE_H +#ifndef WIN32 #include sys/time.h +#endif + #ifdef USE_SSL #include openssl/ssl.h Index: include/utils/elog.h === RCS file: /projects/cvsroot/pgsql-server/src/include/utils/elog.h,v retrieving revision 1.68 diff -u -r1.68 elog.h --- include/utils/elog.h5 Apr 2004 03:02:10 - 1.68 +++ include/utils/elog.h19 Jun 2004 19:46:53 - @@ -14,6 +14,10 @@ #ifndef ELOG_H #define ELOG_H +#ifdef ERROR +#undef ERROR/* possible conflict in win32 */ +#endif + /* Error level codes */ #define DEBUG5 10 /* Debugging messages, in categories of * decreasing detail. */ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] eventlog fix
Dave Page [EMAIL PROTECTED] writes: So is this tool readily available? What does one have to do/buy to lay hands on it? It's included with the Windows Platform SDK (which is free). Oh, good. It's a very large download to get the SDK (180MB) - that's a lot of bandwidth for one little derived file that will almost certainly never change. Hm, that is a lot ... but wouldn't the sort of people interested in hacking PG on Windows likely already have it? If you think not, I'll withdraw my objection to keeping the .BIN in CVS, but I'm just wondering whether we're worrying about something that hackers would have anyway. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] eventlog fix
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 19 June 2004 22:49 To: Dave Page Cc: Magnus Hagander; Bruce Momjian; Laurent Ballester; [EMAIL PROTECTED] Subject: Re: [PATCHES] eventlog fix Hm, that is a lot ... but wouldn't the sort of people interested in hacking PG on Windows likely already have it? If you think not, I'll withdraw my objection to keeping the .BIN in CVS, but I'm just wondering whether we're worrying about something that hackers would have anyway. I have mc.exe, but only because I have paid for Visual Studio. I don't have the platform SDK installed, however I cannot honestly say whether or not I would have it if I didn't have VS. I would include the file in CVS if it were my choice - it's clearly a pain to download the compiler if you don't have it, and the file is unlikely to need updating in the future - it was designed to be a generic DLL that just formats any message as '%s'. Regards Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Compiling libpq with VisualC
Andreas Pflug [EMAIL PROTECTED] writes: sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it isn't used in Linux either; libpq will compile without it. 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? +#ifndef WIN32 #include sys/time.h +#endif Could we please use HAVE_SYS_TIME_H, rather than creating an unnecessary platform specificity? #ifndef ELOG_H #define ELOG_H +#ifdef ERROR +#undef ERROR/* possible conflict in win32 */ +#endif + /* Error level codes */ This seems likely to break anything expecting the Win32 definition of ERROR. Can we look at not including elog.h in frontend builds, instead? I can't think of any reason for frontend code to need it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 00:22
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes:
I'm getting the following error when trying to initdb with CVS tip.
creating template1 database in
C:/msys/1.0/local/pgsql/data/base/1 ...
ERROR: could not open segment 1 of relation 1663/1/1255
(target block
26189776): No such file or directory
The target block number is obviously broken :-(. But maybe
you have a build consistency problem --- did you try a make
distclean and full rebuild?
OK, that cured that one - thanks.
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in initdb.c is responsible for
this, and I see it has WIN32-specific behavior, which is
evidently wrong.
Can you recommend a fix?
The current solution does an rmdir /q /s $PGDATA if the datadir was
created, and del /q /s $PGDATA if the directory already existed. The
second case will not work, as del will not remove directories. AFAICS,
there is no easy way to do this using system() as rmdir won't accept
wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*.
It seems to me that the simple answer is to put Andrew's recursive
unlink code back in (as he suggested), which Bruce removed as rm etc.
were being used in commands/dbcommands.c (which should work fine under
Windows). Patch below
Regards, Dave
*** initdb.c.orig Sat Jun 19 22:15:28 2004
--- initdb.cSat Jun 19 23:02:10 2004
***
*** 132,137
--- 132,144
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static bool rmtree(char *path, bool rmtopdir);
+
+ #ifdef WIN32
+ static int init_unlink(const char *);
+ #else
+ #define init_unlink(x) unlink( (x) )
+ #endif /* WIN32 */
+
static char **replace_token(char **lines, char *token, char
*replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
***
*** 245,264
static bool
rmtree(char *path, bool rmtopdir)
{
! charbuf[MAXPGPATH + 64];
! #ifndef WIN32
! /* doesn't handle .* files, but we don't make any... */
! snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
!rmtopdir ? : /*);
! #else
! snprintf(buf, sizeof(buf), %s /s /q \%s\,
!rmtopdir ? rmdir : del, path);
! #endif
! return !system(buf);
}
/*
* make a copy of the array of lines, with token replaced by
replacement
--- 252,349
static bool
rmtree(char *path, bool rmtopdir)
{
! charfilepath[MAXPGPATH];
! DIR*dir;
! struct dirent *file;
! char **filenames;
! char **filename;
! int numnames = 0;
! struct stat statbuf;
! /*
!* we copy all the names out of the directory before we start
modifying
!* it.
!*
!*/
!
! dir = opendir(path);
! if (dir == NULL)
! return false;
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! numnames++;
! }
!
! rewinddir(dir);
!
! filenames = xmalloc((numnames + 2) * sizeof(char *));
! numnames = 0;
!
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! filenames[numnames++] = xstrdup(file-d_name);
! }
!
! filenames[numnames] = NULL;
!
! closedir(dir);
!
! /* now we have the names we can start removing things */
!
! for (filename = filenames; *filename; filename++)
! {
! snprintf(filepath, MAXPGPATH, %s/%s, path, *filename);
!
! if (stat(filepath, statbuf) != 0)
! return false;
!
! if (S_ISDIR(statbuf.st_mode))
! {
! /* call ourselves recursively for a directory */
! if (!rmtree(filepath, true))
! return false;
! }
! else
! {
! if (init_unlink(filepath) != 0)
! return false;
! }
! }
!
! if (rmtopdir)
! {
! if (rmdir(path) != 0)
! return false;
! }
!
! return true;
}
+ #ifdef WIN32
+
+ /* workaround for win32 unlink bug, not using logging like in
port/dirmod.c */
+
+ /* make sure we call the real unlink from MSVCRT */
+
+ #ifdef unlink
+ #undef unlink
+ #endif
+
+ static int
+ init_unlink(const char *path)
+ {
Re: [PATCHES] Tablespace patch review
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Well, I didn't use tablespaces here so the pg_tablespaces directory is empty, so I can't think of what the tablespace is. You look in the pg_tablespace catalog for the row with that OID. Also, are we calling it pg_tablespaces (plural) rather than pg_tablespace? I didn't have any particular opinion about that till just now ... but now I see that it's a good idea for the pg_tablespaces directory (the one that holds all the symlinks) to have a different name from the pg_tablespace catalog, especially since the latter has a couple of rows that do not correspond to any entries in the former. If you want something distinct, which I understand, perhaps pg_tblspc. I'm not wedded to pg_tablespaces as the name in particular, but it should not be pg_tablespace, or we'll suffer the same confusion over and over that you just did. OK. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Tablespace patch review
Andreas Pflug wrote: 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, retrieving tablespace dependencies (pg_class union pg_schema) and closing takes about one second over an ssl connection, 0.2 seconds with non-ssl. This was a trusted connection, can't check what will happen with md5, krb or so. Well, we could use something like dbsize to report how much disk space is used by each database in the tablespace (it does an 'ls' in the directory as a server-side function), and connect to the database to get actual table names. I can't think of any clean system that would allow access to the table names in other databases without connecting to them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] eventlog fix
Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 19 June 2004 22:49 To: Dave Page Cc: Magnus Hagander; Bruce Momjian; Laurent Ballester; [EMAIL PROTECTED] Subject: Re: [PATCHES] eventlog fix Hm, that is a lot ... but wouldn't the sort of people interested in hacking PG on Windows likely already have it? If you think not, I'll withdraw my objection to keeping the .BIN in CVS, but I'm just wondering whether we're worrying about something that hackers would have anyway. I have mc.exe, but only because I have paid for Visual Studio. I don't have the platform SDK installed, however I cannot honestly say whether or not I would have it if I didn't have VS. I would include the file in CVS if it were my choice - it's clearly a pain to download the compiler if you don't have it, and the file is unlikely to need updating in the future - it was designed to be a generic DLL that just formats any message as '%s'. Agreed. We have to include the .bin file because if we don't, we would have an additional Win32 depenency beyond Mingw. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Compiling libpq with VisualC
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it isn't used in Linux either; libpq will compile without it. 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? +#ifndef WIN32 #include sys/time.h +#endif Could we please use HAVE_SYS_TIME_H, rather than creating an unnecessary platform specificity? The problem is that they are building from win32.mak, and don't run configure at all. Mingw does have it so we can't just skip including it. I think we should test for the MS compiler in this case. Please test for _MSC_VER instead of WIN32 and let us know how it works. #ifndef ELOG_H #define ELOG_H +#ifdef ERROR +#undef ERROR/* possible conflict in win32 */ +#endif + /* Error level codes */ This seems likely to break anything expecting the Win32 definition of ERROR. Can we look at not including elog.h in frontend builds, instead? I can't think of any reason for frontend code to need it. Agreed. We define FRONTEND when compiling libpq. Please test for that and send another patch. Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] eventlog fix
Patch applied, with doc additions I already posted. Please test CVS and let me know how it works. I added a README containing your explaination below for our later reference. I added the MSG01.bin as a binary CVS checkin. --- Laurent Ballester wrote: Hello, I just looking under CVS web interface what is stored in pgevent directory and what is missing. The files attached with this mail have to be stored in pgevent directory. MSG01.bin is a bin files, result of Microsoft MC compiler. MC compiler can be downloaded for free with MS Core SDK but it is not included with MSYS tools and I didn't find a alternative way to compile MC file. To summarize MC pgmsgevent.mc command generates pgmsgevent.h pgmsgevent.rc and MSG1.bin files. In MC file, we declare a string with %s format, so we can write anything we want in the future without need to change the definition of this string. To finish, because DllUnregisterServer and DllRegisterServer are system defined entry point, we need to export these two functions with their names without decoration, so we cannot uses auto generated .def files without handy modifications. regards Laurent Ballester - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Laurent Ballester [EMAIL PROTECTED] Cc: Alvaro Herrera [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 19, 2004 7:13 AM Subject: Re: [PATCHES] eventlog fix OK, I have created the following diff to document the pgevent installation instructions. However, you didn't send me a Makefile for creating the DLL, and I am not sure how to do that. Would you send me a `Makefile for src/bin/pgevent? Thanks. [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
On Sun, 2004-06-20 at 08:04, Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 00:22
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes:
I'm getting the following error when trying to initdb with CVS tip.
creating template1 database in
C:/msys/1.0/local/pgsql/data/base/1 ...
ERROR: could not open segment 1 of relation 1663/1/1255
(target block
26189776): No such file or directory
The target block number is obviously broken :-(. But maybe
you have a build consistency problem --- did you try a make
distclean and full rebuild?
OK, that cured that one - thanks.
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in initdb.c is responsible for
this, and I see it has WIN32-specific behavior, which is
evidently wrong.
Can you recommend a fix?
The current solution does an rmdir /q /s $PGDATA if the datadir was
created, and del /q /s $PGDATA if the directory already existed. The
second case will not work, as del will not remove directories. AFAICS,
there is no easy way to do this using system() as rmdir won't accept
wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*.
It seems to me that the simple answer is to put Andrew's recursive
unlink code back in (as he suggested), which Bruce removed as rm etc.
were being used in commands/dbcommands.c (which should work fine under
Windows). Patch below
you could of course rmdir /s /q $PGDATA mkdir $PGDATA if the purpose
is to leave the directory intact if it already existed prior to install.
Regards,
John
Regards, Dave
*** initdb.c.orig Sat Jun 19 22:15:28 2004
--- initdb.c Sat Jun 19 23:02:10 2004
***
*** 132,137
--- 132,144
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static bool rmtree(char *path, bool rmtopdir);
+
+ #ifdef WIN32
+ static int init_unlink(const char *);
+ #else
+ #define init_unlink(x) unlink( (x) )
+ #endif /* WIN32 */
+
static char **replace_token(char **lines, char *token, char
*replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
***
*** 245,264
static bool
rmtree(char *path, bool rmtopdir)
{
! charbuf[MAXPGPATH + 64];
! #ifndef WIN32
! /* doesn't handle .* files, but we don't make any... */
! snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
! rmtopdir ? : /*);
! #else
! snprintf(buf, sizeof(buf), %s /s /q \%s\,
! rmtopdir ? rmdir : del, path);
! #endif
! return !system(buf);
}
/*
* make a copy of the array of lines, with token replaced by
replacement
--- 252,349
static bool
rmtree(char *path, bool rmtopdir)
{
! charfilepath[MAXPGPATH];
! DIR*dir;
! struct dirent *file;
! char **filenames;
! char **filename;
! int numnames = 0;
! struct stat statbuf;
! /*
! * we copy all the names out of the directory before we start
modifying
! * it.
! *
! */
!
! dir = opendir(path);
! if (dir == NULL)
! return false;
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! numnames++;
! }
!
! rewinddir(dir);
!
! filenames = xmalloc((numnames + 2) * sizeof(char *));
! numnames = 0;
!
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! filenames[numnames++] = xstrdup(file-d_name);
! }
!
! filenames[numnames] = NULL;
!
! closedir(dir);
!
! /* now we have the names we can start removing things */
!
! for (filename = filenames; *filename; filename++)
! {
! snprintf(filepath, MAXPGPATH, %s/%s, path, *filename);
!
! if (stat(filepath, statbuf) != 0)
! return false;
!
! if (S_ISDIR(statbuf.st_mode))
! {
! /* call ourselves recursively for a directory */
! if (!rmtree(filepath, true))
! return false;
! }
! else
! {
! if (init_unlink(filepath) != 0)
! return false;
! }
! }
!
! if (rmtopdir)
! {
! if (rmdir(path) != 0)
! return false;
! }
!
! return true;
}
+ #ifdef
[PATCHES] ALTER TABLE ... SET TABLESPACE
Attached is a patch implementing this functionality. I've modified make_new_heap() as well as swap_relfilenodes() to not assume that tablespaces remain the same from old to new heap. I thought it better to go down this road than introduce a lot of duplicate code. Thanks Gavin altertable.diff.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
