Nabble - PostgreSQL - hackers-win32

sos, help me

2007-04-24T23:43:04Z

as I installed the postgresql, and also get the postgresql code. after that, I also installed the cygwin on my computer( as my os is windows xp). but now I wonder what's my next step. as I have extends some aspects in the postgresql spatial data. can you give me some suggestions on how should I go on? thankyou!
I just wanto know how to build the postgresql in windows.
can you give me some tips. although I have look up the doc of postgresql8.2, but havenot gotten the wondering things. as the doc puzzled me.

thankyou

Re: Query on support for trigger functions defined in a Shared library in Windows

2006-01-27T09:44:45Z

Hi,

Here's a weird scenario that seems to be coming out of so many different
options.
a) When the dll is placed in C:\Program Files\PostgreSQL\8.0\bin it
works.
b) When the dll is placed in C:\Program Files\Test\lib, it fails if
dynamic_library_path is set to 'C:\Program Files\Test\lib;$libdir'

However I had help from two people on this,
i) Jean Marc: Replace \ with / i.e dynamic_library_path is set to
'C:/Program Files/Test/lib;$libdir'
ii) Thomas Hallgreen: Do \\ instead of just \. i.e. dynamic_library_path
is set to 'C:\\Program Files\\Test\\lib;$libdir'

Now both of these "start to" work after some time only. There is no
logic that I can explain as to how they work.
Here's what I have tried to do to understand this behavior.

a) Uninstall postgres completely and delete the data folder.
b) Re-install Postgres.
c) Modify the postgresql.conf file with either of the methods. I used
method (ii) since it is more Windows like.
d) Modify the System Variable PATH to contain the extra term "C:\Program
Files\Test\lib"
d) Now I stop the service, start the service. I even rebooted my system.
e) On a new command prompt, I test it out ... Error as before. I can
verify the PATH variable does have C:\Program Files\Test\lib in it.
f) Anyways since I can't do much, I go back and add the dll to the bin
folder and start using it.
g) I can now go back to first command prompt and retest it starts to
work!!!. It works with libdir.
i)I can also go back and modify and delete the dll file that I placed in
the bin folder.
j) I can again retest the dll and it works fine.

Infact it starts to take the dynamic path perfectly.
test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
trigger
test-# AS 'testrigfuncs'
test-# LANGUAGE C ;
CREATE FUNCTION
test=# \q

I have tried this on 4 different systems running Windows XP (Service
Packs 1 & 2) using PostgreSQL 8.0 as well as PostgreSQL 8.1.
Any clues as to why it won't work till I placed the dll in
Postgresql\bin folder and then once I have placed the dll there and
used it, it starts to work at either places even if I delete the dll
from the bin folder.

Thanks & Regards,
Mehul

-----Original Message-----
From: pgsql-hackers-win32-owner@...
[mailto:pgsql-hackers-win32-owner@...] On Behalf Of Magnus
Hagander
Sent: Friday, January 27, 2006 2:32 AM
To: Mehul Doshi-A20614; pgsql-hackers-win32@...
Subject: Re: [pgsql-hackers-win32] Query on support for trigger
functions defined in a Shared library in Windows

> On Windows for the same I get: (Includes extra \ to account for
> Windows)
>
> test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
> trigger
> test-# AS 'C:\\Program Files\\Test\\lib\\testtrigfuncs.dll'
> test-# LANGUAGE C ;
> ERROR: could not load library "C:\Program
> Files\Test\lib\testtrigfuncs.dll": The specified module could not be
> found.
>
> I went and modified the dynamic_library_path to dynamic_library_path =

> 'C:\Program Files\Test\lib;$libdir'
>
> I also added C:\Program Files\Test\lib to the PATH variable.
> I restarted postgres service and then retried the below.

Are you sure you added this to the SYSTEM path and not the USER path?
Because if it's the second, it won't affect the pg service. I'd also try
a reboot after changing the one in SYSTEM - I've seen cases where it
didn't "take" even if the service was restarted.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Query on support for trigger functions defined in a Shared library in Windows

2006-01-27T02:00:51Z

2006/1/24, Mehul Doshi-A20614 <mehul@...>:

> This is related to the problem that I faced some time ago. I have
> created a dll library file with inbuilt constraints and triggers.
> I also built the same for Linux environment. Here's what I am facing.
> Any clues as to what I am doing wrong?
>
> Linux: Fedora Core 2 Running Postgresql 7.4.2
> Windows: Windows XP Service Pack 2 running PostgreSQL 8.1.2
>
> The testtrigfuncs.dll is placed in C:\Program Files\Test\lib\ directory
> and in Linux it is placed in /opt/WMS/rel/lib/testtrigfuncs.so
>
> On linux when I do the following it works:
> createdb test
> test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
> trigger
> test-# AS '/opt/WMS/rel/lib/testtrigfuncs.so'
> test-# LANGUAGE C ;
> CREATE FUNCTION
> test=#
>
> On Windows for the same I get: (Includes extra \ to account for Windows)
>
> test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
> trigger
> test-# AS 'C:\\Program Files\\Test\\lib\\testtrigfuncs.dll'
> test-# LANGUAGE C ;
> ERROR: could not load library "C:\Program
> Files\Test\lib\testtrigfuncs.dll": The specified module could not be
> found.

Surround the path with extra "" because of the space in the path.

AS '"C:\\Program Files\\Test\\lib\\testtrigfuncs.dll"'

Or better move your lib to a path without spaces.

> I went and modified the dynamic_library_path to
> dynamic_library_path = 'C:\Program Files\Test\lib;$libdir'
>
> I also added C:\Program Files\Test\lib to the PATH variable. I restarted
> postgres service and then retried the below.
>
> test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
> trigger
> test-# AS 'C:\Program Files\Test\lib\testtrigfuncs.dll'
> test-# LANGUAGE C ;
> ERROR: component in parameter "dynamic_library_path" is not an absolute
> path
> test=#
>
> What is this absolute path? Where do I set it? While I know that if I
> place
> testtrigfuncs.dll in C:\Program Files\PostgreSQL\8.1\bin folder and do
> the
> same it works.
>
> test=# CREATE OR REPLACE FUNCTION trigf_stdhlr_pid_insert() RETURNS
> trigger
> test-# AS 'C:\\Program Files\\PostgreSQL\\8.1\\bin\\testtrigfuncs.dll'
> test-# LANGUAGE C ;
> CREATE FUNCTION
> test=#
>
> Any clues on what I need to do to go ahead would be great. I want to be
> able to do the
> same thing on both Linux and Windows without having to write in
> PostgreSQL\bin folder
> where my program has no use of being there.
>
> Thanks & Regards,
> Mehul
>
>
>
> -----Original Message-----
> From: Mehul Doshi-A20614
> Sent: Wednesday, July 27, 2005 8:35 AM
> To: 'Magnus Hagander'; pgsql-hackers-win32@...
> Cc: Mehul Doshi-A20614
> Subject: RE: [pgsql-hackers-win32] Query on support for trigger
> functions defined in a Shared library in Windows
>
>
>
> Hi Magnus,
>
> Thanks. That helped me. I used MingW to compile the code. I still used
> 8.0.0 because it is the version that we are currently working on. I will
> migrate to 8.0.3 once I am Able to validate the entire setup.
>
> I did get another problem, if you could help me out, it would be great.
> Problem Description:
> 1) I generated the dll using the code.
> 2) Added the following in postgresql.conf:
> dynamic_library_path = 'C:\test\lib,$libdir'
> The above didn't work so I went ahead and copied the dll into C:\Program
> Files\PostgreSQL\8.0\lib\
> 3) I restarted the postmaster both times. I got this error both times.
> :25: ERROR: could not load library "C:/Program
> Files/PostgreSQL/8.0/lib/testtrigfuncs.dll": dynamic load error
>
> The log shows:
> 2005-07-26 22:38:07 DEBUG: InitPostgres
> 2005-07-26 22:38:07 DEBUG: StartTransaction
> 2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: DEFAULT;
> state: INPROGR, xid/subid/cid: 33475/1/0, nestlvl: 1, children: <>
> 2005-07-26 22:38:07 DEBUG: CommitTransaction
> 2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: STARTED;
> state: INPROGR, xid/subid/cid: 33475/1/0, nestlvl: 1, children: <>
> 2005-07-26 22:38:07 DEBUG: StartTransactionCommand
> 2005-07-26 22:38:07 DEBUG: StartTransaction
> 2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: DEFAULT;
> state: INPROGR, xid/subid/cid: 33476/1/0, nestlvl: 1, children: <>
> 2005-07-26 22:38:07 DEBUG: ProcessUtility
> 2005-07-26 22:38:07 DEBUG: find_in_dynamic_libpath: trying "C:/Program
> Files/PostgreSQL/8.0/lib/testtrigfuncs.dll"
> 2005-07-26 22:38:07 ERROR: could not load library "C:/Program
> Files/PostgreSQL/8.0/lib/testtrigfuncs.dll": dynamic load error
> 2005-07-26 22:38:07 DEBUG: proc_exit(0)
> 2005-07-26 22:38:07 DEBUG: shmem_exit(0)
> 2005-07-26 22:38:07 DEBUG: exit(0)
>
> However, when I ran the newly compiled postgres code (along with my test
> dll in /usr/local/pgsql/lib) via msys. It didn't give me any such errors
> and everything worked out fine. I don't know what I need to do to make
> this dll which I built run with the already installed version of
> PostgreSQL (8.0.0). I can upgrade it to 8.0.3 if it solves the problem.
>
> Please let me know. Thanks & have a nice day.
>
>
> Thanks & Regards,
> Mehul
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@... so that your
> message can get through to the mailing list cleanly
>

--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Query on support for trigger functions defined in a Shared library in Windows

2006-01-27T00:31:59Z

> On Windows for the same I get: (Includes extra \ to account
> for Windows)
>
> test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert()
> RETURNS trigger
> test-# AS 'C:\\Program Files\\Test\\lib\\testtrigfuncs.dll'
> test-# LANGUAGE C ;
> ERROR: could not load library "C:\Program
> Files\Test\lib\testtrigfuncs.dll": The specified module could
> not be found.
>
> I went and modified the dynamic_library_path to
> dynamic_library_path = 'C:\Program Files\Test\lib;$libdir'
>
> I also added C:\Program Files\Test\lib to the PATH variable.
> I restarted postgres service and then retried the below.

Are you sure you added this to the SYSTEM path and not the USER path?
Because if it's the second, it won't affect the pg service. I'd also try
a reboot after changing the one in SYSTEM - I've seen cases where it
didn't "take" even if the service was restarted.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Query on support for trigger functions defined in a Shared library in Windows

2006-01-24T13:21:24Z

Hi,

This is related to the problem that I faced some time ago. I have
created a dll library file with inbuilt constraints and triggers.
I also built the same for Linux environment. Here's what I am facing.
Any clues as to what I am doing wrong?

Linux: Fedora Core 2 Running Postgresql 7.4.2
Windows: Windows XP Service Pack 2 running PostgreSQL 8.1.2

The testtrigfuncs.dll is placed in C:\Program Files\Test\lib\ directory
and in Linux it is placed in /opt/WMS/rel/lib/testtrigfuncs.so

On linux when I do the following it works:
createdb test
test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
trigger
test-# AS '/opt/WMS/rel/lib/testtrigfuncs.so'
test-# LANGUAGE C ;
CREATE FUNCTION
test=#

On Windows for the same I get: (Includes extra \ to account for Windows)

test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
trigger
test-# AS 'C:\\Program Files\\Test\\lib\\testtrigfuncs.dll'
test-# LANGUAGE C ;
ERROR: could not load library "C:\Program
Files\Test\lib\testtrigfuncs.dll": The specified module could not be
found.

I went and modified the dynamic_library_path to
dynamic_library_path = 'C:\Program Files\Test\lib;$libdir'

I also added C:\Program Files\Test\lib to the PATH variable. I restarted
postgres service and then retried the below.

test=# CREATE OR REPLACE FUNCTION trigf_test_pid_insert() RETURNS
trigger
test-# AS 'C:\Program Files\Test\lib\testtrigfuncs.dll'
test-# LANGUAGE C ;
ERROR: component in parameter "dynamic_library_path" is not an absolute
path
test=#

What is this absolute path? Where do I set it? While I know that if I
place
testtrigfuncs.dll in C:\Program Files\PostgreSQL\8.1\bin folder and do
the
same it works.

test=# CREATE OR REPLACE FUNCTION trigf_stdhlr_pid_insert() RETURNS
trigger
test-# AS 'C:\\Program Files\\PostgreSQL\\8.1\\bin\\testtrigfuncs.dll'
test-# LANGUAGE C ;
CREATE FUNCTION
test=#

Any clues on what I need to do to go ahead would be great. I want to be
able to do the
same thing on both Linux and Windows without having to write in
PostgreSQL\bin folder
where my program has no use of being there.

Thanks & Regards,
Mehul

-----Original Message-----
From: Mehul Doshi-A20614
Sent: Wednesday, July 27, 2005 8:35 AM
To: 'Magnus Hagander'; pgsql-hackers-win32@...
Cc: Mehul Doshi-A20614
Subject: RE: [pgsql-hackers-win32] Query on support for trigger
functions defined in a Shared library in Windows

Hi Magnus,

Thanks. That helped me. I used MingW to compile the code. I still used
8.0.0 because it is the version that we are currently working on. I will
migrate to 8.0.3 once I am Able to validate the entire setup.

I did get another problem, if you could help me out, it would be great.
Problem Description:
1) I generated the dll using the code.
2) Added the following in postgresql.conf:
dynamic_library_path = 'C:\test\lib,$libdir'
The above didn't work so I went ahead and copied the dll into C:\Program
Files\PostgreSQL\8.0\lib\
3) I restarted the postmaster both times. I got this error both times.
:25: ERROR: could not load library "C:/Program
Files/PostgreSQL/8.0/lib/testtrigfuncs.dll": dynamic load error

The log shows:
2005-07-26 22:38:07 DEBUG: InitPostgres
2005-07-26 22:38:07 DEBUG: StartTransaction
2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 33475/1/0, nestlvl: 1, children: <>
2005-07-26 22:38:07 DEBUG: CommitTransaction
2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: STARTED;
state: INPROGR, xid/subid/cid: 33475/1/0, nestlvl: 1, children: <>
2005-07-26 22:38:07 DEBUG: StartTransactionCommand
2005-07-26 22:38:07 DEBUG: StartTransaction
2005-07-26 22:38:07 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 33476/1/0, nestlvl: 1, children: <>
2005-07-26 22:38:07 DEBUG: ProcessUtility
2005-07-26 22:38:07 DEBUG: find_in_dynamic_libpath: trying "C:/Program
Files/PostgreSQL/8.0/lib/testtrigfuncs.dll"
2005-07-26 22:38:07 ERROR: could not load library "C:/Program
Files/PostgreSQL/8.0/lib/testtrigfuncs.dll": dynamic load error
2005-07-26 22:38:07 DEBUG: proc_exit(0)
2005-07-26 22:38:07 DEBUG: shmem_exit(0)
2005-07-26 22:38:07 DEBUG: exit(0)

However, when I ran the newly compiled postgres code (along with my test
dll in /usr/local/pgsql/lib) via msys. It didn't give me any such errors
and everything worked out fine. I don't know what I need to do to make
this dll which I built run with the already installed version of
PostgreSQL (8.0.0). I can upgrade it to 8.0.3 if it solves the problem.

Please let me know. Thanks & have a nice day.

Thanks & Regards,
Mehul

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@... so that your
message can get through to the mailing list cleanly

Re: Time to close hackers-win32?

2005-09-19T19:17:26Z

Magnus Hagander wrote:
> > It occurs to me that there is no longer any great need to
> > have a separate hackers list for win32 development. Perhaps
> > we should close it down now and keep all development on -hackers?
>
> I also think this is a good idea. The number of "win32 only issues of
> -hacker level" is significantly smaller now, and having to bounce people
> between the lists can be kind of annoying...

Agreed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@... | (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: don't forget to increase your free space map settings

Re: [HACKERS] Time to close pgsql-cygwin?

2005-09-18T05:07:51Z

Magnus Hagander schrieb:
>>It occurs to me that there is no longer any great need to
>>have a separate hackers list for win32 development. Perhaps
>>we should close it down now and keep all development on -hackers?
>
> I also think this is a good idea. The number of "win32 only issues of
> -hacker level" is significantly smaller now, and having to bounce people
> between the lists can be kind of annoying...

I believe we should close pgsql-cygwin also.

The cygwin users should ask at the official cygwin list as described in
the README and CYGWIN announcements, not at the pgsql-cygwin list.
Most problems are cygwin specific, others are carried in the FAQ_README
and the seperate /usr/share/doc/Cygwin/postgresql-x.x.x.README

If so, I'll write a documentation patch.
--
Reini Urban
http://phpwiki.org/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Time to close hackers-win32?

2005-09-17T06:48:05Z

> It occurs to me that there is no longer any great need to
> have a separate hackers list for win32 development. Perhaps
> we should close it down now and keep all development on -hackers?

I also think this is a good idea. The number of "win32 only issues of
-hacker level" is significantly smaller now, and having to bounce people
between the lists can be kind of annoying...

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@... so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Time to close hackers-win32?

2005-09-16T07:26:03Z

> It occurs to me that there is no longer any great need to have a
> separate hackers list for win32 development. Perhaps we should close
it
> down now and keep all development on -hackers?

agreed. The more development centered stuff belongs on -hackers and the
really win32 specific stuff should be on -ports, the traffic has slowed
down to the point where it hopefully won't take over that list...

Merlin

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Time to close hackers-win32?

2005-09-16T04:54:10Z

It occurs to me that there is no longer any great need to have a
separate hackers list for win32 development. Perhaps we should close it
down now and keep all development on -hackers?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Server Time Setting

2005-09-15T10:59:54Z

Lane Van Ingen wrote:

>If I am following this correctly, I may have solved the problem for myself
>in
>the Eastern time zone, but this application gets deployed around the world,
>anywhere at sea that a vessel can go. While I think the vessel sets its time
>based on its home port and keeps it that way through voyage(s), I am won-
>dering if handling of time is still going to give me problems outside of
>time
>zones where DST is being observed.
>
>
>
>

If they set the machine to the home port's time and leave it there that
should be no problem, as long as they select DST adjustment if it's a
zone that uses DST. In fact I suspect they can set it anyway, regardless
of TZ, because if the zone doesn't have DST nothing should happen. Test
it and see.

The trouble with any sort of detection/correction would be that if the
DST flag is off we have no idea whether the user has left the time on
the zone's base and so it shows an hour's difference from actual local
time, or if they have set it to the DST time manually and thus more or
less lied about the value of UTC. I've seen both happen, many times.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Server Time Setting

2005-09-15T10:37:24Z

Andrew Dunstan <andrew@...> writes:
> Tom Lane wrote:
>> Should pgtz.c try to detect this situation and handle it by mapping to a
>> non-DST-aware internal timezone?

> I think this is a simple case of misconfiguration and I suspect fiddling
> with it would just open up the possibility of more errors.

Maybe. The other thing that's worrisome here is the likelihood that
people would fiddle with the setting after starting Postgres; which
is a scenario we really can't do much about, but AFAICS it would have
the same effect that now() would deviate from what the system clock
is showing.

I'm not sure it's worth the trouble to try to handle the "box not
checked" case fully --- as you say, anyone who's handling DST by
manually adjusting the system clock twice a year is going to lose
anyway. But if we can detect that setting easily, maybe we could just
insist that it match the behavior we're expecting (ie, fail to find a
matching timezone and complain about it)? It seems to me better that
there be an obvious failure immediately than that the system appear to
work only to start giving wrong answers after the next time change.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Server Time Setting

2005-09-15T10:20:17Z

"Lane Van Ingen" <lvaningen@...> writes:
> Looks like I may have just solved my own problem: I noticed that in Date
and
> Time Properties of the Windows clock, on the Time Zone tab, there is a
> checkbox
> called "Automatically adjust clock for daylight savings time changes".

> If that box is unchecked, PostgreSQL must try to compensate, because on
> those
> platforms that are unchecked is where I am having the problem of now()
> returning
> a date that is one hour later. It now works correctly.

Hmm. I think the way that the code in pgtz.c is set up, it just assumes
that either "Eastern Standard Time" or "Eastern Daylight Time" should
map to our US/Eastern timezone (which is a DST-aware zone). Running
your system in non-DST-aware mode is what's confusing it --- the offset
to GMT is an hour different than it "should be" at this time of year.

Should pgtz.c try to detect this situation and handle it by mapping to a
non-DST-aware internal timezone?

regards, tom lane

I think this is a simple case of misconfiguration and I suspect fiddling
with it would just open up the possibility of more errors. If you say
you are in a DST timezone and you don't check the DST checkbox, and you
set the time to summer time then you're asking for trouble. I would not
be at all surprised if the machine's idea of UTC was an hour out
(Windows boxes keep the RTC on local time, not UTC, which is just horrid).

cheers

andrew (dunstan)

If I am following this correctly, I may have solved the problem for myself
in
the Eastern time zone, but this application gets deployed around the world,
anywhere at sea that a vessel can go. While I think the vessel sets its time
based on its home port and keeps it that way through voyage(s), I am won-
dering if handling of time is still going to give me problems outside of
time
zones where DST is being observed.
Lane Van Ingen

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Server Time Setting

2005-09-15T10:07:26Z

Tom Lane wrote:

>Hmm. I think the way that the code in pgtz.c is set up, it just assumes
>that either "Eastern Standard Time" or "Eastern Daylight Time" should
>map to our US/Eastern timezone (which is a DST-aware zone). Running
>your system in non-DST-aware mode is what's confusing it --- the offset
>to GMT is an hour different than it "should be" at this time of year.
>
>Should pgtz.c try to detect this situation and handle it by mapping to a
>non-DST-aware internal timezone?
>
>
>
>

I think this is a simple case of misconfiguration and I suspect fiddling
with it would just open up the possibility of more errors. If you say
you are in a DST timezone and you don't check the DST checkbox, and you
set the time to summer time then you're asking for trouble. I would not
be at all surprised if the machine's idea of UTC was an hour out
(Windows boxes keep the RTC on local time, not UTC, which is just horrid).

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Server Time Setting

2005-09-15T09:51:14Z

Re: Server Time Setting

2005-09-15T09:16:56Z

Yes, it reads (GMT-05:00) Eastern Time (US & Canada).

Looks like I may have just solved my own problem: I noticed that in Date and
Time Properties of the Windows clock, on the Time Zone tab, there is a
checkbox
called "Automatically adjust clock for daylight savings time changes".

If that box is unchecked, PostgreSQL must try to compensate, because on
those
platforms that are unchecked is where I am having the problem of now()
returning
a date that is one hour later. It now works correctly.

Thanks for causing me to check this out; it looks like my problem is solved!
:-)

-----Original Message-----
From: Obe, Regina DND\MIS [mailto:robe.dnd@...]
Sent: Thursday, September 15, 2005 9:44 AM
To: 'Lane Van Ingen'; 'pgsql-hackers-win32@...'
Subject: RE: [pgsql-hackers-win32] Server Time Setting

When you say time reads correctly for Windows 2003, I assume you also mean
not just the time but that the Time Zone tab of windows 2003 Adjust time
reads "Eastern Time (US & Canada)"?

-----Original Message-----
From: Lane Van Ingen [mailto:lvaningen@...]
Sent: Thursday, September 15, 2005 10:13 AM
To: pgsql-hackers-win32@...
Subject: [pgsql-hackers-win32] Server Time Setting

Tom Lane suggested that perhaps this mailing list would be a better place to
ask the following question ... since we have an application that is very
dependent on the accuracy of timestamps, this is a big issue to us.

-----Original Message-----
From: Tom Lane [mailto:tgl@...]
Sent: Monday, September 12, 2005 6:42 PM
To: Lane Van Ingen
Cc: pgsql-admin@...
Subject: Re: [ADMIN] Server Time Setting

"Lane Van Ingen" <lvaningen@...> writes:
>> I am baffled as to why some of the PostgreSQL functions (like now() )
>> are returning a time which is exactly an hour later than the server's
>> actual system time.

> I'd say you've got TimeZone set to something different than you think
>you do.
> regards, tom lane

Before I asked this question yesterday, I had already checked SHOW ALL and
found only two PostgreSQL config parameters that seemed to apply, and they
appeared to be set properly:
australian_timezones = no
TimeZone = US/Eastern
We are running 8.0.1, Windows 2003.

Since last message, checked 3 other servers, and found that I have the same
problem on two out of three:
Server #1: select now() agreed with Windows time on this one
Server #2: select now() was exactly one hour greater than Windows time
where config parms were set the same as previous paragraph
Server #3: select now() was exactly one hour greater than Windows time,
but config parm was set wrong: TimeZone = Europe/Dublin (don't
know how that happened; makes you wonder if TimeZone has
anything to do with this at all!)

Windows 2003 time was set correctly in all four cases.

Summary:
- one server displays time correctly
- two servers APPEAR to be set correctly in Windows, but time displayed
from now() is one hour greater than Windows time
- one server is set incorrectly (PostgreSQL TimeZone parameter was set to
Dublin/Europe); but TimeZone did not appear to have any effect on the
time being displayed, since now() is displaying time as one hour greater
than Windows time, and Windows time appears to be set correctly

Being as one server is 'doing it right', there must be some difference in
settings, but so far I have not been able to determine what is different.
Windows appeared to be correct in all cases, but PostgreSQL is not.

---------------------------(end of broadcast)---------------------------

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Server Time Setting

2005-09-15T09:16:20Z

> Being as one server is 'doing it right', there must be some difference
in
> settings, but so far I have not been able to determine what is
different.
> Windows appeared to be correct in all cases, but PostgreSQL is not.

Have you ruled out automatic adjustment for daylight savings time?

Merlin

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Server Time Setting

2005-09-15T08:44:12Z

When you say time reads correctly for Windows 2003, I assume you also mean
not just the time but that the Time Zone tab of windows 2003 Adjust time
reads "Eastern Time (US & Canada)"?

-----Original Message-----
From: Lane Van Ingen [mailto:lvaningen@...]
Sent: Thursday, September 15, 2005 10:13 AM
To: pgsql-hackers-win32@...
Subject: [pgsql-hackers-win32] Server Time Setting

Tom Lane suggested that perhaps this mailing list would be a better place to
ask the following question ... since we have an application that is very
dependent on the accuracy of timestamps, this is a big issue to us.

-----Original Message-----
From: Tom Lane [mailto:tgl@...]
Sent: Monday, September 12, 2005 6:42 PM
To: Lane Van Ingen
Cc: pgsql-admin@...
Subject: Re: [ADMIN] Server Time Setting

"Lane Van Ingen" <lvaningen@...> writes:
>> I am baffled as to why some of the PostgreSQL functions (like now() )
>> are returning a time which is exactly an hour later than the server's
>> actual system time.

> I'd say you've got TimeZone set to something different than you think
>you do.
> regards, tom lane

Before I asked this question yesterday, I had already checked SHOW ALL and
found only two PostgreSQL config parameters that seemed to apply, and they
appeared to be set properly:
australian_timezones = no
TimeZone = US/Eastern
We are running 8.0.1, Windows 2003.

Since last message, checked 3 other servers, and found that I have the same
problem on two out of three:
Server #1: select now() agreed with Windows time on this one
Server #2: select now() was exactly one hour greater than Windows time
where config parms were set the same as previous paragraph
Server #3: select now() was exactly one hour greater than Windows time,
but config parm was set wrong: TimeZone = Europe/Dublin (don't
know how that happened; makes you wonder if TimeZone has
anything to do with this at all!)

Windows 2003 time was set correctly in all four cases.

Summary:
- one server displays time correctly
- two servers APPEAR to be set correctly in Windows, but time displayed
from now() is one hour greater than Windows time
- one server is set incorrectly (PostgreSQL TimeZone parameter was set to
Dublin/Europe); but TimeZone did not appear to have any effect on the
time being displayed, since now() is displaying time as one hour greater
than Windows time, and Windows time appears to be set correctly

Being as one server is 'doing it right', there must be some difference in
settings, but so far I have not been able to determine what is different.
Windows appeared to be correct in all cases, but PostgreSQL is not.

---------------------------(end of broadcast)---------------------------

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Server Time Setting

2005-09-15T08:13:21Z

Tom Lane suggested that perhaps this mailing list would be a better place
to ask the following question ... since we have an application that is very
dependent on the accuracy of timestamps, this is a big issue to us.

-----Original Message-----
From: Tom Lane [mailto:tgl@...]
Sent: Monday, September 12, 2005 6:42 PM
To: Lane Van Ingen
Cc: pgsql-admin@...
Subject: Re: [ADMIN] Server Time Setting

"Lane Van Ingen" <lvaningen@...> writes:
>> I am baffled as to why some of the PostgreSQL functions (like now() ) are
>> returning a time which is exactly an hour later than the server's actual
>> system time.

> I'd say you've got TimeZone set to something different than you think
> you do.
> regards, tom lane

Before I asked this question yesterday, I had already checked SHOW ALL and
found only two PostgreSQL config parameters that seemed to apply, and they
appeared to be set properly:
australian_timezones = no
TimeZone = US/Eastern
We are running 8.0.1, Windows 2003.

Since last message, checked 3 other servers, and found that I have the same
problem on two out of three:
Server #1: select now() agreed with Windows time on this one
Server #2: select now() was exactly one hour greater than Windows time
where config parms were set the same as previous paragraph
Server #3: select now() was exactly one hour greater than Windows time,
but config parm was set wrong: TimeZone = Europe/Dublin (don't
know how that happened; makes you wonder if TimeZone has
anything to do with this at all!)

Windows 2003 time was set correctly in all four cases.

Summary:
- one server displays time correctly
- two servers APPEAR to be set correctly in Windows, but time displayed
from now() is one hour greater than Windows time
- one server is set incorrectly (PostgreSQL TimeZone parameter was set to
Dublin/Europe); but TimeZone did not appear to have any effect on the
time being displayed, since now() is displaying time as one hour greater
than Windows time, and Windows time appears to be set correctly

Being as one server is 'doing it right', there must be some difference in
settings, but so far I have not been able to determine what is different.
Windows appeared to be correct in all cases, but PostgreSQL is not.

---------------------------(end of broadcast)---------------------------

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-11T20:27:23Z

Oliver Jowett <oliver@...> writes:
> Tom Lane wrote:
>> So the postmaster-log message may be the best we can do ...
>> but I don't think we should drop the connection.

> Here's a patch to do that; it appears to work as intended on my Linux
> system.

Applied along with some other marginal cleanups.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-11T18:59:46Z

Tom Lane wrote:
> So the postmaster-log message may be the best we can do ...
> but I don't think we should drop the connection.

Here's a patch to do that; it appears to work as intended on my Linux
system.

-O

Index: src/backend/libpq/pqcomm.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/libpq/pqcomm.c,v
retrieving revision 1.178
diff -c -r1.178 pqcomm.c
*** src/backend/libpq/pqcomm.c 30 Jul 2005 20:28:20 -0000 1.178
--- src/backend/libpq/pqcomm.c 12 Sep 2005 00:58:15 -0000
***************
*** 595,612 ****
return STATUS_ERROR;
}

! /* Set default keepalive parameters. This should also catch
! * misconfigurations (non-zero values when socket options aren't
! * supported)
*/
! if (pq_setkeepalivesidle(tcp_keepalives_idle, port) != STATUS_OK)
! return STATUS_ERROR;
!
! if (pq_setkeepalivesinterval(tcp_keepalives_interval, port) != STATUS_OK)
! return STATUS_ERROR;
!
! if (pq_setkeepalivescount(tcp_keepalives_count, port) != STATUS_OK)
! return STATUS_ERROR;
}

return STATUS_OK;
--- 595,607 ----
return STATUS_ERROR;
}

! /* Set default keepalive parameters. We ignore misconfigurations
! * that cause errors -- they will be logged, but won't kill the
! * connection.
*/
! pq_setkeepalivesidle(tcp_keepalives_idle, port);
! pq_setkeepalivesinterval(tcp_keepalives_interval, port);
! pq_setkeepalivescount(tcp_keepalives_count, port);
}

return STATUS_OK;

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Build with Visual Studio & MSVC

2005-09-10T08:29:08Z

-----Original Message-----
From: "Jean-Marc EBER"<jeanmarc.eber@...>
Sent: 10/09/05 14:26:15
To: "Dave Page"<dpage@...>
Cc: "Chuck McDevitt"<cmcdevitt@...>, "pgsql-hackers-win32@..."<pgsql-hackers-win32@...>, "PostgreSQL-development"<pgsql-hackers@...>
Subject: Re: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio & MSVC

>. This would imply that the
> binary native win32 distribution of
> postgresql contains (or that a
> supplementary
> package exists) the libraries (and headers) > that are necessary. Having these
> libraries in mingw format would be nice,
> having them for VC++ would probably be
> very helpful to some of us.

Err, they (libpq and ecpglib) are included in both formats. Admittedley 8.0 missed some headers, but that is already fixed for 8.1.

Regards, Dave

-----Unmodified Original Message-----
Hi all,

A remark linked to the preceding discussion:

Even if I could find some interest in compiling postgresql with Microsoft’s C
compiler, I understand the technical and organizational difficulties implied by
such a feature. If I want to rebuild from sources postgresql, I have to go the
developers way, here use the mingw toolchain.

I think that writing _extensions_ for postgresql is another story.

Even before version 8.0, the binary win32/cygwin distribution contained
precompiled libraries for client side programming with VisualC. This allows you
to write postgresql client code in VC _and_ without rebuilding postgresql yourself.

Something similar (I think it has been discussed earlier but don’t remember the
decisions) should exist for writing UDFs (stored procedures, the main reason for
our use of postgresql compared to commercial databases where this feature is
generally badly documented, to say the least). It would be nice if this was
possible _without_ rebuilding postgresql from sources. This would imply that the
binary native win32 distribution of postgresql contains (or that a supplementary
package exists) the libraries (and headers) that are necessary. Having these
libraries in mingw format would be nice, having them for VC++ would probably be
very helpful to some of us.

Jean-Marc

Dave Page wrote:

>
>
> ------------------------------------------------------------------------
> *From:* pgsql-hackers-owner@...
> [mailto:pgsql-hackers-owner@...] *On Behalf Of *Chuck
> McDevitt
> *Sent:* 09 September 2005 19:38
> *To:* pgsql-hackers-win32@...
> *Cc:* PostgreSQL-development
> *Subject:* [HACKERS] Build with Visual Studio & MSVC
>
> Just for fun, I went through PostgreSQL 8.1 and did a complete build
> using Microsoft’s C and the latest Visual Studio.
>
> With a few minor tweaks, everything compiled with no errors.
>
>
>
> My assumption is that because PostgreSQL is a UNIX/Linux-centric
> project (and gcc/gdb centric), this really isn’t of much interest to
> anyone.
>
> So other than this e-mail, I don’t plan to do anything with this
> except for my own amusement.
>
>
>
> If I’m wrong, and there is some real interest in supporting MSVC,
> let me know, and I’ll put some work into cleaning it up and making
> patches out of it, etc.
>
>
>
> Hi Chuck,
>
>
>
> We discussed this again on list only the other day in fact! Basically
> we're not particulalry interested in supporting VS prject files in place
> of gmake/autoconf, purely because they will undoubtedly cause
> maintenance headaches as the majority of our developers don't have
> Windows boxes, let alone a copy of Visual Studio.
>
>
>
> However, if you need something to keep yourself amused (unless I can
> persuade you to come help out with psqlODBC :-) ), we would be
> interested in patches that allow us to use Microsoft's compiler as an
> alternative to gcc.
>
>
>
> It's interesting to know it built fairly easily though...
>
>
>
> Regards, Dave.
>
>
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: [HACKERS] Build with Visual Studio & MSVC

2005-09-10T07:23:38Z

Hi all,

A remark linked to the preceding discussion:

Even if I could find some interest in compiling postgresql with Microsoft’s C
compiler, I understand the technical and organizational difficulties implied by
such a feature. If I want to rebuild from sources postgresql, I have to go the
developers way, here use the mingw toolchain.

I think that writing _extensions_ for postgresql is another story.

Even before version 8.0, the binary win32/cygwin distribution contained
precompiled libraries for client side programming with VisualC. This allows you
to write postgresql client code in VC _and_ without rebuilding postgresql yourself.

Something similar (I think it has been discussed earlier but don’t remember the
decisions) should exist for writing UDFs (stored procedures, the main reason for
our use of postgresql compared to commercial databases where this feature is
generally badly documented, to say the least). It would be nice if this was
possible _without_ rebuilding postgresql from sources. This would imply that the
binary native win32 distribution of postgresql contains (or that a supplementary
package exists) the libraries (and headers) that are necessary. Having these
libraries in mingw format would be nice, having them for VC++ would probably be
very helpful to some of us.

Jean-Marc

Dave Page wrote:

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Build with Visual Studio & MSVC

2005-09-09T16:05:19Z

Hi,

Sure there is interest in building with VS, at least i would. VS has great
debugging suport, i
mean the IDE. Would be nice to build Postgresql and psqlODBC under one VS
project.
I wonder if you could share your VS project and patch to do a complete
building?

thanks,

Alexander

-----Mensagem Original-----
De: Chuck McDevitt
Para: pgsql-hackers-win32@...
Cc: PostgreSQL-development
Enviada em: sexta-feira, 9 de setembro de 2005 15:37
Assunto: [pgsql-hackers-win32] Build with Visual Studio & MSVC

Just for fun, I went through PostgreSQL 8.1 and did a complete build using
Microsoft's C and the latest Visual Studio.
With a few minor tweaks, everything compiled with no errors.

My assumption is that because PostgreSQL is a UNIX/Linux-centric project
(and gcc/gdb centric), this really isn't of much interest to anyone.
So other than this e-mail, I don't plan to do anything with this except for
my own amusement.

If I'm wrong, and there is some real interest in supporting MSVC, let me
know, and I'll put some work into cleaning it up and making patches out of
it, etc.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Build with Visual Studio & MSVC

2005-09-09T13:18:09Z

Dave Page wrote:

>
> Just for fun, I went through PostgreSQL 8.1 and did a complete
> build using Microsoft’s C and the latest Visual Studio.
>
> With a few minor tweaks, everything compiled with no errors.
>
> My assumption is that because PostgreSQL is a UNIX/Linux-centric
> project (and gcc/gdb centric), this really isn’t of much interest
> to anyone.
>
> So other than this e-mail, I don’t plan to do anything with this
> except for my own amusement.
>
> If I’m wrong, and there is some real interest in supporting MSVC,
> let me know, and I’ll put some work into cleaning it up and making
> patches out of it, etc.
>
> Hi Chuck,
>
> We discussed this again on list only the other day in fact! Basically
> we're not particulalry interested in supporting VS prject files in
> place of gmake/autoconf, purely because they will undoubtedly cause
> maintenance headaches as the majority of our developers don't have
> Windows boxes, let alone a copy of Visual Studio.
>
> However, if you need something to keep yourself amused (unless I can
> persuade you to come help out with psqlODBC :-) ), we would be
> interested in patches that allow us to use Microsoft's compiler as an
> alternative to gcc.
>
> It's interesting to know it built fairly easily though...
>

There is also a pgfoundry project for maintaining Visual Studio project
files. see http://pgfoundry.org/projects/vcproject/

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: [HACKERS] Build with Visual Studio & MSVC

2005-09-09T13:08:28Z

> However, if you need something to keep yourself amused (unless I can
> persuade you to come help out with psqlODBC :-) ), we would be
> interested in patches that allow us to use Microsoft's compiler as an
> alternative to gcc.
>
>
>
> It's interesting to know it built fairly easily though...

What would be of interest to me, would be to know if there is an actual
gain to compiling with the Microsoft compiler. I understand the
maintenance issues but if the Microsoft compiler gives us 25% better
performance on Win32 then Mingw...

Sincerely,

Joshua D. Drake

>
>
>
> Regards, Dave.
>
>
>
>
>

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Build with Visual Studio & MSVC

2005-09-09T12:58:01Z

From: pgsql-hackers-owner@... [mailto:pgsql-hackers-owner@...] On Behalf Of Chuck McDevitt
Sent: 09 September 2005 19:38
To: pgsql-hackers-win32@...
Cc: PostgreSQL-development
Subject: [HACKERS] Build with Visual Studio & MSVC

Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsoft’s C and the latest Visual Studio.

With a few minor tweaks, everything compiled with no errors.

My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isn’t of much interest to anyone.

So other than this e-mail, I don’t plan to do anything with this except for my own amusement.

If I’m wrong, and there is some real interest in supporting MSVC, let me know, and I’ll put some work into cleaning it up and making patches out of it, etc.

Hi Chuck,

We discussed this again on list only the other day in fact! Basically we're not particulalry interested in supporting VS prject files in place of gmake/autoconf, purely because they will undoubtedly cause maintenance headaches as the majority of our developers don't have Windows boxes, let alone a copy of Visual Studio.

However, if you need something to keep yourself amused (unless I can persuade you to come help out with psqlODBC :-) ), we would be interested in patches that allow us to use Microsoft's compiler as an alternative to gcc.

It's interesting to know it built fairly easily though...

Regards, Dave.

Build with Visual Studio & MSVC

2005-09-09T12:37:37Z

Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsoft’s C and the latest Visual Studio.

With a few minor tweaks, everything compiled with no errors.

My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isn’t of much interest to anyone.

So other than this e-mail, I don’t plan to do anything with this except for my own amusement.

If I’m wrong, and there is some real interest in supporting MSVC, let me know, and I’ll put some work into cleaning it up and making patches out of it, etc.

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-09T06:14:36Z

Tom Lane wrote:
> > If the connection gets accepted, I'd expect *something* in the
> > postmaster logs -- can you check?
>
> I suspect Merlin's complaint has to do with the fact that the *user*
> doesn't see any error message. The way you've coded this, setsockopt
> failure during startup is treated as a communications failure and so
> there's no attempt to report the problem to the client.

Correct. In fact, when I posted I did completely miss the log message
due to initdb resetting log_destination. Confirmed:
LOG: setsockopt(TCP_KEEPIDLE) not supported
in server log.

Merlin

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-08T18:11:03Z

Tom Lane wrote:

> I'm not sure if we can issue a notice that will be seen on the client
> side at this point in the startup cycle. I seem to recall the protocol
> document advising against sending NOTICEs during the authentication
> cycle.

As currently written the setsockopt() calls are done very early, well
before even ProcessStartupPacket() has run -- so we can't really send
anything at all to the client because we don't even know which protocol
to use.

Delaying the setsockopt() introduces the danger that you could lose the
network at just the wrong time and have a backend sitting around for an
extended period waiting on a startup packet (but not holding locks,
admittedly).

-O

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)

2005-09-08T18:02:23Z

Oliver Jowett <oliver@...> writes:
> We could just log (already done inside pq_*, IIRC) and continue, instead
> of erroring out. It's just the way it is because I personally prefer
> misconfigurations to break loudly, so you have to fix them ;-)

Well, dropping the connection with no message (except in the postmaster
log, which is equivalent to /dev/null for way too many people) isn't
my idea of how to complain "loudly". It just makes the software look
broken.

I'm not sure if we can issue a notice that will be seen on the client
side at this point in the startup cycle. I seem to recall the protocol
document advising against sending NOTICEs during the authentication
cycle. So the postmaster-log message may be the best we can do ...
but I don't think we should drop the connection.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-08T17:49:54Z

Tom Lane wrote:

> Oliver Jowett <oliver@...> writes:
>
>>The assumption I'm making is that if the TCP_* values are present at
>>compile time, then you can make a setsockopt() call and get a sane error
>>code back if there's no support -- rather than a segfault, or having the
>>OS spontaneously do weird things to the connection, or anything like
>>that. Is that a reasonable thing to assume?
>
>
> Well, on a sane OS it's reasonable. I dunno about Windows ;-)
>
> One question to ask is whether we should treat the setsockopt failure
> as fatal or not. It seems to me that aborting the connection could
> reasonably be called an overreaction to a bad parameter setting;
> couldn't we just set the GUC variable to zero and keep going?

There's no real reason why not; currently the code looks like this:

> /* Set default keepalive parameters. This should also catch
> * misconfigurations (non-zero values when socket options aren't
> * supported)
> */
> if (pq_setkeepalivesidle(tcp_keepalives_idle, port) != STATUS_OK)
> return STATUS_ERROR;
>
> if (pq_setkeepalivesinterval(tcp_keepalives_interval, port) != STATUS_OK)
> return STATUS_ERROR;
>
> if (pq_setkeepalivescount(tcp_keepalives_count, port) != STATUS_OK)
> return STATUS_ERROR;

We could just log (already done inside pq_*, IIRC) and continue, instead
of erroring out. It's just the way it is because I personally prefer
misconfigurations to break loudly, so you have to fix them ;-)

-O

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-08T17:48:00Z

Oliver Jowett <oliver@...> writes:
> Merlin Moncure wrote:
>> More
>> significantly, if you change a tcp parameter from the default, the
>> server rejects connections without a relevant error message :(.

> Could you clarify what you mean by "rejects"? Does it accept them and
> then close the connection, or does it fail to even accept the TCP
> connection?

> If the connection gets accepted, I'd expect *something* in the
> postmaster logs -- can you check?

I suspect Merlin's complaint has to do with the fact that the *user*
doesn't see any error message. The way you've coded this, setsockopt
failure during startup is treated as a communications failure and so
there's no attempt to report the problem to the client.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@... so that your
message can get through to the mailing list cleanly

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)

2005-09-08T17:40:15Z

Oliver Jowett <oliver@...> writes:
> The assumption I'm making is that if the TCP_* values are present at
> compile time, then you can make a setsockopt() call and get a sane error
> code back if there's no support -- rather than a segfault, or having the
> OS spontaneously do weird things to the connection, or anything like
> that. Is that a reasonable thing to assume?

Well, on a sane OS it's reasonable. I dunno about Windows ;-)

One question to ask is whether we should treat the setsockopt failure
as fatal or not. It seems to me that aborting the connection could
reasonably be called an overreaction to a bad parameter setting;
couldn't we just set the GUC variable to zero and keep going?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

2005-09-08T17:33:02Z

Tom Lane wrote:

> Oliver Jowett <oliver@...> writes:
>
>>Merlin Moncure wrote:
>>
>>>Even better would be a stronger test to make sure o/s supports this
>>>feature.
>
>
>>Well, the code assumes that if the TCP_* constants are present then they
>>can be used. It seems a bit stupid if Windows defines them but doesn't
>>support them at all.

> In short, if you were assuming that then you'd better fix the code.

Sorry, to clarify: If the TCP_* constants are provided, *and* you
configure the backend to try to use non-default values, then the code
will try the appropriate setsockopt(). If that fails, then the
connection gets dropped.

If you don't change the defaults, it doesn't use setsockopt() at all.

The assumption I'm making is that if the TCP_* values are present at
compile time, then you can make a setsockopt() call and get a sane error
code back if there's no support -- rather than a segfault, or having the
OS spontaneously do weird things to the connection, or anything like
that. Is that a reasonable thing to assume?

...

There doesn't seem any clean way to test if a particular set of values
specified at runtime is going to work or not -- the only way is to try.
I suppose we could set up a dummy TCP connection on postmaster start and
try that, but..

We could potentially do better in the "no TCP_* support" case, detecting
it on postmaster startup (move the check for NULL port down into the
pqcomm code, and complain about non-zero values even in that case if
there's no support); but that doesn't help the other cases.

If I specify out-of-range values on my Linux box, I get this:

> oliver@extrashiny ~ $ pg/8.1-beta1/bin/psql -h localhost template1
> psql: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.

and in the logs:

> LOG: setsockopt(TCP_KEEPIDLE) failed: Invalid argument

I'd expect to see something similar in the "TCP_* present but no real
support" case.

-O

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@... so that your
message can get through to the mailing list cleanly