Hi all
Postgresql 9.3.14 on Windows.
Hi am making daily backups of a database and omitting two schemas from
the dump (and the public schema). Those schemas are read-only and have
no dependancy with the rest of the database.
My command is :
pg_dump -h pgsql1 -U postgres -b -Fc -E UTF8 -N public
Le 15/11/2016 à 16:21, Adrian Klaver a écrit :
The restore fails on a lot of statements, complaining about dependencies.
For instance, "cannot drop rule _RETURN on view myview1 because view
myview1requires it". Or "cannot drop constraint mypkey on table my table
because other objects depend on it
Le 15/11/2016 à 16:44, Tom Lane a écrit :
You'd have to provide a lot more detail before anyone could tell if there
was a fixable bug here, but I rather doubt it. There are at least two
ways this scenario might lose:
1. There are additional objects in the target database that have
dependencies
Le 16/11/2016 à 20:05, Tom Lane a écrit :
Arnaud Lesauvage writes:
[ dump from problematic database ]
OK, thanks for the test case. The problem here is that pg_dump is setting
up a circular dependency that it doesn't know how to break correctly.
You've got a couple of views that are implicit
Hi
The pg_upgrade documentation for PostgreSQL 9.6 states that --link will
use junction points on Windows.
Shouldn't it rather user hard-links ?
If I'm not mistaken, with junction points (i.e. soft-links to
directories), the old data dir cannot be removed.
With hard-links to file, we can get r
Le 9/06/2017 à 16:07, Bruce Momjian a écrit :
I was told junction points on Windows were hard links and no one has
ever complained about not being able to remove them.
Sorry, I think my explanation was not very clear.
You can remove the link, but the point is to remove the target (i.e. the
old
Le 9/06/2017 à 16:55, Adrian Klaver a écrit :
On 06/09/2017 07:39 AM, Arnaud L. wrote:
So maybe pg_upgrade uses hard-links (i.e. to files), and only the
documentation is wrong by calling them junctions (i.e. soft links to
files) ?
Looks that way. In file.c in ~/src/bin/pg_upgrade I see
Le 9/06/2017 à 17:02, Arnaud L. a écrit :
Le 9/06/2017 à 16:55, Adrian Klaver a écrit :
On 06/09/2017 07:39 AM, Arnaud L. wrote:
So maybe pg_upgrade uses hard-links (i.e. to files), and only the
documentation is wrong by calling them junctions (i.e. soft links to
files) ?
Looks that way. In
Hi all
Using PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 32-bit (on
Windows, obviously).
I noticed that my vacuumdb was hanging on a specific index, so I decided
that the easiest path was to create a duplicate of it (CREATE INDEX
CONCURRENTLY myindex_v2 ...), and drop the original one