Thread: ntfs for windows port rc5-2
why? since an app that I'm working on would be useless for 60% of potential clients, using posgresql with the requirement for ms' corrupted ntfs means postgresql isn't going to work for it. since ms does not include a compiler, and the source for 8.0 won't cross compile from linux. ( gcc 3.3.0 ) whatever happened to targeting lowest common denominator, instead of highest?
On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote: > why? > since an app that I'm working on would be useless for 60% of potential > clients, using posgresql with the requirement for ms' corrupted ntfs > means postgresql isn't going to work for it. I think what you are referring to is the installer refusing to install on a NTFS partition. From the FAQ: http://pginstaller.projects.postgresql.org/FAQ_windows.html 2.4) Can I install PostgreSQL on a FAT partition? PostgreSQL's number one priority is the integrity of your data. FAT and FAT32 filesystems simply do not offer the reliabilty required to allow this. In addition, the lack of security features offered by FAT make it impossible to secure the raw data files from unauthorised modification. Finally, PostgreSQL utilises a feature called 'reparse points' to implement tablespaces. This feature is not available on FAT partitions. <snip> It is recognised however, that on some systems such as developer's PCs, FAT partitions may be the only choice. In such cases, you can simply install PostgreSQL as normal, but without initialising the database cluster. When the installation has finished, manually run the 'initdb.exe' program on the FAT partition. Security and reliability will be compromised however, and any attempts to create tablespaces will fail. > since ms does not include a compiler, and the source for 8.0 won't cross > compile from linux. ( gcc 3.3.0 ) To compile the native port on Windows you need MinGW. And there's always the Cygwin port still. See: http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW Hope this helps, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
Hi, Does anyone know if there is a way to get the backends IP address from the PID? I am using the view pg_stat_activity and it would be nice if it would also display the IP address along with the PID. I can see the IP address when I do a ps -ef but it would be nice to be able to get it via a sql command. Thanks, Tony Caduto http://www.amsoftwaredesign.com
Martijn van Oosterhout wrote: > On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote: > >>why? >>since an app that I'm working on would be useless for 60% of potential >>clients, using posgresql with the requirement for ms' corrupted ntfs >>means postgresql isn't going to work for it. > > > I think what you are referring to is the installer refusing to install > on a NTFS partition. From the FAQ: > > http://pginstaller.projects.postgresql.org/FAQ_windows.html > > 2.4) Can I install PostgreSQL on a FAT partition? > > PostgreSQL's number one priority is the integrity of your data. FAT and > FAT32 filesystems simply do not offer the reliabilty required to allow > this. In addition, the lack of security features offered by FAT make it > impossible to secure the raw data files from unauthorised modification. > Finally, PostgreSQL utilises a feature called 'reparse points' to > implement tablespaces. This feature is not available on FAT partitions. > > <snip> > > It is recognised however, that on some systems such as developer's PCs, > FAT partitions may be the only choice. In such cases, you can simply > install PostgreSQL as normal, but without initialising the database > cluster. When the installation has finished, manually run the > 'initdb.exe' program on the FAT partition. Security and reliability > will be compromised however, and any attempts to create tablespaces > will fail. > > >>since ms does not include a compiler, and the source for 8.0 won't cross >>compile from linux. ( gcc 3.3.0 ) > > > To compile the native port on Windows you need MinGW. And there's > always the Cygwin port still. See: > > http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW > > Hope this helps, rc5-2 msi will not install at all on a fat32 filesystem even without initialising the database. sorry but whole purpose of putting it on a windows box was to make db app for a 250,000 person client base. with some still using win95, some win 98, some winme. all of which do not have ntfs support. since the app will not be world accessable, only through localhost, the lack of security isn't a major concern. -- ======================================== only plain text format email accepted. smaller file size, no virus transfer no proprietary file formats. ========================================
Attachment
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You may wish to consider a different database for your project. SQLite may be a better choice, for example, depending on the project's specific needs (www.sqlite.org). Win95/98/ME is poor technology, no matter how many users it still has. It's probably about time for them to upgrade or switch to another OS (of course, I think Windows in general is a poor technology, but that's for another list...). OTOH, does anyone know if the cygwin version of postgresql enforces the NTFS requirement? That may be another option... On Jan 14, 2005, at 4:39 PM, J. Greenlees wrote: > Martijn van Oosterhout wrote: >> On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote: >>> why? >>> since an app that I'm working on would be useless for 60% of >>> potential clients, using posgresql with the requirement for ms' >>> corrupted ntfs means postgresql isn't going to work for it. >> I think what you are referring to is the installer refusing to install >> on a NTFS partition. From the FAQ: >> http://pginstaller.projects.postgresql.org/FAQ_windows.html >> 2.4) Can I install PostgreSQL on a FAT partition? >> PostgreSQL's number one priority is the integrity of your data. FAT >> and >> FAT32 filesystems simply do not offer the reliabilty required to allow >> this. In addition, the lack of security features offered by FAT make >> it >> impossible to secure the raw data files from unauthorised >> modification. >> Finally, PostgreSQL utilises a feature called 'reparse points' to >> implement tablespaces. This feature is not available on FAT >> partitions. >> <snip> >> It is recognised however, that on some systems such as developer's >> PCs, >> FAT partitions may be the only choice. In such cases, you can simply >> install PostgreSQL as normal, but without initialising the database >> cluster. When the installation has finished, manually run the >> 'initdb.exe' program on the FAT partition. Security and reliability >> will be compromised however, and any attempts to create tablespaces >> will fail. >>> since ms does not include a compiler, and the source for 8.0 won't >>> cross compile from linux. ( gcc 3.3.0 ) >> To compile the native port on Windows you need MinGW. And there's >> always the Cygwin port still. See: >> http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW >> Hope this helps, > rc5-2 msi will not install at all on a fat32 filesystem > even without initialising the database. > sorry but whole purpose of putting it on a windows box was to make db > app for a 250,000 person client base. > with some still using win95, some win 98, some winme. > all of which do not have ntfs support. > > since the app will not be world accessable, only through localhost, > the lack of security isn't a major concern. > > -- > ======================================== > > only plain text format email accepted. > > smaller file size, no virus transfer > no proprietary file formats. > > ======================================== > - ----------------------------------------------------------- Frank D. Engel, Jr. <fde101@fjrhome.net> $ ln -s /usr/share/kjvbible /usr/manual $ true | cat /usr/manual | grep "John 3:16" John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB6EOs7aqtWrR9cZoRAtGcAKCDdfxAWPzNw23+hJ/t9xObxoP+kACfTz1T eD6NOkOnIcok1U3iSGnjxyo= =P26l -----END PGP SIGNATURE----- ___________________________________________________________ $0 Web Hosting with up to 120MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com
Frank D. Engel, Jr. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You may wish to consider a different database for your project. SQLite > may be a better choice, for example, depending on the project's specific > needs (www.sqlite.org). > > Win95/98/ME is poor technology, no matter how many users it still has. > It's probably about time for them to upgrade or switch to another OS (of > course, I think Windows in general is a poor technology, but that's for > another list...). > > OTOH, does anyone know if the cygwin version of postgresql enforces the > NTFS requirement? That may be another option... > I'll check sqllite out, thanks for the tip on it. not sure about the cygwin, but don't really want to cause clients to have to install and run extra services that shouldn't be needed. I agree about windows, not worth using at all. -- ======================================== only plain text format email accepted. smaller file size, no virus transfer no proprietary file formats. ========================================
Attachment
I don't think that Windows isn't worth using some versions such as XP are quite
stable for most purposes. By no means am I saying go put a production database
server like Postgres or Oracle on it. SMB's (Small - to - Medium Businesses) may
benefit from Windows 2000 if there aren't able to get somebody who can manage
Linux/Unix in their environment and don't have a heavy load.
Cheers,
Aly.
> I agree about windows, not worth using at all.
--
Aly Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
On Fri, Jan 14, 2005 at 02:29:47PM -0600, Tony Caduto wrote:
> Does anyone know if there is a way to get the backends IP address from
> the PID?
Do you mean the IP address of the backend (the server) or the address
of the client that's using that backend?
PostgreSQL 8.0 will have inet_client_addr() and inet_server_addr()
functions to get the client and backend IP addresses for the current
session, but I'm not aware of a way to get another session's IP
addresses via an SQL query.
> I am using the view pg_stat_activity and it would be nice if it would
> also display the IP address along with the PID.
That probably wouldn't be hard to add -- consider submitting a patch
or suggesting it to the developers.
> I can see the IP address when I do a ps -ef but it would be nice to be
> able to get it via a sql command.
A workaround would be to write a function that runs ps, netstat,
lsof, etc., and extracts the IP address from the command's output.
Here's a set-returning plperlu example that works with PostgreSQL
8.0.0rc5 on FreeBSD 4.11:
CREATE TYPE pid_ip AS (
pid integer,
ipaddr inet
);
CREATE FUNCTION backend_client_ips() RETURNS SETOF pid_ip AS $$
my $psprog = "/bin/ps";
my $rows;
if (open(my $ps, "-|", $psprog, $pid)) {
while (<$ps>) {
if (/^\s*(\d+).*postmaster: \S+ \S+ (\d+\.\d+\.\d+\.\d+)/) {
push @$rows, {pid => $1, ipaddr => $2};
}
}
close $ps;
} else {
elog ERROR, "$psprog: $!";
}
return $rows;
$$ LANGUAGE plperlu VOLATILE;
SELECT * FROM backend_client_ips();
pid | ipaddr
-------+-----------
78563 | 10.1.0.1
78566 | 127.0.0.1
78573 | 10.1.0.2
(3 rows)
SELECT i.ipaddr, a.*
FROM pg_stat_activity AS a
LEFT OUTER JOIN backend_client_ips() AS i ON i.pid = a.procpid;
ipaddr | datid | datname | procpid | usesysid | usename | current_query | query_start
-----------+-------+---------+---------+----------+---------+---------------+-------------------------------
| 26492 | test | 78575 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:51.816278-07
10.1.0.2 | 26492 | test | 78573 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:34.224116-07
10.1.0.1 | 26492 | test | 78563 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:39.294674-07
127.0.0.1 | 26492 | test | 78566 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:14.276227-07
(4 rows)
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
>rc5-2 msi will not install at all on a fat32 filesystem >even without initialising the database. Really? The code for checking the filesystem type is only executed if you chose to initdb, so I really don't see this happening. Exactly what message do you get? >sorry but whole purpose of putting it on a windows box was to make db >app for a 250,000 person client base. >with some still using win95, some win 98, some winme. >all of which do not have ntfs support. This is a different thing. We don't support 9x for a *lot* of reasons. The lack of NTFS is a very minor one. There are a *lot* of other things that are just not inmplemented, or so badly implemented it's unusable, in these systems. Your only option in this case is the Cygwin version, where a huge amount of work has gone into re-implementing these things in teh Cygwin framework. AFAIK it works on 9x - as well as anything can ;-) >since the app will not be world accessable, only through >localhost, the >lack of security isn't a major concern. If you're even considering Win9x, security is clearly not a concern :-) //Magnus
Magnus Hagander wrote: >>rc5-2 msi will not install at all on a fat32 filesystem >>even without initialising the database. > > > Really? The code for checking the filesystem type is only executed if > you chose to initdb, so I really don't see this happening. Exactly what > message do you get? > Log in the temp install dir: The Cacls command can be run only on disk drives that use the NTFS file system I'll have to rip half or more of the full log as it seems to be to large for the list to accept -- ======================================== only plain text format email accepted. smaller file size, no virus transfer no proprietary file formats. ========================================
Attachment
>>>rc5-2 msi will not install at all on a fat32 filesystem >>>even without initialising the database. >> >> >> Really? The code for checking the filesystem type is only executed if >> you chose to initdb, so I really don't see this happening. >Exactly what >> message do you get? >> >Log in the temp install dir: >The Cacls command can be run only on disk drives that use the >NTFS file >system > >I'll have to rip half or more of the full log as it seems to >be to large >for the list to accept I assume you are talking about the initdb.log file? That file is created by initdb.bat, which should only be called when you choose to run initdb. Exactly which options did you specify during the installation? //Magnus
Magnus Hagander wrote: >>>>rc5-2 msi will not install at all on a fat32 filesystem >>>>even without initialising the database. >>> >>> >>>Really? The code for checking the filesystem type is only executed if >>>you chose to initdb, so I really don't see this happening. >> >>Exactly what >> >>>message do you get? >>> >> >>Log in the temp install dir: >>The Cacls command can be run only on disk drives that use the >>NTFS file >>system >> >>I'll have to rip half or more of the full log as it seems to >>be to large >>for the list to accept > > > I assume you are talking about the initdb.log file? That file is created > by initdb.bat, which should only be called when you choose to run > initdb. Exactly which options did you specify during the installation? > > //Magnus > with msi installer, options are only for where to install, until initdb stage. chose no at that point, and it installs, then errors and completely un-installs. leaving a dir struct under program files with a single file: pgperm.log under the directory with the msi files in it there is a full install log, which the list has twice refused to accept as being to large.
> >>Log in the temp install dir: > >>The Cacls command can be run only on disk drives that use the NTFS > >>file system > >> > >>I'll have to rip half or more of the full log as it seems to be to > >>large for the list to accept > > > > > > I assume you are talking about the initdb.log file? That > file is created > > by initdb.bat, which should only be called when you choose to run > > initdb. Exactly which options did you specify during the > installation? > > > > //Magnus > > > with msi installer, options are only for where to install, > until initdb > stage. (I assume you entered a service username and password as well, because there is no way to get past that dialog without it) > chose no at that point, and it installs, then errors and > completely un-installs. > leaving a dir struct under program files with a single file: > pgperm.log > under the directory with the msi files in it there is a full install > log, which the list has twice refused to accept as being to large. Ok. There is indeed a bug here. Seems this codepath is not exercised a lot - most people follow the advice not to store their data on FAT ;-) And the other tests just exercised the case when you didn't do a service install at all. The pgperm.bat file incorrectly tries to do cacls on the DATA directory even if it's installed on FAT. It correctly skips the bin, lib, share etc paths, but not DATA. Dave has committed a fix for this and it will be in the release. //Magnus
> > chose no at that point, and it installs, then errors and completely > > un-installs. > > leaving a dir struct under program files with a single file: > > pgperm.log > > under the directory with the msi files in it there is a > full install > > log, which the list has twice refused to accept as being to large. > > Ok. There is indeed a bug here. Seems this codepath is not > exercised a lot - most people follow the advice not to store > their data on FAT ;-) And the other tests just exercised the > case when you didn't do a service install at all. > > The pgperm.bat file incorrectly tries to do cacls on the DATA > directory even if it's installed on FAT. It correctly skips > the bin, lib, share etc paths, but not DATA. > > Dave has committed a fix for this and it will be in the release. Actually, we just uploaded RC5-3 to the pgFoundry site with this fix in it if you need it faster. //Magnus
Tony Caduto wrote:
> Hi,
> Does anyone know if there is a way to get the backends IP address from
> the PID?
> I am using the view pg_stat_activity and it would be nice if it would
> also display the IP address along with the PID.
>
> I can see the IP address when I do a ps -ef but it would be nice to be
> able to get it via a sql command.
Added to TODO:
* Add IP address to pg_stat_activity
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Tony Caduto wrote: >> Hi, >> Does anyone know if there is a way to get the backends IP address from >> the PID? >> I am using the view pg_stat_activity and it would be nice if it would >> also display the IP address along with the PID. >> >> I can see the IP address when I do a ps -ef but it would be nice to be >> able to get it via a sql command. > > Added to TODO: > > * Add IP address to pg_stat_activity > While this does not involve the POD, but doesn't this give the IP address of the host: select inet_server_addr() Or is he talking about something else? --BMT
Berend Tober wrote:
> > Tony Caduto wrote:
> >> Hi,
> >> Does anyone know if there is a way to get the backends IP address from
> >> the PID?
> >> I am using the view pg_stat_activity and it would be nice if it would
> >> also display the IP address along with the PID.
> >>
> >> I can see the IP address when I do a ps -ef but it would be nice to be
> >> able to get it via a sql command.
> >
> > Added to TODO:
> >
> > * Add IP address to pg_stat_activity
> >
>
> While this does not involve the POD, but doesn't this give the IP address of
> the host:
>
> select inet_server_addr()
>
> Or is he talking about something else?
Yes, I updated the TODO:
* Add the client IP address to pg_stat_activity
and while there is a client version that does your connection, it
doesn't work for other connections.
I think we should display all the info we show in ps -ef in
pg_stat_activity and the one piece we don't give currently is the client
address.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Saturday 12 February 2005 4:09 pm, Bruce Momjian wrote: > Added to TODO: > > * Add IP address to pg_stat_activity I like it. How about IP and port to differentiate multiple connections from the same host? Will this support IPV6? Cheers, Steve
Bruce, On another note, is there plans to improve the type checking of stored functions during the save/compile? Currently I can pretty much make tons of mistakes (on purpose of course :-) and they are not flagged as errors until runtime. The biggest complaint I see from other DBAs (MS SQL, Oracle) is that Postgres does little to no pre-runtime type checking. Thanks, Tony Caduto Bruce Momjian wrote: >Tony Caduto wrote: > > >>Hi, >>Does anyone know if there is a way to get the backends IP address from >>the PID? >>I am using the view pg_stat_activity and it would be nice if it would >>also display the IP address along with the PID. >> >>I can see the IP address when I do a ps -ef but it would be nice to be >>able to get it via a sql command. >> >> > >Added to TODO: > > * Add IP address to pg_stat_activity > > >
Tony Caduto wrote: > Bruce, > On another note, is there plans to improve the type checking of stored > functions during the save/compile? > Currently I can pretty much make tons of mistakes (on purpose of course > :-) and they are not flagged as errors until runtime. > The biggest complaint I see from other DBAs (MS SQL, Oracle) is that > Postgres does little to no pre-runtime type checking. We have no plans to improve that. We do have 'check_function_bodies' which defaults to true and does some checking. Would you give us a particular example you would like improved? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I have hit this as well though unlike Tony my errors are generally not test cases! If for example you mistype a column/variable name inside the function Postgres will create and allow the function to run as long as the path through the function containing the error is not executed. It would be nice to be told about the error on function creation/modification. Although I feel this is almost a feature as it keeps me honest and testing every possible path through my functions a little bit more thoroughly than I might have been doing with Oracle and MSSQL.... It would still be nice to have some idiotproofing. Is there info on what the check_function_bodies does check? Oisin ----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: <tony_caduto@amsoftwaredesign.com> Cc: <pgsql-general@postgresql.org> Sent: Monday, February 21, 2005 10:47 AM Subject: Re: [GENERAL] is there anyway to get the backends IP address from > Tony Caduto wrote: >> Bruce, >> On another note, is there plans to improve the type checking of stored >> functions during the save/compile? >> Currently I can pretty much make tons of mistakes (on purpose of course >> :-) and they are not flagged as errors until runtime. >> The biggest complaint I see from other DBAs (MS SQL, Oracle) is that >> Postgres does little to no pre-runtime type checking. > > We have no plans to improve that. We do have 'check_function_bodies' > which defaults to true and does some checking. Would you give us a > particular example you would like improved? > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.306 / Virus Database: 266.1.0 - Release Date: 2/18/2005 > >
Steve Crawford wrote:
> On Saturday 12 February 2005 4:09 pm, Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Add IP address to pg_stat_activity
>
> I like it. How about IP and port to differentiate multiple connections
> from the same host? Will this support IPV6?
Good point, added:
* Add the client IP address and port to pg_stat_activity
and yes, it would support IPv6.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073