Le 13/10/2010 23:20, Guillaume Lelarge a écrit :
> Hi Kasia,
>
> Le 13/10/2010 22:21, Kasia Tuszynska a écrit :
>> [...]
>> Thanks for your reply I did a bit more testing with the superuser priv
>> issue, and now I came to the conclusion that pgAdminIII may be doing
>> something silly.
>>
>
> S
Le 15/10/2010 21:31, Tom Lane a écrit :
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
>> On Fri, 2010-10-15 at 12:18 -0700, Isabella Ghiurea wrote:
>>> ERROR: column t.tgisconstraint does not exist at character 387
>
>> Could it be a non-9.0 aware client software?
>
> So it would appear. pgAdm
Hi All
we would like to implement a virtual ip for two of our of our PG db
hosts to help us with switching hosts with less downtime for clients, is
there any specific change need to be done on PG database hosts
configuration , I was thinking maybe pg_hba.conf file ?
Thank you
Isabella
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Fri, 2010-10-15 at 12:18 -0700, Isabella Ghiurea wrote:
>> ERROR: column t.tgisconstraint does not exist at character 387
> Could it be a non-9.0 aware client software?
So it would appear. pgAdmin maybe? I thought at first that it might be
an o
On Oct 16, 2010, at 12:48 AM, Isabella Ghiurea wrote:
> ERROR: column t.tgisconstraint does not exist at character 387
> 2010-10-15 12:09:56 PDT[25262]:[2-1]STATEMENT: SELECT t.oid, t.tgname AS
> name, t.tgtype, t.tgenabled, t.tgdeferrable, t.tginitdeferred, t.tgnargs,
> t.tgargs, p.proname,
Devrim GÜNDÜZ wrote:
On Fri, 2010-10-15 at 12:18 -0700, Isabella Ghiurea wrote:
I have upgrade my existing env PG 8.4.4 to PG 9.0.1 , run a dump and
restore and recreate the table space.
The upgrade went smooth no issues until I restart the db and I see
this
in PG erorrlog, any ideas if t
On Fri, 2010-10-15 at 12:18 -0700, Isabella Ghiurea wrote:
> I have upgrade my existing env PG 8.4.4 to PG 9.0.1 , run a dump and
> restore and recreate the table space.
> The upgrade went smooth no issues until I restart the db and I see
> this
> in PG erorrlog, any ideas if this is a new tabl
Hi All,
I have upgrade my existing env PG 8.4.4 to PG 9.0.1 , run a dump and
restore and recreate the table space.
The upgrade went smooth no issues until I restart the db and I see this
in PG erorrlog, any ideas if this is a new table or any changes have
been made to this table.
ERROR:
On Linux at least - not sure about Windows - deleting a file does
not remove it from the file system until there are no more processes
holding the file open.
So while postgres holds the file open, it can keep writing to it
happily.
You won't be able to see the file i
I am curious about this scenario:
What is going to happen when a server is running and the Postgres log file is
accidentally deleted or renamed? The server will have no place to write its
log
entries obviously.. what else?.
Is there any way to check within Postgres what the current log name (
10 matches
Mail list logo