Peter Eisentraut writes:
> On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>> handled *exactly* the way that the -D target directory of initdb is.
On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote:
> Yeah. We have gotten complaints in the past from people who tried to
> specify a mount point as a tablespace, and it failed because of
> lost+found or the mount dir being root-owned. We've told them to make
> a subdirectory, but that always see
On Sat, Dec 11, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote:
>>> I'm not really thinking about crash recovery, but replication slaves.
>>> Omitting to create the tablespace location directories on slaves
>>> doesn't seem far-fetched a
Robert Haas writes:
> On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote:
>> I'm not really thinking about crash recovery, but replication slaves.
>> Omitting to create the tablespace location directories on slaves
>> doesn't seem far-fetched at all. Of course, it's likely that
>> the slave server
On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote:
>>> OK. Is there any value in doing mkdir -p in WAL-recovery execution of
>>> CREATE TABLESPACE but not regular execution?
>
>> I don't think so. If someone creates a dir
Robert Haas writes:
> On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote:
>> OK. Is there any value in doing mkdir -p in WAL-recovery execution of
>> CREATE TABLESPACE but not regular execution?
> I don't think so. If someone creates a directory that is not fsync'd,
> and then creates a subdirec
On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
Anybody have a problem with adopting this behavior?
>
>>> Seems a bit surprising.
>
>> Yeahh.. I'm not really sure
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
>>> Anybody have a problem with adopting this behavior?
>> Seems a bit surprising.
> Yeahh.. I'm not really sure about mkdir -p type actions from a SQL
> command. Not enti
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
> > Anybody have a problem with adopting this behavior?
>
> Seems a bit surprising.
Yeahh.. I'm not really sure about mkdir -p type actions from a SQL
command. Not entirely sure why but it doesn't
On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
> I wrote:
>>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>>> handled *exactly* the way that the -D target directory of initdb is.
>
> One intere
I wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>> handled *exactly* the way that the -D target directory of initdb is.
One interesting point here is that initdb uses the equivalent of mkdi
On 12/10/2010 06:01 PM, Tom Lane wrote:
Robert Haas writes:
+1 for src/port.
...
At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
I think this is the sensible way to go
Robert Haas writes:
> +1 for src/port.
> ...
> At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Fri, Dec 10, 2010 at 3:26 PM, Tom Lane wrote:
> I'm finally getting around to something that's been on my todo list for
> a couple of months.
>
> I wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ough
I'm finally getting around to something that's been on my todo list for
a couple of months.
I wrote:
> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
> handled *exactly* the way that the -D target dire
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Looking at the pg_upgrade code some more, I found that it was not
> >>> removing the PG_VERSION file when deleting <= 8.4 tablespace files.
> >>> This might confuse administrators so the attached patch a
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> Looking at the pg_upgrade code some more, I found that it was not
>>> removing the PG_VERSION file when deleting <= 8.4 tablespace files.
>>> This might confuse administrators so the attached patch adds the removal
>>> of PG_VE
Tom Lane wrote:
> Bruce Momjian writes:
> > Looking at the pg_upgrade code some more, I found that it was not
> > removing the PG_VERSION file when deleting <= 8.4 tablespace files.
> > This might confuse administrators so the attached patch adds the removal
> > of PG_VERSION. I would like to ap
Bruce Momjian writes:
> Looking at the pg_upgrade code some more, I found that it was not
> removing the PG_VERSION file when deleting <= 8.4 tablespace files.
> This might confuse administrators so the attached patch adds the removal
> of PG_VERSION. I would like to apply this to master and 9.0
bruce wrote:
> Tom Lane wrote:
> > Dave Cramer writes:
> > > as seen below create tablespace does not throw an error or appear to
> > > do anything other than register the tablespace.
> >
> > I suspect this behavior is partially intentional, because tablespace
> > creation now involves an extra l
Tom Lane wrote:
> Yeah. We have gotten complaints in the past from people who tried to
> specify a mount point as a tablespace, and it failed because of
> lost+found or the mount dir being root-owned. We've told them to make a
> subdirectory, but that always seemed like a workaround. With the ne
Robert Haas writes:
> On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane wrote:
>> Given the use of the version-numbered subdirectory, I see no real merit
>> in insisting that the parent directory be empty anyway. It'd be
>> precisely analogous to "initdb -D /foo/bar/data" insisting that /foo/bar
>> be e
On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote:
>>> Robert Haas wrote:
I haven't yet been convinced we need or want to relax the rule about
the directory being empty.
>>>
>>> Uh, how would pg_upgrade work t
Robert Haas writes:
> On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote:
>> Robert Haas wrote:
>>> I haven't yet been convinced we need or want to relax the rule about
>>> the directory being empty.
>>
>> Uh, how would pg_upgrade work then? It would require renaming the
>> top-level tablespa
Robert Haas wrote:
> On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote:
> >> > Bruce Momjian writes:
> >> >> Robert Haas wrote:
> >> >>> Perhaps we should fix the behavior rather than the documentation.
> >> >
> >> >
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote:
>> > Bruce Momjian writes:
>> >> Robert Haas wrote:
>> >>> Perhaps we should fix the behavior rather than the documentation.
>> >
>> >> We can't fix the behavior because
Robert Haas wrote:
> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Robert Haas wrote:
> >>> Perhaps we should fix the behavior rather than the documentation.
> >
> >> We can't fix the behavior because we have to allow an old cluster to
> >> keep its tablespace fi
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Perhaps we should fix the behavior rather than the documentation.
>
> > We can't fix the behavior because we have to allow an old cluster to
> > keep its tablespace files during a pg_upgrade. They are given a script
> > to delet
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I suspect this behavior is partially intentional, because tablespace
> >> creation now involves an extra level of subdirectory. However, it's
> >> not clear to me why CREATE TABLESPACE is still changing the permissions
> >> on the p
On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> Perhaps we should fix the behavior rather than the documentation.
>
>> We can't fix the behavior because we have to allow an old cluster to
>> keep its tablespace files during a pg_upgrade. They ar
Bruce Momjian writes:
> Robert Haas wrote:
>> Perhaps we should fix the behavior rather than the documentation.
> We can't fix the behavior because we have to allow an old cluster to
> keep its tablespace files during a pg_upgrade. They are given a script
> to delete those files later, if they w
Bruce Momjian writes:
> Tom Lane wrote:
>> I suspect this behavior is partially intentional, because tablespace
>> creation now involves an extra level of subdirectory. However, it's
>> not clear to me why CREATE TABLESPACE is still changing the permissions
>> on the parent directory. Bruce, exa
Dave Cramer wrote:
> >> >> IIRC the reason this works is that the tablespace code now creates a
> >> >> version-specific subdirectory inside the specified directory. ?This was
> >> >> done to help binary upgrades.
> >> >
> >> > Right, the directory is catalog-version named, which was done to allow
Dave Cramer wrote:
> >> >> > postgres=# select version();
> >> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? version
> >> >> > ---
> >> >> > ?PostgreSQL 9.0.1 on x86_64-unkno
On Mon, Oct 18, 2010 at 2:39 PM, Bruce Momjian wrote:
> Dave Cramer wrote:
>> On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote:
>> > Alvaro Herrera wrote:
>> >> Hi Dave,
>> >>
>> >> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
>> >> > as seen below create tablespace
Dave Cramer wrote:
> On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Hi Dave,
> >>
> >> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
> >> > as seen below create tablespace does not throw an error or appear to
> >> > do anything other t
On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Hi Dave,
>>
>> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
>> > as seen below create tablespace does not throw an error or appear to
>> > do anything other than register the tablespace.
>> >
Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian wrote:
> > Dave Cramer wrote:
> >> On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote:
> >> > Dave Cramer writes:
> >> >> as seen below create tablespace does not throw an error or appear to
> >> >> do anything other than register
Tom Lane wrote:
> Dave Cramer writes:
> > as seen below create tablespace does not throw an error or appear to
> > do anything other than register the tablespace.
>
> I suspect this behavior is partially intentional, because tablespace
> creation now involves an extra level of subdirectory. Howe
Alvaro Herrera wrote:
> Hi Dave,
>
> Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
> > as seen below create tablespace does not throw an error or appear to
> > do anything other than register the tablespace.
> >
> > postg...@db01:~> less /opt/pg/data/jnj_indexes/PG_VERSIO
On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian wrote:
> Dave Cramer wrote:
>> On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote:
>> > Dave Cramer writes:
>> >> as seen below create tablespace does not throw an error or appear to
>> >> do anything other than register the tablespace.
>> >
>> > I su
Dave Cramer wrote:
> On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote:
> > Dave Cramer writes:
> >> as seen below create tablespace does not throw an error or appear to
> >> do anything other than register the tablespace.
> >
> > I suspect this behavior is partially intentional, because tablespac
On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane wrote:
> Dave Cramer writes:
>> as seen below create tablespace does not throw an error or appear to
>> do anything other than register the tablespace.
>
> I suspect this behavior is partially intentional, because tablespace
> creation now involves an ex
Dave Cramer writes:
> as seen below create tablespace does not throw an error or appear to
> do anything other than register the tablespace.
I suspect this behavior is partially intentional, because tablespace
creation now involves an extra level of subdirectory. However, it's
not clear to me wh
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
> as seen below create tablespace does not throw an error or appear to
> do anything other than register the tablespace.
>
> postg...@db01:~> less /opt/pg/data/jnj_indexes/PG_VERSION
> 8.4
> postg...@db01:~> /opt/pg91
45 matches
Mail list logo
