Le jeudi 23 avril 2009 à 14:48:29, jan-peter.seif...@gmx.de a écrit :
> Hello,
>
> Guillaume Lelarge wrote:
> > > However, when I view the properties of the new template1 in pgAdmin III
> >
> > it
> >
> > > isn't stated that it's a system database anymore. Is it because that
> > > the OID is differ
Hello,
Guillaume Lelarge wrote:
> > However, when I view the properties of the new template1 in pgAdmin III
> it
> > isn't stated that it's a system database anymore. Is it because that the
> > OID is different from 1 or is there a hidden flag? In pg_database I
> don't
> > see any significant di
Le jeudi 23 avril 2009 à 12:54:12, Tore Halvorsen a écrit :
> [...]
> Is there any way to display the slony cluster schema?
>
> Ie, the schema _clustername in the treeview - this is visible in
> version 1.8.4 but not in 1.10.
>
The slony schema should be available in the catalogs node.
--
Guill
Le jeudi 23 avril 2009 à 12:29:33, Jan-Peter Seifert a écrit :
> [...]
> in order to get a clean template1 I dropped and recreated it:
>
> UPDATE pg_database SET datistemplate = false WHERE datname = 'template1';
>
> DROPDB -U postgres template1
>
> CREATEDB -U postgres -T template0 template1
>
> U
There are tcp_keepalives on the server side of postgresql
The problem was that debian waits 2 hours before starting the keepalives
(7200 s).
Also, the connection would only be kept alive for 9*75 s, which is 11 min.
So i changed the tcp_keepalives_idle to 120 (keepalives start after 2 min)
and th
Hi,
Is there any way to display the slony cluster schema?
Ie, the schema _clustername in the treeview - this is visible in
version 1.8.4 but not in 1.10.
--
Eld på åren og sol på eng gjer mannen fegen og fjåg. [Jøtul]
2009 Tore Halvorsen || +052 0553034554
--
Sent via pgadmin-support mailing
Hi,
Is there any way to display the slony cluster schema?
Ie, the schema _clustername in the treeview - this is visible in
version 1.8.4 but not in 1.10.
--
Eld på åren og sol på eng gjer mannen fegen og fjåg. [Jøtul]
2009 Tore Halvorsen || +052 0553034554
--
Sent via pgadmin-support mailing
Hello,
in order to get a clean template1 I dropped and recreated it:
UPDATE pg_database SET datistemplate = false WHERE datname = 'template1';
DROPDB -U postgres template1
CREATEDB -U postgres -T template0 template1
UPDATE pg_database SET datistemplate = true WHERE datname = 'template1';
GRANT
I looked at this problem once again with a colleage and came to the
conclusion that the firewall is timing out the connection.
Some other client software packages, like SSH for example, have a mechanism
to manage this problem:
"NAT firewalls like to time out idle sessions to keep their state tabl
