thanks andy!
a little off-topic, but about database reorganization - is it recommended
to group all sequences and domains under the public schema? or is a
sequence tied to one table and is better in its separate schema?
what about replication options for x64 systems since slony is not an option?
moving from 8.1 to 9.3, and redesigning at the same time (using navicat and
psql).
have access to both 8.1 and 9.3. and by redesigning i mean, going from
multiple databases to multiple schemas.
so what's the best approach?
On 11/06/2013 03:08 PM, zach cruise wrote:
moving from 8.1 to 9.3, and redesigning at the same time (using navicat and
psql).
have access to both 8.1 and 9.3. and by redesigning i mean, going from multiple
databases to multiple schemas.
so what's the best approach?
Having just done that, I
Greetings,
I just got around to upgrading from 9.3-beta1 to 9.3-beta2, and was
surprised to see that the server was refusing to start. In the log,
I'm seeing:
2013-07-24 13:41:47 PDT [7083]: [1-1] db=,user= FATAL: database files
are incompatible with server
2013-07-24 13:41:47 PDT [7083]: [2-1]
Lonni J Friedman escribió:
I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
expected, intentional behavior? Do I really need to dump reload to
upgrade between beta releases of 9.3, or is there some more efficient
way?
We try to avoid forcing initdb between beta versions, but
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Lonni J Friedman escribió:
I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
expected, intentional behavior? Do I really need to dump reload to
upgrade between beta releases of 9.3, or is there some more efficient
way?
We try to
On Wed, Jul 24, 2013 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Lonni J Friedman escribió:
I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
expected, intentional behavior? Do I really need to dump reload to
upgrade between
