From: | Groshev Andrey <greenx(at)yandex(dot)ru> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 |
Date: | 2012-12-20 05:30:40 |
Message-ID: | 1236831355981440@web8h.yandex.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
No, people can confuse writing, but it makes a computer.
Unfortunately, I have not found developer this database, but I understand the logic was:
plob - primary key (lob ~ BLOB)
rlob - reference key (lob ~ BLOB)
Maybe if I describe the task, this part of the database, the problem is clear.
We need to maintain external documents (binary scans, per page).
Therefore, there is a table to store the titles and a table to store binary data.
To make it more comfortable I replaced all Russian words translated words.
This a table for headers store.
-- Table: "VersionOfTheExternalDocument$Document"
-- DROP TABLE "VersionOfTheExternalDocument$Document";
CREATE TABLE "VersionOfTheExternalDocument$Document"
(
"@File" integer NOT NULL DEFAULT nextval((pg_get_serial_sequence('"public"."VersionOfTheExternalDocument$Document"'::text, '@File'::text))::regclass),
"GUID" uuid,
"DataTime" timestamp without time zone DEFAULT (now())::timestamp without time zone,
"Name" character varying,
"Size" integer,
CONSTRAINT "VersionOfTheExternalDocument$Document_pkey" PRIMARY KEY ("@File")
)
WITH (
OIDS=FALSE
);
ALTER TABLE "VersionOfTheExternalDocument$Document"
OWNER TO postgres;
GRANT ALL ON TABLE "VersionOfTheExternalDocument$Document" TO postgres;
GRANT SELECT ON TABLE "VersionOfTheExternalDocument$Document" TO view_user;
-- Index: "iVersionOfTheExternalDocument$Document-blb_header"
-- DROP INDEX "iVersionOfTheExternalDocument$Document-blb_header";
CREATE INDEX "iVersionOfTheExternalDocument$Document-blb_header"
ON "VersionOfTheExternalDocument$Document"
USING btree
("GUID", "@Файл", "ДатаВремя")
WHERE "GUID" IS NOT NULL;
---------------------------------------------------------------
And this for data.
-- Table: "lob.VersionOfTheExternalDocument$Document"
-- DROP TABLE "lob.VersionOfTheExternalDocument$Document";
CREATE TABLE "lob.VersionOfTheExternalDocument$Document"
(
"@File" integer NOT NULL,
"Page" integer NOT NULL,
"Data" bytea,
CONSTRAINT "lob.VersionOfTheExternalDocument$Document_pkey" PRIMARY KEY ("@File", "Page"),
CONSTRAINT "rlob(dot)VersionOfTheExternalDocument$Document-(at)File" FOREIGN KEY ("@File")
REFERENCES "VersionOfTheExternalDocument$Document" ("@File") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE INITIALLY IMMEDIATE
)
WITH (
OIDS=FALSE
);
ALTER TABLE "lob.VersionOfTheExternalDocument$Document"
OWNER TO postgres;
GRANT ALL ON TABLE "lob.VersionOfTheExternalDocument$Document" TO postgres;
GRANT SELECT ON TABLE "lob.VersionOfTheExternalDocument$Document" TO view_user;
20.12.2012, 07:12, "Bruce Momjian" <bruce(at)momjian(dot)us>:
> On Wed, Dec 19, 2012 at 10:35:11PM -0500, Bruce Momjian wrote:
>
>>> There is another table "ВерсияВнешнегоДокумента$Документ" (without ^lob.)
>>> It is referenced by a foreign key ("rlob(dot)ВерсияВнешнегоДокумента$Документ-(at)Файл")
>>> But as I understand it, the problem with the primary key.
>> Does the old database have a table with prefix "plob.", called
>> plob.ВерсияВнешнегоДокумента$Документ?
>>
>> If not, if you do pg_dumpall --schema-only --binary-upgrade, is there a
>> table with that name mentioned?
>
> Also, when you say "rlob" above, is the 'r' a Latin letter sound that
> would look like a Russian 'p' in the error message? (In Cyrillic, a
> Latin-looking p sounds like Latin-sounding r.)
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Kesten | 2012-12-20 06:42:43 | Re: How to startup the database server? |
Previous Message | Groshev Andrey | 2012-12-20 04:55:16 | Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Groshev Andrey | 2012-12-20 05:34:44 | Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 |
Previous Message | Amit Kapila | 2012-12-20 05:22:10 | Re: Set visibility map bit after HOT prune |