On Fri, May 11, 2012 at 10:03 PM, Tom Lane wrote:
>
> Well, the question to me is exactly how much good it will do to stop
> deletion of the pg_tablespace entry, if the underlying files are gone.
> I'm having a hard time getting excited about expending cycles on that.
>
There could be multiple r
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of vie may 11 20:28:28 -0400 2012:
>> I'm astonished we don't do that already. Seems inconsistent with
>> other SQL object types - most obviously, schemas - and a potentially
>> giant foot-gun.
> The original patch did contain tablespa
Excerpts from Robert Haas's message of vie may 11 20:28:28 -0400 2012:
> On Fri, May 11, 2012 at 7:55 PM, Tom Lane wrote:
> > A larger question is whether we should start making pg_shdepend entries
> > for table/index usage of non-default tablespaces, so that you couldn't
> > DROP a tablespace th
On Fri, May 11, 2012 at 7:55 PM, Tom Lane wrote:
> A larger question is whether we should start making pg_shdepend entries
> for table/index usage of non-default tablespaces, so that you couldn't
> DROP a tablespace that the catalogs think still has tables/indexes in
> it.
I'm astonished we don't
"Albe Laurenz" writes:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
> Right. That's strange.
> Usually OIDs get incremented, so you shouldn't end up
On 5/11/12, Michael Nolan wrote:
> On 5/11/12, Albe Laurenz wrote:
>> Michael Nolan wrote:
>>> I see one potential difference between your results and mine.
>>>
>>> When I rebuild the tablespace, I wind up with the same filename/OID as
>>> before, I'm not sure you do.
>>
>> Right. That's strange.
On 5/11/12, Albe Laurenz wrote:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>>
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
>
> Right. That's strange.
> Usually OIDs get incremented, so you sho
Michael Nolan wrote:
> I see one potential difference between your results and mine.
>
> When I rebuild the tablespace, I wind up with the same filename/OID as
> before, I'm not sure you do.
Right. That's strange.
Usually OIDs get incremented, so you shouldn't end up with the same
OID for the new
I see one potential difference between your results and mine.
When I rebuild the tablespace, I wind up with the same filename/OID as
before, I'm not sure you do.
--
Mike Nolan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On 5/9/12, Albe Laurenz wrote:
> I cannot reproduce this on 9.1.3:
Odd, I've tried it another two times, with similar results to my initial post.
Here's what I get starting with the point where I deleted the files in
the tablespace:
mytest=# select * from mytable;
select * from mytable;
ERROR:
Michael Nolan wrote:
> While researching a problem reported on the -general list by a user
who lost a disk containing his
> index tablespace, I ran into something, but I'm not sure is a serious
bug or just an inconsistency in
> how \d shows tables.
>
> Here are the steps I took.
>
> 1. Create a
The last portion of my original post got edited out by mistake.
The tests I ran were on version 9.1.3, running Fedora 14, kernel
2.6.35.14-106.fc14-i686.
It seems to me that DROP TABLESPACE should check to see if there are
references in the system catalog to the tablespace before dropping it, not
While researching a problem reported on the -general list by a user who
lost a disk containing his index tablespace, I ran into something, but I'm
not sure is a serious bug or just an inconsistency in how \d shows tables.
Here are the steps I took.
1. Create a new database 'MYDB' and connect to
13 matches
Mail list logo
