Lists: | pgsql-committerspgsql-hackers |
---|
From: | momjian(at)svr1(dot)postgresql(dot)org (Bruce Momjian) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Remove: * Allow database recovery where tablespaces can't be |
Date: | 2004-11-06 05:38:35 |
Message-ID: | [email protected] |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Log Message:
-----------
Remove:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.
Modified Files:
--------------
pgsql/doc:
TODO (r1.1385 -> r1.1386)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386)
From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Bruce Momjian <momjian(at)svr1(dot)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Remove: * Allow database recovery where |
Date: | 2004-11-08 15:21:00 |
Message-ID: | [email protected] |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Just curious, but in what sort of circumstance could this happen?
Permissions problems, that sort of thing?
On Sat, 6 Nov 2004, Bruce Momjian wrote:
> Log Message:
> -----------
> Remove:
>
> * Allow database recovery where tablespaces can't be created
>
> When a pg_dump is restored, all tablespaces will attempt to be created
> in their original locations. If this fails, the user must be able to
> adjust the restore process.
>
> Modified Files:
> --------------
> pgsql/doc:
> TODO (r1.1385 -> r1.1386)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | Bruce Momjian <momjian(at)svr1(dot)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Remove: * Allow database recovery |
Date: | 2004-11-08 15:39:31 |
Message-ID: | [email protected] |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Marc G. Fournier wrote:
>
> Just curious, but in what sort of circumstance could this happen?
> Permissions problems, that sort of thing?
Restoring a dump to another system that doesn't have the same
directories to create the tablespaces.
---------------------------------------------------------------------------
>
> On Sat, 6 Nov 2004, Bruce Momjian wrote:
>
> > Log Message:
> > -----------
> > Remove:
> >
> > * Allow database recovery where tablespaces can't be created
> >
> > When a pg_dump is restored, all tablespaces will attempt to be created
> > in their original locations. If this fails, the user must be able to
> > adjust the restore process.
> >
> > Modified Files:
> > --------------
> > pgsql/doc:
> > TODO (r1.1385 -> r1.1386)
> > (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386)
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Remove: * Allow database recovery |
Date: | 2004-11-08 16:42:06 |
Message-ID: | [email protected] |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
On Mon, 8 Nov 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
>>
>> Just curious, but in what sort of circumstance could this happen?
>> Permissions problems, that sort of thing?
>
> Restoring a dump to another system that doesn't have the same
> directories to create the tablespaces.
'k, that's what I thought, just wanted to clarify ... stupid question then
... if such a case happens, do we send a WARNING to let ppl know that the
load didn't quite go as the dump went?
>
> ---------------------------------------------------------------------------
>
>>
>> On Sat, 6 Nov 2004, Bruce Momjian wrote:
>>
>>> Log Message:
>>> -----------
>>> Remove:
>>>
>>> * Allow database recovery where tablespaces can't be created
>>>
>>> When a pg_dump is restored, all tablespaces will attempt to be created
>>> in their original locations. If this fails, the user must be able to
>>> adjust the restore process.
>>>
>>> Modified Files:
>>> --------------
>>> pgsql/doc:
>>> TODO (r1.1385 -> r1.1386)
>>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386)
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 4: Don't 'kill -9' the postmaster
>>>
>>
>> ----
>> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
>> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 3: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>> message can get through to the mailing list cleanly
>>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Remove: * Allow database recovery |
Date: | 2004-11-08 16:48:04 |
Message-ID: | [email protected] |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Marc G. Fournier wrote:
> On Mon, 8 Nov 2004, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >>
> >> Just curious, but in what sort of circumstance could this happen?
> >> Permissions problems, that sort of thing?
> >
> > Restoring a dump to another system that doesn't have the same
> > directories to create the tablespaces.
>
> 'k, that's what I thought, just wanted to clarify ... stupid question then
> ... if such a case happens, do we send a WARNING to let ppl know that the
> load didn't quite go as the dump went?
Yes, they get a warning because the tablespace create failed. When we
had a TABLESPACE clause in create (before default_tablespace), all the
CREATEs would fail leading to a useless restore.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073