Обсуждение: about and feature matrix on site
both about and feature matrix on site should contain the critical feature that the db files can be backed up since they do not mod the fs under the hood like other DBMS. this is very important for me.
On 2016-06-20 5:23 PM, Jim Michaels wrote: > both about and feature matrix on site should contain the critical > feature that the db files can be backed up since they do not mod the fs > under the hood like other DBMS. this is very important for me. Huh? You can ABSOLUTELY NOT take backups of postgres that way. .m
Marko Tiikkaja wrote: > On 2016-06-20 5:23 PM, Jim Michaels wrote: > >both about and feature matrix on site should contain the critical > >feature that the db files can be backed up since they do not mod the fs > >under the hood like other DBMS. this is very important for me. > > Huh? You can ABSOLUTELY NOT take backups of postgres that way. Actually you can, as long as the server is stopped. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6/20/2016 8:48 AM, Alvaro Herrera wrote:
> Marko Tiikkaja wrote:
>> >On 2016-06-20 5:23 PM, Jim Michaels wrote:
>>> > >both about and feature matrix on site should contain the critical
>>> > >feature that the db files can be backed up since they do not mod the fs
>>> > >under the hood like other DBMS. this is very important for me.
>> >
>> >Huh? You can ABSOLUTELY NOT take backups of postgres that way.
> Actually you can, as long as the server is stopped.
or if you bracket the backup with pg_{start,stop}_backup() calls...
--
john r pierce, recycling bits in santa cruz
On Mon, Jun 20, 2016 at 09:07:22AM -0700, John R Pierce wrote:
> On 6/20/2016 8:48 AM, Alvaro Herrera wrote:
>
> Marko Tiikkaja wrote:
>
> > On 2016-06-20 5:23 PM, Jim Michaels wrote:
>
> > >both about and feature matrix on site should contain the critical
> > >feature that the db files can be backed up since they do not mod the fs
> > >under the hood like other DBMS. this is very important for me.
>
> >
> > Huh? You can ABSOLUTELY NOT take backups of postgres that way.
>
> Actually you can, as long as the server is stopped.
>
>
> or if you bracket the backup with pg_{start,stop}_backup() calls...
And have all the WAL files used during the backup, and do PITR restore.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Q: does pgsql create data files using the filesystem and OS API, or does it try to write directly into NTFS without using the API? because if it uses the API, I can down the server and back it up as an alternative, check the fs, etc. On 6/20/2016 8:48 AM, Alvaro Herrera wrote: > Marko Tiikkaja wrote: >> On 2016-06-20 5:23 PM, Jim Michaels wrote: >>> both about and feature matrix on site should contain the critical >>> feature that the db files can be backed up since they do not mod the fs >>> under the hood like other DBMS. this is very important for me. >> Huh? You can ABSOLUTELY NOT take backups of postgres that way. > Actually you can, as long as the server is stopped. >
On Wed, Jun 22, 2016 at 11:06:36PM -0700, Jim Michaels wrote: > Q: does pgsql create data files using the filesystem and OS API, or does it > try to write directly into NTFS without using the API? because if it uses > the API, I can down the server and back it up as an alternative, check the > fs, etc. Yes, that is useful, but honestly, few people ask about it, and more people ask if we support raw devices, which is the opposite of this, so I don't see how adding it as a features makes sense. --------------------------------------------------------------------------- > > > On 6/20/2016 8:48 AM, Alvaro Herrera wrote: > >Marko Tiikkaja wrote: > >>On 2016-06-20 5:23 PM, Jim Michaels wrote: > >>>both about and feature matrix on site should contain the critical > >>>feature that the db files can be backed up since they do not mod the fs > >>>under the hood like other DBMS. this is very important for me. > >>Huh? You can ABSOLUTELY NOT take backups of postgres that way. > >Actually you can, as long as the server is stopped. > > > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Jim Michaels wrote: > Q: does pgsql create data files using the filesystem and OS API, or does it > try to write directly into NTFS without using the API? We don't write to the FS directly, and I don't think we would change that any time soon. > because if it uses the API, I can down the server and back it up as an > alternative, check the fs, etc. Yes, you can do that and it works fine. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Bruce Momjian wrote: > On Wed, Jun 22, 2016 at 11:06:36PM -0700, Jim Michaels wrote: > > Q: does pgsql create data files using the filesystem and OS API, or does it > > try to write directly into NTFS without using the API? because if it uses > > the API, I can down the server and back it up as an alternative, check the > > fs, etc. > > Yes, that is useful, but honestly, few people ask about it, and more > people ask if we support raw devices, which is the opposite of this, so > I don't see how adding it as a features makes sense. Few people ask about this because it already exists, I suppose. I don't think we're likely to add raw device support any time soon. I don't know of anyone working in that direction. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services