On Wed, Dec 7, 2011 at 10:05, Magnus Hagander wrote:
> On Tue, Dec 6, 2011 at 17:07, Tom Lane wrote:
>> Magnus Hagander writes:
>>> There is some nice precedent in the CREATE TABLESPACE command (though
>>> dependent on HAVE_SYMLINK and not HAVE_READLINK), so I'm just going to
>>> copy the error
On Tue, Dec 6, 2011 at 17:07, Tom Lane wrote:
> Magnus Hagander writes:
>> There is some nice precedent in the CREATE TABLESPACE command (though
>> dependent on HAVE_SYMLINK and not HAVE_READLINK), so I'm just going to
>> copy the error message from there.
>
> Fair enough.
>
> Looking at the exis
Magnus Hagander writes:
> There is some nice precedent in the CREATE TABLESPACE command (though
> dependent on HAVE_SYMLINK and not HAVE_READLINK), so I'm just going to
> copy the error message from there.
Fair enough.
Looking at the existing readlink use in port/exec.c, it strikes me that
anoth
On Tue, Dec 6, 2011 at 16:17, Tom Lane wrote:
> Magnus Hagander writes:
>> Throwing an error seems a lot more safe in this case than just
>> returning NULL. Since it's a situtation that really shouldn't happen.
>> Maybe an assert, but I think a regular ereport(ERROR) would be the
>> best.
>
> Not
Magnus Hagander writes:
> Throwing an error seems a lot more safe in this case than just
> returning NULL. Since it's a situtation that really shouldn't happen.
> Maybe an assert, but I think a regular ereport(ERROR) would be the
> best.
Not an assert, since it's trivially user-triggerable.
On Tue, Dec 6, 2011 at 16:12, Tom Lane wrote:
> Magnus Hagander writes:
>> AFAICT, it should be as simple as the attached.
>
> Oh, one other thought is that the function body has to be
> conditionalized on HAVE_READLINK (the fact that you forgot that
> somewhere else isn't an excuse for not doing
Magnus Hagander writes:
> AFAICT, it should be as simple as the attached.
Oh, one other thought is that the function body has to be
conditionalized on HAVE_READLINK (the fact that you forgot that
somewhere else isn't an excuse for not doing it here). IIRC,
only the two built-in tablespaces can e
Magnus Hagander writes:
> + snprintf(sourcepath, sizeof(sourcepath), "pg_tblspc/%d", tablespaceOid);
%u for an OID, please. Otherwise seems reasonably sane on first glance.
regards, tom lane
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make ch
On Sun, Dec 4, 2011 at 18:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/04/2011 11:41 AM, Tom Lane wrote:
>>> Hm, how portable is symlink-reading? If we can actually do that
>>> without big headaches, then +1.
>
>> I wondered that, specifically about Windows junction points, but we seem
Andrew Dunstan writes:
> On 12/04/2011 11:41 AM, Tom Lane wrote:
>> Hm, how portable is symlink-reading? If we can actually do that
>> without big headaches, then +1.
> I wondered that, specifically about Windows junction points, but we seem
> to have support for it already in dirmod.c::pgreadl
On 12/04/2011 11:41 AM, Tom Lane wrote:
1) Remove the column. Rely on the symlink. Create a
pg_get_tablespace_location(oid) function, that could be used by
pg_dumpall and friends, that just reads the symlink.
Hm, how portable is symlink-reading? If we can actually do that
without big headac
On Sun, Dec 4, 2011 at 17:41, Tom Lane wrote:
> Magnus Hagander writes:
>> And IIRC, we don't actually *use* spclocation anywhere.
>
> Just for pg_dump, I think.
pg_dumpall :-)
It's also used in pg_upgrade and pg_basebackup, but those are easily
dealt with if we define a function for it.
>> H
Magnus Hagander writes:
> And IIRC, we don't actually *use* spclocation anywhere.
Just for pg_dump, I think.
> How about we
> just get rid of them as independents? We could either:
> 1) Remove the column. Rely on the symlink. Create a
> pg_get_tablespace_location(oid) function, that could be us
On Sun, Dec 4, 2011 at 17:12, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Sun, Dec 4, 2011 at 00:43, Bruce Momjian wrote:
>> > Do we have any documentation about how to move a tablespace to a new
>> > directory? ?If not, I think we should write some.
>>
>> Do we have any support for doing
Magnus Hagander wrote:
> On Sun, Dec 4, 2011 at 00:43, Bruce Momjian wrote:
> > Do we have any documentation about how to move a tablespace to a new
> > directory? ?If not, I think we should write some.
>
> Do we have any support for doing it? (Yes, it works, but anything that
> requires manual h
On Sun, Dec 4, 2011 at 00:43, Bruce Momjian wrote:
> Do we have any documentation about how to move a tablespace to a new
> directory? If not, I think we should write some.
Do we have any support for doing it? (Yes, it works, but anything that
requires manual hacking of system catalogs really ca
Do we have any documentation about how to move a tablespace to a new
directory? If not, I think we should write some.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via p
17 matches
Mail list logo
