On 26/09/17 20:44, Mark Kirkwood wrote:
$ pg_basebackup -D .
WARNING: could not read symbolic link "pg_tblspc/space1": Invalid
argument
pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists
but is not empty
pg_basebackup: removing contents of data directory "."
Err - actua
On 29/04/15 09:35, Bruce Momjian wrote:
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
This way, both pg_dump and pg_upgrade will issue warnings, though, of
course, those warnings can be ignored. I am hopeful these two warnings
will be sufficient and we will not need make these
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
> This way, both pg_dump and pg_upgrade will issue warnings, though, of
> course, those warnings can be ignored. I am hopeful these two warnings
> will be sufficient and we will not need make these errors, with the
> possible inconveni
On Wed, Apr 22, 2015 at 10:41:02PM -0400, Bruce Momjian wrote:
> > josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xlog/';
> > CREATE TABLESPACE
> >
> > It really seems like we ought to block *THAT*. Of course, if we block
> > tablespace creation in PGDATA generally, then that's c
On Thu, Apr 23, 2015 at 4:30 PM, Andres Freund wrote:
> On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
>> But pg_upgrade automates all that, so you can't use pg_upgrade in that
>> case. If we add a GUC as I suggested, you can still use pg_upgrade.
>
> But we also have to live with data director
On 4/23/15 4:30 PM, Andres Freund wrote:
> On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
>> But pg_upgrade automates all that, so you can't use pg_upgrade in that
>> case. If we add a GUC as I suggested, you can still use pg_upgrade.
>
> But we also have to live with data directories being in
On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
> But pg_upgrade automates all that, so you can't use pg_upgrade in that
> case. If we add a GUC as I suggested, you can still use pg_upgrade.
But we also have to live with data directories being in a shit state
forever onward. We won't really be a
On Thu, Apr 23, 2015 at 3:57 PM, Andres Freund wrote:
> On 2015-04-23 15:46:20 -0400, Robert Haas wrote:
>> Well, we've made backward-incompatible changes before. Not to this
>> specific thing, but in general. I don't think there's anything
>> preventing us from doing so here, except that we don
On 2015-04-23 15:17:55 -0500, Jim Nasby wrote:
> Yes, but only after creating a brand new cluster from scratch, which would
> then disallow them from putting tablespaces in $PGDATA.
pg_dumpall output includes tablespaces.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 4/23/15 11:01 AM, Andres Freund wrote:
On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby
wrote:
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so people can use pg_upgrade the
On 2015-04-23 15:46:20 -0400, Robert Haas wrote:
> Well, we've made backward-incompatible changes before. Not to this
> specific thing, but in general. I don't think there's anything
> preventing us from doing so here, except that we don't want to annoy
> too many users.
I think the number of us
On Thu, Apr 23, 2015 at 11:00 AM, Bruce Momjian wrote:
>> > I have developed the attached patch to warn about creating tablespaces
>> > inside the data directory. The case this doesn't catch is referencing a
>> > symbolic link that points to the same directory. We can't make it an
>> > error so
On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby
wrote:
>On 4/22/15 9:41 PM, Bruce Momjian wrote:
>> The case this doesn't catch is referencing a
>> symbolic link that points to the same directory. We can't make it an
>> error so people can use pg_upgrade these setups.
>
>Couldn't we make it an
On Thu, Apr 23, 2015 at 05:05:14PM +0200, Andres Freund wrote:
> On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
> > On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> > > I think this is a good thing to do, but I sure wish we could go
> > > further and block it completely. That may
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so people can use pg_upgrade these setups.
Couldn't we make it an ERROR unless IsBinaryUpgrade?
--
Jim Nasby, Data Architect, Blue Tr
On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
> On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> > I think this is a good thing to do, but I sure wish we could go
> > further and block it completely. That may require more thought than
> > we have time to put in at this stage of
On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian wrote:
> >> What is a real problem is that we don't block creating tablespaces
> >> anywhere at all, including in obviously problematic places like the
> >> transaction log directory:
> >
On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian wrote:
>> What is a real problem is that we don't block creating tablespaces
>> anywhere at all, including in obviously problematic places like the
>> transaction log directory:
>>
>> josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xl
On Fri, Jan 30, 2015 at 01:26:22PM -0800, Josh Berkus wrote:
> Robert, Stephen, etc.:
>
> Apparently you can create a tablespace in the tablespace directory:
>
> josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
> CREATE TABLESPACE
> josh=# create table test_tbl ( test text
> it is just as likely they simply are not aware
> of the downsides and the only reason they put it is $PGDATA is that
> it seemed like a logical place to put a directory that is intended to hold
> database data.
Yes, this is the reason why we got in this issue. The name PGDATA is misleading.
> T
Robert, Stephen, etc.:
Apparently you can create a tablespace in the tablespace directory:
josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
CREATE TABLESPACE
josh=# create table test_tbl ( test text ) tablespace tbl;
CREATE TABLE
josh=# \q
josh@Radegast:~/pg94/data/pg_tbls
On 01/30/2015 09:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Given all this, it seems like a good idea to at least give a warning
>> if somebody tries to create a tablespace instead the data directory.
>
> A warning seems like a good idea. I actually thought we *
Robert Haas wrote
> Arguably, we should prohibit it altogether, but there are obviously
> people that want to do it, and there could even be somewhat valid
> reasons for that,
Lots of hand-waving here and it is just as likely they simply are not aware
of the downsides and the only reason they put
* Robert Haas (robertmh...@gmail.com) wrote:
> Given all this, it seems like a good idea to at least give a warning
> if somebody tries to create a tablespace instead the data directory.
A warning seems like a good idea. I actually thought we *did* prevent
it..
> Arguably, we should prohibit it
On 1/30/15 11:43 AM, Joshua D. Drake wrote:
> On 01/30/2015 08:19 AM, Bruce Momjian wrote:
>>
>> On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
>>> I think everyone who has read this mailing list for a while is
>>> probably already aware of this problem. When you create a tablespace
On Fri, Jan 30, 2015 at 11:43 AM, Joshua D. Drake
wrote:
> I mean yes a warning is good but it is after the fact, the tablespace is
> already created. We know that tablespaces in $PGDATA are a bad idea, why not
> protect the user?
Please go back and read the discussion of that option in the OP.
On 01/30/2015 08:19 AM, Bruce Momjian wrote:
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things happe
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
> I think everyone who has read this mailing list for a while is
> probably already aware of this problem. When you create a tablespace
> somewhere inside the data directory, weird things happen. If you
> pg_upgrade and then incautiously
28 matches
Mail list logo
