We did use pg_upgrade with the hard link option. We are not sure if we ran the cleanup script.
Not sure which script you are referring to? Is that script the one that removes the stuff in the source bin directory?
We did the pg_largeobject.sql script, as we were instructed by the pg_upgrade pr
Ups, thank you for clarification.
Regards, Michael
Am 27.02.2013 16:45, schrieb Tom Lane:
> michael.e...@wincor-nixdorf.com writes:
>
>> in page docs/9.1/static/trigger-definition.html (applies also for other
>> versions):
>> ... while row-level AFTER triggers fire at the end of the statement .
On 2/25/13 7:59 PM, adam.tomj...@zuerchertech.com wrote:
> I have a database that uses a user-defined datatype. If the .so file
> implementing that type is missing, pg_dump will fail when dumping a table
> which uses that type, but it will still exit with status 0. The dump file
> will be truncat
"fburg...@radiantblue.com" wrote:
> We have a Postgres database that was recently upgraded from 8.4.3
> to 9.1.6. We have noticed unusual growth in the data files and
> generated a script to perform the following actions.
> 1. Query pg_class for all records
> 2. Generate a file listing of all p
michael.e...@wincor-nixdorf.com writes:
> in page docs/9.1/static/trigger-definition.html (applies also for other
> versions):
> ... while row-level AFTER triggers fire at the end of the statement ...
> should be changed to
> ... while row-level AFTER triggers fire immediately after a particular ro
The following bug has been logged on the website:
Bug reference: 7908
Logged by: Michael Enke
Email address: michael.e...@wincor-nixdorf.com
PostgreSQL version: 9.1.8
Operating system: CentOS 6.2
Description:
in page docs/9.1/static/trigger-definition.html (applies al
