[ADMIN] Owner Issue When Migrating Database to New Server

[Campbell, Lance]

PostgreSQL: 8.2.4

OS: Linux Red Hat 4.x 64 bit

 

I have a database running on serverA with postgres user userA.  I want
to migrate the database to ServerB with a postgres user userB.  Notice
the users are not the same.  I did the following to put the database on
the new server:

 

1)   I created the database on serverB with userB.

2)   I then did pg_dump -h serverA -U userA dbname | psql -h serverB
-U userB dbname

 

This of course failed.  The user userA was not in the database found on
serverB.  I then did the following:

 

1)   I created the database on serverB with userB.

2)   On serverB I did pg_dump -h serverA -U userA dbname >
postgreSQL.out

3)   I then did a find and replace on userA with userB through NANO
on the file postgreSQL.out

4)   I then did psql -h serverB -U userB dbname -f postgreSQL.out

 

Is there a better way to do this? 

 

Thanks,

 

 

Lance Campbell

Project Manager/Software Architect

Web Services at Public Affairs

University of Illinois

217.333.0382

http://webservices.uiuc.edu

 

Re: [ADMIN] Owner Issue When Migrating Database to New Server

[Milen A. Radev]

Campbell, Lance написа:
> PostgreSQL: 8.2.4
> 
> OS: Linux Red Hat 4.x 64 bit
> 
>  
> 
> I have a database running on serverA with postgres user userA.  I want
> to migrate the database to ServerB with a postgres user userB.  Notice
> the users are not the same.  I did the following to put the database on
> the new server:
> 
>  
> 
> 1)   I created the database on serverB with userB.
> 
> 2)   I then did pg_dump -h serverA -U userA dbname | psql -h serverB
> -U userB dbname
> 
>  
> 
> This of course failed.  The user userA was not in the database found on
> serverB.  I then did the following:
> 
>  
> 
> 1)   I created the database on serverB with userB.
> 
> 2)   On serverB I did pg_dump -h serverA -U userA dbname >
> postgreSQL.out
> 
> 3)   I then did a find and replace on userA with userB through NANO
> on the file postgreSQL.out
> 
> 4)   I then did psql -h serverB -U userB dbname -f postgreSQL.out
> 
>  
> 
> Is there a better way to do this? 
> 


Yes - use the "--no-owner" option for "pg_dump" when creating the dump file.

-- 
Milen A. Radev


---(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

[ADMIN] Migration Between Releases

[George Wilk]

Could someone clarify the database dump/restore requirement for postgres
upgrades between major releases?

The online help chapter "23.5. Migration Between Releases" states that:

 

As a general rule, the internal data storage format is subject to change
between major releases of PostgreSQL (where the number after the first dot
changes). This does not apply to different minor releases under the same
major release (where the number after the second dot changes); these always
have compatible storage formats. For example, releases 7.2.1, 7.3.2, and 7.4
are not compatible, whereas 7.2.1 and 7.2.2 are.

 

I thought that the major release was the first number in the versioning
schema, the second represented minor release, and the third would be the
maintenance release or revision number (i.e. 8.2.4).  I need to understand
this better for the sake of writing install scripts for my own Solaris
packages.  Originally, my scripts were checking for the difference in the
major release between the output of "postgres -version" and PG_VERSION file,
looking at the first module of the versioning schema (i.e. 8 in "8.2.4").
Is this still true, or should I be checking the minor release as well?

 

Thanks in advance,

~george

Re: [ADMIN] Migration Between Releases

[Milen A. Radev]

George Wilk написа:
> Could someone clarify the database dump/restore requirement for postgres
> upgrades between major releases?
> 
> The online help chapter "23.5. Migration Between Releases" states that:
> 
>  
> 
> As a general rule, the internal data storage format is subject to change
> between major releases of PostgreSQL (where the number after the first dot
> changes). This does not apply to different minor releases under the same
> major release (where the number after the second dot changes); these always
> have compatible storage formats. For example, releases 7.2.1, 7.3.2, and 7.4
> are not compatible, whereas 7.2.1 and 7.2.2 are.
> 
>  
> 
> I thought that the major release was the first number in the versioning
> schema, the second represented minor release, and the third would be the
> maintenance release or revision number (i.e. 8.2.4).  I need to understand
> this better for the sake of writing install scripts for my own Solaris
> packages.  Originally, my scripts were checking for the difference in the
> major release between the output of "postgres -version" and PG_VERSION file,
> looking at the first module of the versioning schema (i.e. 8 in "8.2.4").
> Is this still true, or should I be checking the minor release as well?

http://www.postgresql.org/support/versioning


-- 
Milen A. Radev


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

Re: [ADMIN] Migration Between Releases

[Peter Eisentraut]

Am Mittwoch, 15. August 2007 16:20 schrieb George Wilk:
> I thought that the major release was the first number in the versioning
> schema, the second represented minor release, and the third would be the
> maintenance release or revision number (i.e. 8.2.4).

You thought wrong then.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

Re: [ADMIN] Migration Between Releases

[George Wilk]

Hi Peter, thanks for your helpful and kind reply.  It certainly clears a lot
of smoke...  In the future you might consider including links to relevant
information.

-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 15, 2007 10:44 AM
To: pgsql-admin@postgresql.org
Cc: George Wilk
Subject: Re: [ADMIN] Migration Between Releases

Am Mittwoch, 15. August 2007 16:20 schrieb George Wilk:
> I thought that the major release was the first number in the versioning
> schema, the second represented minor release, and the third would be the
> maintenance release or revision number (i.e. 8.2.4).

You thought wrong then.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



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

   http://archives.postgresql.org

Re: [ADMIN] Migration Between Releases

[Peter Eisentraut]

Am Mittwoch, 15. August 2007 16:52 schrieb George Wilk:
> Hi Peter, thanks for your helpful and kind reply.  It certainly clears a
> lot of smoke...  In the future you might consider including links to
> relevant information.

You posted the relevant information yourself.  You just need to believe it.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

Re: [ADMIN] Migration Between Releases

[George Wilk]

This must be a matter of personal pride for you Peter, as your personal
website states: "I spend much of my spare time programming, writing
documentation for, and answering mailing list questions about PostgreSQL."
Whereas "answering mailing list questions" might be an understatement :)

I'll let you have the parting shot in this flame thread...
Pleasure was all mine.


Am Mittwoch, 15. August 2007 16:52 schrieb George Wilk:
> Hi Peter, thanks for your helpful and kind reply.  It certainly clears a
> lot of smoke...  In the future you might consider including links to
> relevant information.

You posted the relevant information yourself.  You just need to believe it.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



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

Re: [ADMIN] Migration Between Releases

[Alvaro Herrera]

George Wilk wrote:

> As a general rule, the internal data storage format is subject to change
> between major releases of PostgreSQL (where the number after the first dot
> changes). This does not apply to different minor releases under the same
> major release (where the number after the second dot changes); these always
> have compatible storage formats. For example, releases 7.2.1, 7.3.2, and 7.4
> are not compatible, whereas 7.2.1 and 7.2.2 are.
> 
> I thought that the major release was the first number in the versioning
> schema, the second represented minor release, and the third would be the
> maintenance release or revision number (i.e. 8.2.4).

It needs no clarification -- what it says is right and what you thought
is wrong.  We don't have a concept of "maintenance release" -- we only
have major (new features) and minor (bug fixes).  (This is
Postgres-specific).  Peter wasn't flaming at all.

-- 
Alvaro Herrerahttp://www.advogato.org/person/alvherre
Jason Tesser: You might not have understood me or I am not understanding you.
Paul Thomas: It feels like we're 2 people divided by a common language...

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [ADMIN] [GENERAL] Permission ALTER PASSWORD

[Decibel!]

On Wed, Aug 08, 2007 at 06:35:51PM -0300, Anderson Alves de Albuquerque  wrote:
>  After user $USER execute this ALTER, it get change PASSWORD. Could I block
> command ALTER password to user $USER?

No, there's no way to do that. You might want to look at using
ident-based authentication for that user instead.
-- 
Decibel!, aka Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)


pgpTWu00WwUAH.pgp
Description: PGP signature

Re: [ADMIN] Migration Between Releases

[Scott Marlowe]

On 8/15/07, George Wilk <[EMAIL PROTECTED]> wrote:
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 15, 2007 10:44 AM
> To: pgsql-admin@postgresql.org
> Cc: George Wilk
> Subject: Re: [ADMIN] Migration Between Releases
>
> Am Mittwoch, 15. August 2007 16:20 schrieb George Wilk:
> > I thought that the major release was the first number in the versioning
> > schema, the second represented minor release, and the third would be the
> > maintenance release or revision number (i.e. 8.2.4).
>
> You thought wrong then.
> Hi Peter, thanks for your helpful and kind reply.  It certainly clears a lot
> of smoke...  In the future you might consider including links to relevant
> information.

1: Please don't top post.
2: Peter, if you don't provide links like George is asking for, we're
gonna have to cut what we pay you to post here in half.  :)

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

Re: [ADMIN] Migration Between Releases

[Bruce Momjian]

Scott Marlowe wrote:
> On 8/15/07, George Wilk <[EMAIL PROTECTED]> wrote:
> > From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 15, 2007 10:44 AM
> > To: pgsql-admin@postgresql.org
> > Cc: George Wilk
> > Subject: Re: [ADMIN] Migration Between Releases
> >
> > Am Mittwoch, 15. August 2007 16:20 schrieb George Wilk:
> > > I thought that the major release was the first number in the versioning
> > > schema, the second represented minor release, and the third would be the
> > > maintenance release or revision number (i.e. 8.2.4).
> >
> > You thought wrong then.
> > Hi Peter, thanks for your helpful and kind reply.  It certainly clears a lot
> > of smoke...  In the future you might consider including links to relevant
> > information.
> 
> 1: Please don't top post.
> 2: Peter, if you don't provide links like George is asking for, we're
> gonna have to cut what we pay you to post here in half.  :)

This information used to be in the FAQ, but now it is on our web site
and linked to from the FAQ:

http://www.postgresql.org/support/versioning

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

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

Re: [ADMIN] Configure pg_hba.conf

[Andy Shellam (Mailing Lists)]

Hi Alexander,

Use 0.0.0.0/0.  You can of course add multiple lines to match all your 
ranges (e.g. 192.168.0.0/24, 10.0.0.0/8 etc.)


Regards,

Andy.

Alexander B. wrote:

Hi people,

I would like to configure pg_hba for any IP.
I have several network mask,  some times 192..., or 10, or 190
..., ... ...

How can I configure for any IP?

Thanks
Alexander

---(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

!DSPAM:37,46c33ff9107509519219121!



  



---(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

[ADMIN] Configure pg_hba.conf

[Alexander B.]

Hi people,

I would like to configure pg_hba for any IP.
I have several network mask,  some times 192..., or 10, or 190
..., ... ...

How can I configure for any IP?

Thanks
Alexander

---(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: [ADMIN] Configure pg_hba.conf

[Peter Koczan]

A few notes. postgres looks through pg_hba.conf until it finds the
*first* entry that matches and tries to authenticate and connect using
that method. There's no fallback, so order of entries is important.

If you just want to have any IP connect using one particular
authentication method, put something like this as the last line in
your pg_hba.conf:
hostall all 0.0.0.0   0.0.0.0   md5

Keep in mind that *anyone* from *any computer* can try to connect to
your database server.  (i.e. caveat emptor)

If you want to do something different for other subnets or restrict
access to specific users, you should put those lines in *before* that
so that postgres will see them.

Check here for more details:
http://www.postgresql.org/docs/8.2/interactive/client-authentication.html

Peter

On 8/15/07, Alexander B. <[EMAIL PROTECTED]> wrote:
> Hi people,
>
> I would like to configure pg_hba for any IP.
> I have several network mask,  some times 192..., or 10, or 190
> ..., ... ...
>
> How can I configure for any IP?
>
> Thanks
> Alexander
>
> ---(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
>

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[ADMIN] PG engine takeover or switch over

[Medi Montaseri]

Hi,

I am looking for some suggestions to optimize the following
problem/solution.

Given two nodes A and B (two computers) in a active-passive mode where A is
running PG engine,  and B is simply standing by,  and  a common storage
(twin tailed) ( or from pg_ctl point of view -D /common/data ), I am looking
for a faster solution during the takeover where A has crashed and B is to
start PG engine and run with it.

My current solution is to start PG engine which should take little time to
study the configuration files and /common/data and fork a few childrens. But
I am still interested in optimizing this start-up cost.

For example, would I gain anything by starting PG engine on both A and B,
but on B I point it to /common/dummy and during the takeover, I somehow tell
it to now read from /common/data, for example have two postmaster.conf or
PGDATA and then use  pg_ctl reload.

Thanks
Medi

Re: [ADMIN] unsubcribe

[samngan]

[ADMIN] unsubcribe





---(end of broadcast)---
TIP 1: 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

[ADMIN] Yet Another Socket .s.PGSQL.5432 Problem

[Hilton Perantunes]

Hi folks!

That's another "sob sob.. I can't connect to socket blah blah ..
.s.PGSQL.5432" asking for help. But this is somewhat bizarre, and i'm not
used to the 8.2's postgresql.conf file.

I'm running a PostgreSQL 8.4.2 powered by Debian Sarge (very)Unstable. My
PHP application successfully connects to the appropriated database. Even
PgAdmin3 connects to the database. But my 'postgres' user cannot connect to
the database via command line:

--
psql: could not connect to server:
Is the server running locally and accepting
connections on Unix domain socket
"/var/run/postgresql/.s.PGSQL.5432"?
--

Well, the socket file actually IS there (zero bytes of size) and it's given
the correct permissions. Now, I have this in my pg_hba.conf (replace XXX by
my network, and I just added the second line recently, in despair):

--
# "local" is for Unix domain socket connections only
local   all all   trust
# IPv4 local connections:
hostall all XXX.XXX.XXX.1/24   trust
hostall postgres127.0.0.1/32  trust
# IPv6 local connections:
hostall all ::1/128   trust
--

Finally, that's the hot section in my postgresql.conf:

--
listen_addresses = '*'  # what IP address(es) to listen on;

port = 5432 # (change requires restart)
--

So, I just can't connect in the database through command line. Someone can
waste some time helping me?

Thanks in advance =)

-- 
Hilton William Ganzo Perantunes
Sistemas de Informação - Universidade Federal de Santa Catarina
--
Dinheiro não traz felicidade, mas dá uma sensação tão parecida...  -_-

Re: [ADMIN] Yet Another Socket .s.PGSQL.5432 Problem

[Julio Cesar Sánchez González]

El mié, 15-08-2007 a las 17:13 -0300, Hilton Perantunes escribió:
> Hi folks!
> 
> That's another "sob sob.. I can't connect to socket blah
> blah .. .s.PGSQL.5432" asking for help. But this is somewhat bizarre,
> and i'm not used to the 8.2's postgresql.conf file.
> 
> I'm running a PostgreSQL 8.4.2 powered by Debian Sarge (very)Unstable.
> My PHP application successfully connects to the appropriated database.
> Even PgAdmin3 connects to the database. But my 'postgres' user cannot
> connect to the database via command line: 
> 
> --
> psql: could not connect to server:
> Is the server running locally and accepting
> connections on Unix domain socket
> "/var/run/postgresql/.s.PGSQL.5432"?
> --
> 
> Well, the socket file actually IS there (zero bytes of size) and it's
> given the correct permissions. Now, I have this in my pg_hba.conf
> (replace XXX by my network, and I just added the second line recently,
> in despair): 
> 

Try stoping the postgresql process and delete the socket unix file,
restart the postgresql daemon and we to mean.

> --
> # "local" is for Unix domain socket connections only
> local   all all   trust
> # IPv4 local connections:
> hostall all XXX.XXX.XXX.1 /24   trust
> hostall postgres127.0.0.1/32  trust
> # IPv6 local connections:
> hostall all ::1/128   trust
> --
> 
> Finally, that's the hot section in my postgresql.conf:
> 
> --
> listen_addresses = '*'  # what IP address(es) to
> listen on;  
> port = 5432 # (change requires restart) 
> --
> 
> So, I just can't connect in the database through command line. Someone
> can waste some time helping me?
> 
> Thanks in advance =)
> 
> -- 
> Hilton William Ganzo Perantunes
> Sistemas de Informação - Universidade Federal de Santa Catarina 
> --
> Dinheiro não traz felicidade, mas dá uma sensação tão parecida...  -_-



-- 
Regards,

Julio Cesar Sánchez González
www.sistemasyconectividad.com.mx
blog: http://darkavngr.blogspot.com

---
Ahora me he convertido en la muerte, destructora de mundos.
Soy la Muerte que se lleva todo, la fuente de las cosas que vendran.


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

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

Re: [ADMIN] Yet Another Socket .s.PGSQL.5432 Problem

[Hilton Perantunes]

Thanks for answering, Julio.

When I stop the database, the socket file is automatically removed. That's
the way it happened before... but now, oddly enough, I restarted the
database at will several times, my app is still running, pgadmin too... and
no socket file is created. o.0

(and I still can't connect via bash)

Hilton



On 8/15/07, Julio Cesar Sánchez González <
[EMAIL PROTECTED]> wrote:
>
> El mié, 15-08-2007 a las 17:13 -0300, Hilton Perantunes escribió:
> > Hi folks!
> >
> > That's another "sob sob.. I can't connect to socket blah
> > blah .. .s.PGSQL.5432" asking for help. But this is somewhat bizarre,
> > and i'm not used to the 8.2's postgresql.conf file.
> >
> > I'm running a PostgreSQL 8.4.2 powered by Debian Sarge (very)Unstable.
> > My PHP application successfully connects to the appropriated database.
> > Even PgAdmin3 connects to the database. But my 'postgres' user cannot
> > connect to the database via command line:
> >
> > --
> > psql: could not connect to server:
> > Is the server running locally and accepting
> > connections on Unix domain socket
> > "/var/run/postgresql/.s.PGSQL.5432"?
> > --
> >
> > Well, the socket file actually IS there (zero bytes of size) and it's
> > given the correct permissions. Now, I have this in my pg_hba.conf
> > (replace XXX by my network, and I just added the second line recently,
> > in despair):
> >
>
> Try stoping the postgresql process and delete the socket unix file,
> restart the postgresql daemon and we to mean.
>
> > --
> > # "local" is for Unix domain socket connections only
> > local   all all   trust
> > # IPv4 local connections:
> > hostall all XXX.XXX.XXX.1 /24   trust
> > hostall postgres127.0.0.1/32  trust
> > # IPv6 local connections:
> > hostall all ::1/128   trust
> > --
> >
> > Finally, that's the hot section in my postgresql.conf:
> >
> > --
> > listen_addresses = '*'  # what IP address(es) to
> > listen on;
> > port = 5432 # (change requires restart)
> > --
> >
> > So, I just can't connect in the database through command line. Someone
> > can waste some time helping me?
> >
> > Thanks in advance =)
> >
> > --
> > Hilton William Ganzo Perantunes
> > Sistemas de Informação - Universidade Federal de Santa Catarina
> > --
> > Dinheiro não traz felicidade, mas dá uma sensação tão parecida...  -_-
>
>
>
> --
> Regards,
>
> Julio Cesar Sánchez González
> www.sistemasyconectividad.com.mx
> blog: http://darkavngr.blogspot.com
>
> ---
> Ahora me he convertido en la muerte, destructora de mundos.
> Soy la Muerte que se lleva todo, la fuente de las cosas que vendran.
>
>


-- 
Hilton William Ganzo Perantunes
Sistemas de Informação - Universidade Federal de Santa Catarina
--
Dinheiro não traz felicidade, mas dá uma sensação tão parecida...  -_-

Re: [ADMIN] Yet Another Socket .s.PGSQL.5432 Problem

[Tom Lane]

"Hilton Perantunes" <[EMAIL PROTECTED]> writes:
> When I stop the database, the socket file is automatically removed. That's
> the way it happened before... but now, oddly enough, I restarted the
> database at will several times, my app is still running, pgadmin too... and
> no socket file is created. o.0

Are you sure that's where the database thinks the socket file should be?
/var/run/postgresql is *not* the factory default for this; /tmp is.
If you replaced a distro build with your own or vice versa you may be
confused by that.

Wrong permissions on the directory or its parents could be the
problem, too.

> psql: could not connect to server:
> Is the server running locally and accepting
> connections on Unix domain socket
> "/var/run/postgresql/.s.PGSQL.5432"?

This clip omits the most important part of the message: there should be
a kernel error code after the colon.

regards, tom lane

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

Re: [ADMIN] Configure pg_hba.conf

[Julio Cesar Sánchez González]

El mié, 15-08-2007 a las 13:39 -0500, Peter Koczan escribió:
> A few notes. postgres looks through pg_hba.conf until it finds the
> *first* entry that matches and tries to authenticate and connect using
> that method. There's no fallback, so order of entries is important.
> 
> If you just want to have any IP connect using one particular
> authentication method, put something like this as the last line in
> your pg_hba.conf:
> hostall all 0.0.0.0   0.0.0.0   md5
> 
> Keep in mind that *anyone* from *any computer* can try to connect to
> your database server.  (i.e. caveat emptor)
> 
> If you want to do something different for other subnets or restrict
> access to specific users, you should put those lines in *before* that
> so that postgres will see them.
> 
> Check here for more details:
> http://www.postgresql.org/docs/8.2/interactive/client-authentication.html
> 
> Peter
> 
> On 8/15/07, Alexander B. <[EMAIL PROTECTED]> wrote:
> > Hi people,
> >
> > I would like to configure pg_hba for any IP.
> > I have several network mask,  some times 192..., or 10, or 190
> > ..., ... ...
> >
> > How can I configure for any IP?

In the pg_hba.conf add some similar to:

hostall all 192.168.1.0/24trust

with the respective cidr address would you like to do.

> >
> > Thanks
> > Alexander
> >
> > ---(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
> >
> 
> ---(end of broadcast)---
> TIP 7: You can help support the PostgreSQL project by donating at
> 
> http://www.postgresql.org/about/donate

-- 
Regards,

Julio Cesar Sánchez González
www.sistemasyconectividad.com.mx
blog: http://darkavngr.blogspot.com

---
Ahora me he convertido en la muerte, destructora de mundos.
Soy la Muerte que se lleva todo, la fuente de las cosas que vendran.


---(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: [ADMIN] PgAgent..

[Jayakumar_Mukundaraju]

Hi,
 
If i start the service in service panel the following error is occurs.
 
  Could not start the PostgreSQL Scheduling Agent - pgAgent service on 
Local Computer.
  Error 1053: The service did not respond to the start or control request 
in a timely fashion.
 
Kindly give me solution...
 
Thanks & Regards
Jayakumar M
 



From: Vishal Arora [mailto:[EMAIL PROTECTED]
Sent: Tue 8/14/2007 11:24 PM
To: Jayakumar_Mukundaraju; pgsql-admin@postgresql.org; [EMAIL PROTECTED]
Subject: RE: [ADMIN] PgAgent..


Hi Jay
 
This is the pgADMIN query so you should ask it in that list /
you should try to restart the service in the service panel 







Subject: [ADMIN] PgAgent..
Date: Tue, 14 Aug 2007 16:44:28 +0530
From: [EMAIL PROTECTED]
To: pgsql-admin@postgresql.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]


Dear All
 
If i am trying to start my pgAgent, the following error is occurs... 
 
C:\Program Files\PostgreSQL\8.2\bin>net start pgAgent
The service is not responding to the control function.
More help is available by typing NET HELPMSG 2186.

If any body gone through this errors, kindly give me the solution for 
this. 

DISCLAIMER:
This email (including any attachments) is intended for the sole use of 
the intended recipient/s and may contain material that is CONFIDENTIAL AND 
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated..





Recharge--play some free games. Win cool prizes too! Play It! 
  


DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.