Hi Łukasz,
is postgres really listening on all addresses?
Please run the following command on your postgres server and post the
output:
# netstat -nltp | grep postgres
And what is the error message when you try to connect with
# psql -h
Regards
Frank
Am 04.03.2011 07:53, schrieb Lukasz Brod
Hi,
I have a problem with PostgreSQL 8.2.4 I've installed it on Ubuntu
configured to listen to all addresses started and still can't add the
server to pgAdmin on a remote machine neither can I connect through my
own app. All the credentials are ok, there is no NAT (it's LAN),
firewall or antivirus
> > ? Did you read the paragraph above?
> >
> > Install latest version, and restart postmaster.
>
> Installing of latest version as-is will keep overwriting the existing
> installed directories/files/binaries but not the "/usr/local/pgsql/data/"
> directory right? Since this is our production s
On Mar 2, 8:37 pm, masao.fu...@gmail.com (Fujii Masao) wrote:
> On Wed, Mar 2, 2011 at 11:17 PM, Jason Clark
>
> wrote:
> > so thats not an issue, also, the backup server is pulling the WAL
> > files and loading them properly, here is my recovery.conf file:
>
> > standby_mode = 'on'
> > restore_co
On Thu, Mar 3, 2011 at 2:16 AM, Heikki Linnakangas
wrote:
> On 03.03.2011 09:12, daveg wrote:
>>
>> Question: what would be the consequence of simply patching out the setting
>> of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
>> problem (big assumption perhaps) then simpl
On Wed, Mar 02, 2011 at 01:10:37PM -0500, Vaughn, Adam (IMS) wrote:
> Thanks for the suggestions. I made all of the changes you mentioned except
> for the shared_buffers (which will require a downtime I have set for
> tonight). I do have another question though, why did you pick 512 MB for the
>
On Thu, Mar 03, 2011 at 10:16:29AM +0200, Heikki Linnakangas wrote:
> On 03.03.2011 09:12, daveg wrote:
> >Question: what would be the consequence of simply patching out the setting
> >of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
> >problem (big assumption perhaps) then
OK, here goes:
-- For binary upgrade, must preserve relfilenodes
SELECT binary_upgrade.set_next_heap_relfilenode('88788'::pg_catalog.oid);
SELECT binary_upgrade.set_next_toast_relfilenode('88795'::pg_catalog.oid);
SELECT binary_upgrade.set_next_index_relfilenode('88797'::pg_catalog.oid);
CREATE
On 03.03.2011 09:12, daveg wrote:
Question: what would be the consequence of simply patching out the setting
of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
problem (big assumption perhaps) then simply never setting it would at least
avoid the possibility of returning wr
