Re: [HACKERS] Largeobject Access Controls and pg_migrator
Takahiro Itagaki wrote: > > KaiGai Kohei wrote: > > > Can SELECT lo_create(16385); help this situation? > > SELECT lo_create(loid) FROM (SELECT DISTINCT loid FROM pg_largeobject) AS t > > would work for pg_migrator. > > > I'm not clear whether we also check pg_largeobejct has chunks with same > > LOID on lo_create(). In the regular operation, it shall never happen. > > I think the omission is a reasonable optimization. Thanks, I have updated pg_migrator to use your suggested method. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls and pg_migrator
KaiGai Kohei wrote: > Can SELECT lo_create(16385); help this situation? SELECT lo_create(loid) FROM (SELECT DISTINCT loid FROM pg_largeobject) AS t would work for pg_migrator. > I'm not clear whether we also check pg_largeobejct has chunks with same > LOID on lo_create(). In the regular operation, it shall never happen. I think the omission is a reasonable optimization. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls and pg_migrator
(2009/12/13 11:31), Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
lo_import() has an another prototype which takes second argument to
specify LOID. Isn't it available to restore a large object with
correct LOID? For example, lo_import('/etc/profile', 1234)
I can't use that because the migration has already brought over the
pg_largeobject file which has the data.
Or, if you intend to restore metadata in the second lo_import(),
ALTER LAEGE OBJECT and GRANT LARGE OBJECT enable to set up metadata
of a certain large object.
Yes, that will work cleanly. The file might be large because I need a
GRANT for every large object, but I suppose that is OK.
Uh, I tested pg_migrator and found a problem with this approach:
test=> select loid from pg_largeobject;
loid
---
16385
16385
16386
(3 rows)
test=> grant all ON LARGE OBJECT 16385 to public;
ERROR: large object 16385 does not exist
I am wondering if the missing pg_largeobject_metadata row is causing
this, and again I have no way of creating one with the specified oid.
Can SELECT lo_create(16385); help this situation?
It create an entry into pg_largeobject_metadata, but does not touch
pg_largeobject because it is empty in the initial state.
But, in this case, pg_migrator already bring only data chunks to
pg_largeobject. So, this operation enables to recombine orphan chunks
and a metadata entry.
I'm not clear whether we also check pg_largeobejct has chunks with same
LOID on lo_create(). In the regular operation, it shall never happen.
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls and pg_migrator
Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > lo_import() has an another prototype which takes second argument to
> > specify LOID. Isn't it available to restore a large object with
> > correct LOID? For example, lo_import('/etc/profile', 1234)
>
> I can't use that because the migration has already brought over the
> pg_largeobject file which has the data.
>
> > Or, if you intend to restore metadata in the second lo_import(),
> > ALTER LAEGE OBJECT and GRANT LARGE OBJECT enable to set up metadata
> > of a certain large object.
>
> Yes, that will work cleanly. The file might be large because I need a
> GRANT for every large object, but I suppose that is OK.
Uh, I tested pg_migrator and found a problem with this approach:
test=> select loid from pg_largeobject;
loid
---
16385
16385
16386
(3 rows)
test=> grant all ON LARGE OBJECT 16385 to public;
ERROR: large object 16385 does not exist
I am wondering if the missing pg_largeobject_metadata row is causing
this, and again I have no way of creating one with the specified oid.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls and pg_migrator
KaiGai Kohei wrote:
> lo_import() has an another prototype which takes second argument to
> specify LOID. Isn't it available to restore a large object with
> correct LOID? For example, lo_import('/etc/profile', 1234)
I can't use that because the migration has already brought over the
pg_largeobject file which has the data.
> Or, if you intend to restore metadata in the second lo_import(),
> ALTER LAEGE OBJECT and GRANT LARGE OBJECT enable to set up metadata
> of a certain large object.
Yes, that will work cleanly. The file might be large because I need a
GRANT for every large object, but I suppose that is OK.
> > You might remember that INSERT cannot set the oid of a row, so I don't
> > see how pg_migrator can migrate this? Is there a reason we used 'oid'
> > in pg_largeobject_metadata but 'lobj' in pg_largeobject? Why did't we
> > add the lomowner and lomacl columns to pg_largeobject?
>
> A large object consists of multiple tuples within pg_largeobject.
> If we added lomowner and lomacl into pg_largeobject, we have to manage
> all the pages in a large object to keep consistent state.
Ah, good point.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls and pg_migrator
(2009/12/13 10:39), Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
What happens when
there is no entry in pg_largeobject_metadata for a specific row?
In this case, these rows become orphan.
So, I think we need to create an empty large object with same LOID on
pg_migrator. It makes an entry on pg_largeobject_metadata without
writing anything to the pg_largeobject.
I guess rest of migrations are not difference. Correct?
Agreed. I have modified pg_migrator with the attached patch which
creates a script that adds default permissions for all large object
tables.
Oops, seem like I have a problem in getting pg_migrator to populate
pg_largeobject_metadata:
test=> select lo_import('/etc/profile');
lo_import
---
16385
(1 row)
test=> select lo_import('/etc/profile.env');
lo_import
---
16386
(1 row)
test=> select oid,* from pg_largeobject_metadata;
oid | lomowner | lomacl
---+--+
16385 | 10 |
16386 | 10 |
(2 rows)
lo_import() has an another prototype which takes second argument to
specify LOID. Isn't it available to restore a large object with
correct LOID? For example, lo_import('/etc/profile', 1234)
Or, if you intend to restore metadata in the second lo_import(),
ALTER LAEGE OBJECT and GRANT LARGE OBJECT enable to set up metadata
of a certain large object.
Or, am I missing the problem?
You might remember that INSERT cannot set the oid of a row, so I don't
see how pg_migrator can migrate this? Is there a reason we used 'oid'
in pg_largeobject_metadata but 'lobj' in pg_largeobject? Why did't we
add the lomowner and lomacl columns to pg_largeobject?
A large object consists of multiple tuples within pg_largeobject.
If we added lomowner and lomacl into pg_largeobject, we have to manage
all the pages in a large object to keep consistent state.
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Largeobject Access Controls and pg_migrator
Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > > What happens when
> > > there is no entry in pg_largeobject_metadata for a specific row?
> >
> > In this case, these rows become orphan.
> > So, I think we need to create an empty large object with same LOID on
> > pg_migrator. It makes an entry on pg_largeobject_metadata without
> > writing anything to the pg_largeobject.
> > I guess rest of migrations are not difference. Correct?
>
> Agreed. I have modified pg_migrator with the attached patch which
> creates a script that adds default permissions for all large object
> tables.
Oops, seem like I have a problem in getting pg_migrator to populate
pg_largeobject_metadata:
test=> select lo_import('/etc/profile');
lo_import
---
16385
(1 row)
test=> select lo_import('/etc/profile.env');
lo_import
---
16386
(1 row)
test=> select oid,* from pg_largeobject_metadata;
oid | lomowner | lomacl
---+--+
16385 | 10 |
16386 | 10 |
(2 rows)
You might remember that INSERT cannot set the oid of a row, so I don't
see how pg_migrator can migrate this? Is there a reason we used 'oid'
in pg_largeobject_metadata but 'lobj' in pg_largeobject? Why did't we
add the lomowner and lomacl columns to pg_largeobject?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
