[GENERAL] Transactions across multiples databases

[Sergio Pili]

Hello:

I need to modify diferent tables in multiples databases in one transaction.
Can i do it whitout lost integrity in all databases if "rollback" is
executed?

Thanks,

Sergio Pili

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [GENERAL] Upgrading to 7.3.4?

[scott.marlowe]

On Thu, 31 Jul 2003, Paul Ramsey wrote:

> Voot! Not necessary! :)
> This is a minor version upgrade, so data can remain in place. For a 7.2 
> -> 7.3 upgrade you would have to dump-and-restore.
> My upgrade procedure is:
> tar xvfz postgresql-7.3.4.tar.gz ; cd postgresql-7.3.4
> ./configure ; make ; make install
> pg_ctl stop ; pg_ctl start

Actuall, it's a really good idea to do:

make
pg_ctl stop
make install
pg_ctl start

I.e. you shouldn't have a service that's running when you do a 'make 
install'.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [GENERAL] OSCON "paper"

[Richard Huxton]

On Thursday 31 July 2003 17:40, Andrew Sullivan wrote:
> Hi,
>
> I had a couple of requests for copies of my presentation at OSCON.  I
> don't really know that it's of any value to anyone, but if you'd
> like to see a cleaned-up (i.e. you can read it) version of my notes
> for that presentation, it's available at
> .

Interesting read. Thanks Andrew.

-- 
  Richard Huxton
  Archonet Ltd

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

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [GENERAL] surppressing column names in COPY format

[Tom Lane]

Robert Treat <[EMAIL PROTECTED]> writes:
> the problem is that I am restoring the data to a database with different
> column names, which errors out in 7.3 (but didn't under 7.2 since it
> didn't produce column names in the COPY output). I checked the docs and
> it provided no clue as to how to suppress column names for COPY only
> dumps.

I think you can still get it to dump as INSERTs without column names.

I don't really agree that we've "lost functionality" here, though ---
you might as well claim that it's a bug that the COPY command forces
you to restore the data into a particular table.  If you need to do
data transformation (which includes relabeling columns IMHO), restore
the data into a temp table and then do INSERT ... SELECT ... to massage
it into what you want.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [GENERAL] Upgrading to 7.3.4?

[Bjørn T Johansen]

Thanks for all your suggestions, I will be trying this... :)


BTJ

On Thu, 2003-07-31 at 20:27, scott.marlowe wrote:
> On Thu, 31 Jul 2003, Paul Ramsey wrote:
> 
> > Voot! Not necessary! :)
> > This is a minor version upgrade, so data can remain in place. For a 7.2 
> > -> 7.3 upgrade you would have to dump-and-restore.
> > My upgrade procedure is:
> > tar xvfz postgresql-7.3.4.tar.gz ; cd postgresql-7.3.4
> > ./configure ; make ; make install
> > pg_ctl stop ; pg_ctl start
> 
> Actuall, it's a really good idea to do:
> 
> make
> pg_ctl stop
> make install
> pg_ctl start
> 
> I.e. you shouldn't have a service that's running when you do a 'make 
> install'.



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

[GENERAL] surppressing column names in COPY format

[Robert Treat]

in 7.2 doing a data only dump (pg_dump -a -x db > dump) would give
output like:

UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" = 'status';

COPY "status" FROM stdin;
0   INFO
1   WARNING
2   CRIT
\. 
-- Enable triggers
UPDATE pg_class SET reltriggers = (SELECT count(*) FROM pg_trigger where
pg_class.oid = tgrelid) WHERE relname = 'status';



however in 7.3, doing the equivalent (pg_dump -a --disable-triggers db >
dump) i get the following output. 

UPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid =
'status'::pg_catalog.regclass;

COPY status (status_id, description) FROM stdin;
0   INFO 
1   WARNING
2   CRIT 
\.

-- Enable triggers
UPDATE pg_catalog.pg_class SET reltriggers = (SELECT pg_catalog.count(*)
FROM pg_catalog.pg_trigger where pg_class.oid = tgrelid) WHERE oid =
'status'::pg_catalog.regclass;


the problem is that I am restoring the data to a database with different
column names, which errors out in 7.3 (but didn't under 7.2 since it
didn't produce column names in the COPY output). I checked the docs and
it provided no clue as to how to suppress column names for COPY only
dumps. I also checked the message archives, but the only thing relevant
seemed to be the original patch which didn't appear to allow for a way
to suppress the column names, am I completely missing something here or
did we lose this functionality?

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


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

Re: [GENERAL] Upgrading to 7.3.4?

[Paul Ramsey]

Voot! Not necessary! :)
This is a minor version upgrade, so data can remain in place. For a 7.2 
-> 7.3 upgrade you would have to dump-and-restore.
My upgrade procedure is:
tar xvfz postgresql-7.3.4.tar.gz ; cd postgresql-7.3.4
./configure ; make ; make install
pg_ctl stop ; pg_ctl start

Freddy Menjívar M. wrote:
- Original Message -
From: "Bjørn T Johansen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 30, 2003 3:53 PM
Subject: [GENERAL] Upgrading to 7.3.4?
 > If I upgrade from 7.3.3 to 7.3.4, is it enough to just copy the data
 > directory from 7.3.3 to 7.3.4 to "restore" my databases?
 > Regards
 
Try something like this
==
 
pgdumpall > dbbackup  -- backup and stop
pg_ctl stop
mv %PGHOME% /usr/local/pgsql.old  -- move old pgsql program

cd /usr/local/src/postgresql-7.3.2-- installs new pgsql version
make install
initdb -D %PGHOME%/data   -- start and restore db.
pg_ctl start
psql < dbackup
 


--
  __
 /
 | Paul Ramsey
 | Refractions Research
 | Email: [EMAIL PROTECTED]
 | Phone: (250) 885-0632
 \_
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [GENERAL] Postgres Hanging on Inserts

[Adam Kavan]

> Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
> > On Wed, Jul 30, 2003 at 01:03:55PM -0500, Adam Kavan wrote:
> >> I have found the problem (I think) below is the list of all the locks
> >> pending on the relation.  The relation is a hash index on the table
that is
> >> being INSERT'd rapidly.  From what I can see pid 10024 and 10025 both
have
> >> an ExclusiveLock on the index, and they both are waiting to get an
> >> ExclusiveLock on the relation.
>
> > Oh, so this is the problem.  Truth is hash indexes in Postgres are known
to
> > have poor concurrency, though I didn't expect them to be subject to
> > deadlocks...
>
> They are known to have internal deadlock problems too.  I believe what
> Adam has shown us is an internal deadlock in the index.  The locks that
> are being taken are actually page-level locks, but the pg_locks view
> doesn't show the page numbers.
>
> I had thought that such things would trigger a "deadlock detected" error
> though --- curious that it seems not to.
>
> > you should change the hash index to a btree index
>
> Agreed.  Hash indexes would probably have gotten fixed by now if anyone
> could see a reason to expend effort on them, but they seem to be mostly
> an academic exercise.
>
> regards, tom lane

I can happily report that my system has gone through the night without any
problems.  Thanks a lot for helping me.

--- Adam Kavan
--- [EMAIL PROTECTED]


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

   http://www.postgresql.org/docs/faqs/FAQ.html

[GENERAL] OSCON "paper"

[Andrew Sullivan]

Hi,

I had a couple of requests for copies of my presentation at OSCON.  I
don't really know that it's of any value to anyone, but if you'd
like to see a cleaned-up (i.e. you can read it) version of my notes
for that presentation, it's available at
.

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Liberty RMS   Toronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
 +1 416 646 3304 x110


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

   http://archives.postgresql.org

Re: [GENERAL] PostgreSQL Question

[Patrick Welche]

On Thu, Jul 31, 2003 at 11:52:42AM +0800, Ryan F. Bayhonan wrote:
> Hi Patrick,
> 
> Have read your reply in the web about postgreSQL.
> (http://archives.postgresql.org/pgsql-interfaces/2001-01/msg00170.php)
> 
> My name is Ryan, and I would like to ask some help about PostgreSQL.
> 
> I have the relations below:
> 
> TABLE_CLIENT:
> CID   |   CLIENT_NAME 
> --+--
>   1   |   RFB CO.
>   2   |   ABC CO.
> 
> TABLE_PROJECTS:
> PID   |   PROJECT_NAME   |   STATUS   |  PID
> --+--++---
>   1   |   PROJECT_A  |   ACTIVE   |   1
>   2   |   PROJECT_B  |   ACTIVE   |   1
>   3   |   PROJECT_C  |   CLOSED   |   1
>   4   |   PROJECT_D  |   CLOSED   |   1
>   5   |   PROJECT_E  |   ACTIVE   |   2
>   6   |   PROJECT_F  |   ACTIVE   |   2
> 
> I want to list all the CLIENT and know how many projects ACTIVE
> and how many are CLOSED. I want to have a result shown below:
> 
> CID   |   CLIENT_NAME   |   ACTIVE   |   CLOSED   
> --+-++
>   1   |   RFB CO.   |  2 |  2
>   2   |   ABC CO.   |  2 |  0
> 
> 
> What would be the correct SQL syntax for the above result?

I have no idea if this is "correct", just that it seems to work.
By the way, you are much better off posting to pgsql-sql or
pgsql-general @ postgresql.org...

Cheers,

Patrick

begin;
create table client (
id  serial primary key,
"name"  text
);

create table status (
id  serial primary key,
"name"  text
);

create table projects (
id  serial primary key,
"name"  text,
status  integer references status,
cid integer references client
);

insert into client ("name") values ('RFB CO.');
insert into client ("name") values ('ABC CO.');

insert into status ("name") values ('ACTIVE');
insert into status ("name") values ('CLOSED');

insert into projects ("name",status,cid) values ('PROJECT_A',1,1);
insert into projects ("name",status,cid) values ('PROJECT_B',1,1);
insert into projects ("name",status,cid) values ('PROJECT_C',2,1);
insert into projects ("name",status,cid) values ('PROJECT_D',2,1);
insert into projects ("name",status,cid) values ('PROJECT_E',1,2);
insert into projects ("name",status,cid) values ('PROJECT_F',1,2);
commit;

select * from client order by id;

select p.id,p.name,s.name,p.cid
  from projects as p,status as s
 where p.status=s.id
 order by id
;

select c.id,c.name,
  coalesce(
(select count(*)
   from projects as p
  where p.cid=c.id
and p.status=1
  group by c.id,c.name
),0) as active,
  coalesce(
(select count(*)
   from projects as p
  where p.cid=c.id
and p.status=2
  group by c.id,c.name
),0) as closed
 from client as c
 order by id
;


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

Re: [GENERAL] Updating from update trigger

[Csaba Nagy]

Answering my own half-way thought solution: of course you won't avoid
the infinite loop if you take the location info in a separate table,
cause if you do, then you can't update the location by just updating the
cd table.
So having this solution invalid, I just can think of using some query
rewriting rules.
I have absolutely no experience with this, so check out the docs:
http://www.postgresql.org/docs/7.3/static/rules.html

HTH,
Csaba.

On Thu, 2003-07-31 at 14:26, Csaba Nagy wrote:
> You should probably rethink the application logic. 
> If there's no way to do it differently, you might be able to place the
> location details in a separate table, and update them there - this way
> on update of the "cd" table you will update also the "cd_locations"
> table, avoiding the loop.
> You should join the 2 tables using a sequence generated key, which
> should be never changed once allocated to a cd/location pair.
> 
> In any case this trigger approach will not work correctly in multi-user
> environments, unless you implement some kind of locking for the
> insert/update access to the cd table. In the best case you will get
> rolled back transactions, worst case - the locations get f**ed up.
> 
> HTH,
> Csaba.
> 
> On Thu, 2003-07-31 at 12:46, Jonathan Mezach wrote:
> > Is there anyone who has a solution to this problem?
> > 
> > Greetings,
> > 
> > Jonathan Mezach aka Taz
> > News Writer for HL2Zone (www.hl2zone.net)
> > 
> > 
> > -Oorspronkelijk bericht-
> > Van: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Namens Jonathan Mezach
> > Verzonden: vrijdag 25 juli 2003 21:07
> > Aan: [EMAIL PROTECTED]
> > Onderwerp: [GENERAL] Updating from update trigger
> > 
> > Hello,
> > 
> > I'm writing a program with which I can keep track of all the CD's I
> > have. As a backend, I'm using Postgres to store my data. Now, I have
> > this trigger on a table (a scheme of the database at the bottom) which
> > executes a function called movecdsdown. From this function, the same
> > table is updated. This gives no problems when the trigger is called
> > because of an insert, and it does what it should do. However, I also
> > want to update the table when that table is updated. This of course
> > gives me problems, cause it will begin an endless loop. So, somehow I
> > need to disable the trigger, or the function must now if the function
> > was already called, but I have no idea on how to do this.
> > 
> > Here is a scheme of the database I'm using:
> > 
> > cd  locationlocationdetails rental
> > renter
> > 
> > title (pk)  location (pk)   fk_cd (pk)
> > startdate (pk)  firstname (pk)
> > creationdatewidth   fk_location (pk)
> > followupnr (pk) lastname (pk)
> > typeheight  partfk_cd
> > phonenumber
> > fk_storedlocparts   column  fk_firstname
> > email
> > fk_currentloc   fitshalfsizerow fk_lastname
> > sizestack
> > enddate
> > homelocation
> > 
> > I think the foreign and primary keys speak for themselves. The trigger
> > is defined on the locationdetails table. The trigger function then
> > updates the row field of all rows where row > NEW.row. It works
> > perfectly for INSERT, but it doesn't work for UPDATE.
> > 
> > Greetings,
> > 
> > Jonathan Mezach
> > 
> > 
> > 
> > 
> > ---(end of broadcast)---
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> >   subscribe-nomail command to [EMAIL PROTECTED] so that your
> >   message can get through to the mailing list cleanly
> > 
> > 
> > 
> > ---(end of broadcast)---
> > TIP 8: explain analyze is your friend
> > 
> 



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

   http://archives.postgresql.org

Re: [GENERAL] Updating from update trigger

[Csaba Nagy]

You should probably rethink the application logic. 
If there's no way to do it differently, you might be able to place the
location details in a separate table, and update them there - this way
on update of the "cd" table you will update also the "cd_locations"
table, avoiding the loop.
You should join the 2 tables using a sequence generated key, which
should be never changed once allocated to a cd/location pair.

In any case this trigger approach will not work correctly in multi-user
environments, unless you implement some kind of locking for the
insert/update access to the cd table. In the best case you will get
rolled back transactions, worst case - the locations get f**ed up.

HTH,
Csaba.

On Thu, 2003-07-31 at 12:46, Jonathan Mezach wrote:
> Is there anyone who has a solution to this problem?
> 
> Greetings,
> 
> Jonathan Mezach aka Taz
> News Writer for HL2Zone (www.hl2zone.net)
> 
> 
> -Oorspronkelijk bericht-
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Namens Jonathan Mezach
> Verzonden: vrijdag 25 juli 2003 21:07
> Aan: [EMAIL PROTECTED]
> Onderwerp: [GENERAL] Updating from update trigger
> 
> Hello,
> 
> I'm writing a program with which I can keep track of all the CD's I
> have. As a backend, I'm using Postgres to store my data. Now, I have
> this trigger on a table (a scheme of the database at the bottom) which
> executes a function called movecdsdown. From this function, the same
> table is updated. This gives no problems when the trigger is called
> because of an insert, and it does what it should do. However, I also
> want to update the table when that table is updated. This of course
> gives me problems, cause it will begin an endless loop. So, somehow I
> need to disable the trigger, or the function must now if the function
> was already called, but I have no idea on how to do this.
> 
> Here is a scheme of the database I'm using:
> 
> cdlocationlocationdetails rental
> renter
> 
> title (pk)location (pk)   fk_cd (pk)
> startdate (pk)firstname (pk)
> creationdate  width   fk_location (pk)
> followupnr (pk)   lastname (pk)
> type  height  partfk_cd
> phonenumber
> fk_storedloc  parts   column  fk_firstname
> email
> fk_currentloc fitshalfsizerow fk_lastname
> size  stack
> enddate
>   homelocation
> 
> I think the foreign and primary keys speak for themselves. The trigger
> is defined on the locationdetails table. The trigger function then
> updates the row field of all rows where row > NEW.row. It works
> perfectly for INSERT, but it doesn't work for UPDATE.
> 
> Greetings,
> 
> Jonathan Mezach
> 
> 
> 
> 
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly
> 
> 
> 
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
> 



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

Re: [GENERAL] Updating from update trigger

[Jonathan Mezach]

Is there anyone who has a solution to this problem?

Greetings,

Jonathan Mezach aka Taz
News Writer for HL2Zone (www.hl2zone.net)


-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Jonathan Mezach
Verzonden: vrijdag 25 juli 2003 21:07
Aan: [EMAIL PROTECTED]
Onderwerp: [GENERAL] Updating from update trigger

Hello,

I'm writing a program with which I can keep track of all the CD's I
have. As a backend, I'm using Postgres to store my data. Now, I have
this trigger on a table (a scheme of the database at the bottom) which
executes a function called movecdsdown. From this function, the same
table is updated. This gives no problems when the trigger is called
because of an insert, and it does what it should do. However, I also
want to update the table when that table is updated. This of course
gives me problems, cause it will begin an endless loop. So, somehow I
need to disable the trigger, or the function must now if the function
was already called, but I have no idea on how to do this.

Here is a scheme of the database I'm using:

cd  locationlocationdetails rental
renter

title (pk)  location (pk)   fk_cd (pk)
startdate (pk)  firstname (pk)
creationdatewidth   fk_location (pk)
followupnr (pk) lastname (pk)
typeheight  partfk_cd
phonenumber
fk_storedlocparts   column  fk_firstname
email
fk_currentloc   fitshalfsizerow fk_lastname
sizestack
enddate
homelocation

I think the foreign and primary keys speak for themselves. The trigger
is defined on the locationdetails table. The trigger function then
updates the row field of all rows where row > NEW.row. It works
perfectly for INSERT, but it doesn't work for UPDATE.

Greetings,

Jonathan Mezach




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly



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

Re: [GENERAL] CREATE TABLE with a column of type {table name}

[Stephan Szabo]

On Thu, 31 Jul 2003, Ang Chin Han wrote:

> In Postgresql 7.3, a datatype can be int, text, etc, and also
> pseudo-types like RECORD, any, etc.
>
> These pseudo types are mainly used in CREATE FUNCTIONs, but what if it's
> used in a CREATE TABLE, esp. when the name of another table is used as a
> datatype?
[...]
>
> -- Hmmm... What if pseudo-types in CREATE TABLEs?
> -- *** THIS IS THE WHAT I'M INTERESTED IN ***
> CREATE TABLE bar(myfoo foo, c int);
>
> -- The only way I can think of to insert values into the table bar:
> SELECT INTO bar SELECT get_foo1(), 1;

You can write casts as well presumably to allow other inputs.

> -- How to retrieve data from bar?
> SELECT * FROM bar;
> ERROR:  Cannot display a value of type RECORD
>
> SELECT myfoo.a FROM bar;
> ERROR:  Attribute "myfoo.a" not found

However the syntax
 select a(myfoo),b(myfoo) from bar
should work.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[GENERAL] CREATE TABLE with a column of type {table name}

[Ang Chin Han]

In Postgresql 7.3, a datatype can be int, text, etc, and also 
pseudo-types like RECORD, any, etc.

These pseudo types are mainly used in CREATE FUNCTIONs, but what if it's 
used in a CREATE TABLE, esp. when the name of another table is used as a 
datatype?

e.g.

-- Just for illustration:
CREATE TABLE foo(a int, b int);
INSERT INTO foo VALUES (1, 2);
INSERT INTO foo VALUES (2, 3);
-- Main uses of pseudo-types
CREATE FUNCTION get_foo1() RETURNS foo
  LANGUAGE SQL AS
  'SELECT * FROM foo WHERE a = 1';
-- Cool uses:
SELECT b FROM get_foo1();
Output:
 b
---
 2
(1 row)
-- Hmmm... What if pseudo-types in CREATE TABLEs?
-- *** THIS IS THE WHAT I'M INTERESTED IN ***
CREATE TABLE bar(myfoo foo, c int);
-- The only way I can think of to insert values into the table bar:
SELECT INTO bar SELECT get_foo1(), 1;
-- How to retrieve data from bar?
SELECT * FROM bar;
ERROR:  Cannot display a value of type RECORD
SELECT myfoo.a FROM bar;
ERROR:  Attribute "myfoo.a" not found
Should the CREATE TABLE bar(...) return an error in the first place? How 
do we retrieve or somehow make use of bar once we get data into it? 
Purely academical question at the moment, but might be an interesting 
feature to explore esp. for perspective of OOP.

pg_dump (7.3.2) returns an error when trying to dump this table.

--
Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 
GNU/Linux
  6:00pm  up 217 days,  9:05,  5 users,  load average: 5.26, 5.10, 5.03


pgp0.pgp
Description: PGP signature

Re: [GENERAL] Don't removes/recycles WAL files at all

[Michael Govorun]

Tom Lane <[EMAIL PROTECTED]> writes:

> Yeah, adding or removing -malign-double would change the layout of our
> on-disk data structures, so it's no surprise you'd need to dump and
> reload for that.
>
> Also, -ffast-math is known to be Evil.  I thought we had a check to
> prevent that (looks ...) yeah we do; how'd you get by this check in
> timestamp.c?
>
> /*
>  * gcc's -ffast-math switch breaks routines that expect exact results from
>  * expressions like timeval / 3600, where timeval is double.
>  */
> #ifdef __FAST_MATH__
> #error -ffast-math is known to break this code
> #endif

Thanks for info, but I did not see this error.

> As for the other stuff, it theoretically should work, but isn't
>egcs-2.91.66 rather old and buggy?  Perhaps a newer gcc would work
>better.

Yes, it's old redhat 6.2 and whole system for a long time needs
upgrade.

-- 
Michael Govorun

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

Re: [GENERAL] Port?

[Jean-Christian Imbeault]

b b wrote:
(B>
(B>  What port does the postgresql server listen on. 
(B
(BIt listens on whichever port you tell it to :) 5432 by default I think.
(B
(B>  How do we know the port postgresql is listening on?
(B
(BMake sure that tcp connections are enabled in the conf file. TCP
(Bconnection are *not* enabled by default.
(B
(BJean-Christian Imbeault
(B
(B
(B---(end of broadcast)---
(BTIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]