unix domain sockets on Windows.

Does the postgres server support listening on unix domain sockets on windows?  It seems to me that they do
not, but this is not called out directly in the documentation.

Listen_address in postgresql.conf

    listen_addresses = ''      # what IP address(es) to listen on;
                        # comma-separated list of addresses;
                        # defaults to 'localhost', '*' = all
                        # (change requires restart)

The online documentation for listen_address is not specific about whether windows does or does not
support unix-domain sockets.

In pg_hba.conf documentation for local connections (unix domain sockets) we see the following

    local
        This record matches connection attempts using Unix-domain sockets. Without a record of this type,
Unix-domain socket connections are disallowed.

Basically I am wondering if the postgres code substitutes some other windows facility for this functionality.

We do see some notes that certain related parameters (unix_socket_directory (string),
unix_socket_group (string), unix_socket_permissions (integer)) are not supported on windows but
nothing with the basic configuration information.

I have tried to start a server with this configuration an received the following error..

pg_ctl: another server might be running; trying to start server anyway
2011-12-31 16:35:38 PST FATAL:  no socket created for listening
server starting

Re: unix domain sockets on Windows.

On lör, 2011-12-31 at 17:06 -0800, Jeff Rule wrote:
> Does the postgres server support listening on unix domain sockets on windows?

No.

> It seems to me that they do not, but this is not called out directly in the documentation.
> 
> Listen_address in postgresql.conf
> 
>     listen_addresses = ''      # what IP address(es) to listen on;
>                         # comma-separated list of addresses;
>                         # defaults to 'localhost', '*' = all
>                         # (change requires restart)

It says right there that it controls what *IP addresses* to listen to.
It does not have anything to do with Unix-domain sockets.  There are
other options that control whether and where those are created.

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

system is swapping (not actively), why?

good morning to all and happy new year!

i am facing the following situation; there is a server which is using 2-5GB
of swap very often (almost all the time) and i cannot figure out why. i can
provide any information you find useful and i will start what i think is
more relevant to my 'problem'.

-os -> CentOS release 5.6 (Final)
-the server is a dedicated db server with nothing else running there
-postgres version -> 9.0.5
-shared_buffers -> 15 GB

-vm.swapiness = 0

free -m
             total       used       free     shared    buffers     cached
Mem:         64445      61505       2940          0        159      59989
-/+ buffers/cache:       1356      63089
Swap:        32767       1868      30899

vmstat -n -S M 10 5
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id
wa st
 4  0   1867   1533    161  61345    0    0   682   164    0    0  9  1 86 
4  0
 1  0   1867   1286    161  61643    0    0 17932  3224 9776 9957  5  1 94 
0  0
 3  0   1867   1119    161  61802    0    0 12877 13080 3297 2580  5  1 95 

Re: system is swapping (not actively), why?

MirrorX <mirrorx <at> gmail.com> wrote:

> i am facing the following situation; there is a server which is
> using 2-5GB of swap very often (almost all the time) and i cannot
> figure out why.

In the Ubuntu man docs, it says that the swpd column of vmstat is
not affected by the -S switch.  Is that the case in CentOS, too? 
The man docs for free don't say anything about it, but since you're
showing matching values with vmstat, perhaps it holds there, too. 
That would mean 2 MB, not 2 GB, in swap.

We routinely have a few MB of library code swapped out which is
rarely used.  I wouldn't worry as long as the si and so columns of
vmstat report zero under load.

-Kevin

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: system is swapping (not actively), why?

thx a lot for your reply.

i think it is measured in GB
*free*
             total       used       free     shared    buffers     cached
Mem:      65992668   64425924    1566744          0     196932   62767468
-/+ buffers/cache:    1461524   64531144
Swap:     33554424    2105664   31448760

*top *
top - 17:10:32 up 84 days,  8:23,  2 users,  load average: 2.09, 2.12, 2.09
Tasks: 568 total,   5 running, 563 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.0%us,  1.6%sy,  0.0%ni, 90.9%id,  0.1%wa,  0.0%hi,  0.5%si, 
0.0%st
Mem:  65992668k total, 65484676k used,   507992k free,   200644k buffers
Swap: 33554424k total,  2105608k used, 31448816k free, 63781976k cached

--
View this message in context: http://postgresql.1045698.n5.nabble.com/system-is-swapping-not-actively-why-tp5116515p5117416.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: system is swapping (not actively), why?

MirrorX <mirrorx <at> gmail.com> wrote:

> i think it is measured in GB

> Swap:     33554424    2105664   31448760

> Swap: 33554424k total

That sure seems to be the case.

I don't think it change my overall advice -- if you see zero swaps
in or out under load, I wouldn't worry about it.  We tried
configuring our servers to prevent such things, and under careful
benchmarking the effort slightly reduced performance.  Probably
because we were using RAM to hold stuff we didn't need instead of
allowing it to be used for OS caching.

I know some people are fanatic about keeping that swap number at
zero, but in our case it turns out to be best to let the OS do its
thing.

-Kevin

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

lo_import

Hi all,

I'm trying to use lo_import to import a file into my database, if I 
execute from postgres runing in my local machine
it works perfectly, but if I do it in the postgres runing in the server, 
it says "No such file or directory"

I Guess postgres only see file on the machine it is runing and not 
through the network...
I will have to upload the file into the server and then use import  ?   
is there any other way ?

Thanks every one.
Cruz

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: lo_import

Cannot restore dumps made with -Fc and --column-inserts

Hi guys

Running pg on Ubuntu 10.04 64bit, which is 8.4.9 today.
When I do a pg_dump using --column-inserts, the subsequent restore fails:

postgres <at> filesender:~$ pg_dump -Fc --column-inserts filesender -f
filesender_backup.pgdump
postgres <at> filesender:~$ createdb -T template0 fstest
postgres <at> filesender:~$ pg_restore -d fstest filesender_backup.pgdump
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1785; 0 16390 TABLE
DATA files fs_user
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax
error at end of input
LINE 6: ...lesubject, filevoucheruid, filemessage, filefrom, filesize,
                                                                       ^
    Command was: INSERT INTO files (fileto, filesubject,
filevoucheruid, filemessage, filefrom, filesize, fileoriginalname,
filestatus, filei...
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax
error at or near "fileoriginalname"
LINE 1: fileoriginalname, filestatus, fileip4address, fileip6address...

etc etc

Without the option it works fine:

postgres <at> filesender:~$ pg_dump -Fc filesender -f filesender_backup.pgdump
postgres <at> filesender:~$ createdb -T template0 fstest
postgres <at> filesender:~$ pg_restore -v -d fstest filesender_backup.pgdump
(database restored)

The column-inserts option does work with the default format (i.e. plain SQL):

pg_dump --column-inserts filesender -f filesender_backup.sql
createdb -T template0 fstest
psql fstest < filesender_backup.sql
(database restored)

I guess the -Fc and --column-inserts are mutually exclusive.
Which makes sense because according to the man page, since -Fc yields
a dump that is ONLY suitable for pg_restore, while --colum-inserts is:
"mainly useful for making dumps that can be loaded into non-PostgreSQL
databases".

In any case, it would it be great to raise an error when calling
pg_dump with both options.
Finding out that dumps are unusable at restore time is not very nice 

THanks!!

-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Cannot restore dumps made with -Fc and --column-inserts

As far as I am aware, you're right and they ARE mutally exclusive.

Cheers


-----Original Message-----
From: pgsql-admin-owner <at> postgresql.org [mailto:pgsql-admin-owner <at> postgresql.org] On Behalf Of
Dick Visser
Sent: 04 January 2012 08:26
To: pgsql-admin <at> postgresql.org
Subject: [ADMIN] Cannot restore dumps made with -Fc and --column-inserts

Hi guys

Running pg on Ubuntu 10.04 64bit, which is 8.4.9 today.
When I do a pg_dump using --column-inserts, the subsequent restore fails:

postgres <at> filesender:~$ pg_dump -Fc --column-inserts filesender -f
filesender_backup.pgdump
postgres <at> filesender:~$ createdb -T template0 fstest
postgres <at> filesender:~$ pg_restore -d fstest filesender_backup.pgdump
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1785; 0 16390 TABLE
DATA files fs_user
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax
error at end of input
LINE 6: ...lesubject, filevoucheruid, filemessage, filefrom, filesize,
                                                                       ^
    Command was: INSERT INTO files (fileto, filesubject,
filevoucheruid, filemessage, filefrom, filesize, fileoriginalname,
filestatus, filei...
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax
error at or near "fileoriginalname"
LINE 1: fileoriginalname, filestatus, fileip4address, fileip6address...

etc etc

Without the option it works fine:

postgres <at> filesender:~$ pg_dump -Fc filesender -f filesender_backup.pgdump
postgres <at> filesender:~$ createdb -T template0 fstest
postgres <at> filesender:~$ pg_restore -v -d fstest filesender_backup.pgdump
(database restored)

The column-inserts option does work with the default format (i.e. plain SQL):

pg_dump --column-inserts filesender -f filesender_backup.sql
createdb -T template0 fstest
psql fstest < filesender_backup.sql
(database restored)

I guess the -Fc and --column-inserts are mutually exclusive.
Which makes sense because according to the man page, since -Fc yields
a dump that is ONLY suitable for pg_restore, while --colum-inserts is:
"mainly useful for making dumps that can be loaded into non-PostgreSQL
databases".

In any case, it would it be great to raise an error when calling
pg_dump with both options.
Finding out that dumps are unusable at restore time is not very nice 

THanks!!


-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


___________________________________________________ 

This email is intended for the named recipient. The information contained 
in it is confidential.  You should not copy it for any purposes, nor 
disclose its contents to any other party.  If you received this email 
in error, please notify the sender immediately via email, and delete it from
your computer. 

Any views or opinions presented are solely those of the author and do not 
necessarily represent those of the company. 

PCI Compliancy: Please note, we do not send or wish to receive banking, credit
or debit card information by email or any other form of communication.         

Please try our new on-line ordering system at http://www.cromwell.co.uk/ice

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin