Re: pg_dump With OIDs Supported?
| От | Dylan Hansen |
|---|---|
| Тема | Re: pg_dump With OIDs Supported? |
| Дата | |
| Msg-id | 8B524B34-75A6-4354-96C2-65CE8A432864@pixpo.com обсуждение исходный текст |
| Ответ на | Re: pg_dump With OIDs Supported? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-general |
Hi Tom, thanks for your reply.
On 23-Jun-06, at 11:17 AM, Tom Lane wrote:
--oids is only meant to preserve OIDs within user tables; it never hasand never will preserve OIDs for system-catalog entries.
So just to clarify, the table's OID itself will never be preserved, but the data inside the table will? Does each row have it's own OID? Pardon my n00b-ness on this question...
The real problem here is pg_autovacuum, which doesn't have any dump/restoresupport at the moment. This is because we stuck it into 8.1 at the lastminute and aren't yet convinced it will survive in its current form.
It strikes me that a relatively trivial hack would make it easier todump and restore pg_autovacuum manually using COPY: change the declaredtype of the vacrelid column to "regclass". This would make nodifference to the internal use of the table, but it'd cause COPY to emitthe column values in a symbolic format that would restore correctly.
What I have done for the time being is created a script to be done that executes after every restore of the database that enters into pg_autovacuum based on the table name. For example:
INSERT INTO pg_autovacuum
(vacrelid, enabled, vac_base_thresh, vac_scale_factor, anl_base_thresh, anl_scale_factor, vac_cost_delay, vac_cost_limit)
VALUES ((select oid from pg_class where relname = 'tablename'), true, 500, 0.1, 200, 0.05, -1, -1);
This will work for now. It would be nice to have the vacrelid stay the same for each restore as the app we are currently using PostgreSQL with allows a script to be run before the dump is restored. I will just have to alter it to be run after the dump is restored.
Thanks!
--
Dylan Hansen
Enterprise Systems Developer
В списке pgsql-general по дате отправления: