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
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
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 à 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
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
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
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 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
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