Hi,
I have a number of PostgreSQL servers which I often access through ssh
tunnel with Pgadmin3. I would like to double check which one I have landed
on (if the tunnel is really configured the way I want). Is there a way to
query the hostname from the catalogs?
Thanks
Peter
On Fri, Apr 30, 2010 at 03:33:13PM +0200, Péter Kovács wrote:
> Hi,
>
> I have a number of PostgreSQL servers which I often access through ssh
> tunnel with Pgadmin3. I would like to double check which one I have landed
> on (if the tunnel is really configured the way I want). Is there a way to
>
"Ross J. Reedstrom" wrote:
> If you're talking unix/linux machines, then /etc/hostname _should_
> have the current hostname in it
If not, check for /etc/HOSTNAME -- some distributions do that.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your
Thank you, Ross!
inet_server_addr() returns the correct IP address in this case. I am not
sure why... The tunnel goes through at least one port-forwarding node, but I
am not sure this makes postgresql see the connection any less local.
Thanks
Peter
On Fri, Apr 30, 2010 at 4:14 PM, Ross J. Reedst
--- On Fri, 30/4/10, Ross J. Reedstrom wrote:
> > Hi,
> >
> > I have a number of PostgreSQL servers which I often
> access through ssh
> > tunnel with Pgadmin3. I would like to double check
> which one I have landed
> > on (if the tunnel is really configured the way I
> want). Is there a way to
Yes, nice and simple.
I just did this in C and it works ok!
hostname.c
===
#include
#include "postgres.h"
#include "utils/elog.h"
#include "utils/palloc.h"
#include "storage/bufpage.h"
#define MAX_HOST_SIZE 200
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(host
Gavin Kistner writes:
> On Apr 29, 2010, at 11:42 PM, Tom Lane wrote:
>> For comparison, I have these settings on my laptop:
>> pro:~ tgl$ cat /etc/sysctl.conf
>> kern.sysv.shmmax=33554432
>> kern.sysv.shmmin=1
>> kern.sysv.shmmni=32
>> kern.sysv.shmseg=8
>> kern.sysv.shmall=8192
>>
>> and PG st
Hi folks,
I'm doing regular (hourly) dumps and putting them into git
(and automatically pushing it to several git servers).
The problem is: the dumps are always differing (even if nothing
happened in that db).
diff --git a/DB-net79.sql b/DB-net79.sql
index 89b682d..c8be6d6 100644
HI,
I have a vacuum process that has been running on a table for the past 20 days.
The server is postgres 8.3 on ubuntu linux.
Can I safely kill the vacuum with:
select pg_cancel_backend(26433)
Some stats
The table sees ~5million and not more than ~10million updates month
$ ps aux | gre
Jason Culverhouse writes:
> I have a vacuum process that has been running on a table for the past 20 days.
> The server is postgres 8.3 on ubuntu linux.
> Can I safely kill the vacuum with:
> select pg_cancel_backend(26433)
Sure.
20 days is a long time. Is it actually running, or blocked
Jason Culverhouse wrote:
> The server is postgres 8.3 on ubuntu linux.
There have been a number of bugs fixed in vacuuming, including
autovacuum, since the original 8.3 release. I hope you mean
8.3.somethingrecent -- if not, you should get the latest fixes.
> Can I safely kill the vacuum wi
Enrico Weigelt writes:
> I'm doing regular (hourly) dumps and putting them into git
> (and automatically pushing it to several git servers).
> The problem is: the dumps are always differing (even if nothing
> happened in that db).
> CREATE TEMPORARY TABLE pgdump_oid (dummy integer) WITH OIDS;
>
I wrote:
> I have no idea why EDB recommend changing the maxproc settings, but
> I doubt that's related to shared memory. I see that they have shmmax
> equal to exactly 4096 times shmall, so that's good, but there must be
> some other OSX peculiarity that this is tripping over. Maybe it's too
> l
I wrote:
> ... OTOH I'd have expected you to have to reboot multiple
> times while experimenting with the shm parameters, so I'm not entirely
> convinced I've hit on the right explanation.
Oh ... were you using sysctl -w rather than rebooting to adjust the
shmmem parameters? I realized after expe
Scott Whitney wrote:
On the 10k vs 15k rpm disks, there's a _lot_ to be said about that. I don't want to start a flame war here,
but 15k versus 10k rpm hard drives does NOT equivocate to a 50% increase in read/write times, to say
the VERY least.
Your characterization is correct were there o
A _very_ valid point which I omitted simply because it once again points to 24
spindles
equating to a faster array than 12. The problem, as you so easily summarize, is
the fact
that once you put any decent RAID controller into this, you've essentially
added
a magic black box that does "better
I had a very strange occurrence 2 days ago where autovacuum appears to
have stopped running.
I did not see any error messages in pg_log. The problem caused a file
which is usually around 50Mb but which gets updated extensively to grow
to 105GB, which in turn brought the server's performance down
On Apr 30, 2010, at 3:35 PM, Tom Lane wrote:
> Does the theory of a pre-existing smaller shmem segment make sense from
> your end? In particular, had you previously had another Postgres server
> running on that machine, and perhaps killed it ungracefully? If this
> theory is correct, the issue wa
18 matches
Mail list logo
