On Mon, Jan 23, 2017 at 9:10 AM, Jim Nasby wrote:
> On 1/18/17 6:09 PM, David G. Johnston wrote:
>>
>> That would not be a productive exercise for me, or most people who just
>> want
>> some idea of what to expect in terms of behavior when they write and use a
>> Stable
Dear Jeff,
Thanks for the correction and by this email, we hope that myth has gone
forever :)
Will do that to inform other about this matter.
And agree with all of us here that: using pg_basebackup is the best
approach rather than do it manually through pg_start_backup, right?
Thanks and
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 23 January 2017 at 17:12, Jeff Janes wrote:
> >> Just to make sure anyone reading the mailing list archives isn't
> >> confused, running pg_start_backup does *not* make PG stop writing to
> >> BASEDIR (or DATADIR, or
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> On Mon, Jan 23, 2017 at 7:28 AM, Jim Nasby wrote:
> > On 1/22/17 11:32 AM, Stephen Frost wrote:
> >> The 1-second window concern is regarding the validity of a subsequent
> >> incremental backup.
> >
> > BTW, there's a simpler
On 23 January 2017 at 17:12, Jeff Janes wrote:
>> Just to make sure anyone reading the mailing list archives isn't
>> confused, running pg_start_backup does *not* make PG stop writing to
>> BASEDIR (or DATADIR, or anything, really). PG *will* continue to write
>> data into
On Mon, Jan 23, 2017 at 7:28 AM, Jim Nasby wrote:
> On 1/22/17 11:32 AM, Stephen Frost wrote:
>
>> The 1-second window concern is regarding the validity of a subsequent
>> incremental backup.
>>
>
> BTW, there's a simpler scenario here:
>
> Postgres touches file.
>
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost wrote:
> > Just to make sure anyone reading the mailing list archives isn't
> > confused, running pg_start_backup does *not* make PG stop writing to
> > BASEDIR (or DATADIR, or
Greetings,
* Torsten Zuehlsdorff (mailingli...@toco-domains.de) wrote:
> I just have around 11 TB but switched to ZFS based backups only. I'm
> using snapshots therefore which gives some flexibility. I can
> rolback them, i can just clone it and work with a full copy as a
> different cluster (and
On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost wrote:
> Greetings,
>
> * julyanto SUTANDANG (julya...@equnix.co.id) wrote:
> > CORRECTION:
> >
> > "you might you pg_start_backup to tell the server not to write into the
> > DATADIR"
> >
> > become
> >
> > "you might *use*
Hello,
Increments in pgbackrest are done on file level which is not really
efficient. We have done parallelism, compression and page-level
increments (9.3+) in barman fork [1], but unfortunately guys from
2ndquadrant-it don’t hurry to work on it.
We're looking at page-level incremental backup
Hi All,
I have two servers. On the first one I have postgresql version 9.6 . On the
second one I have version 9.3 . I ran pgbench on both servers.
First server results:
scaling factor: 10
query mode: simple
number of clients: 1
number of threads: 1
duration: 10 s
number of transactions actually
On 1/23/17 9:27 AM, Stephen Frost wrote:
If you want my 2c on that, running with BLKSZ <> 8192 is playing with
fire, or at least running with scissors.
I've never seen it myself, but I'm under the impression that it's not
unheard of for OLAP environments. Given how sensitive PG is to IO
On 1/22/17 11:32 AM, Stephen Frost wrote:
The 1-second window concern is regarding the validity of a subsequent
incremental backup.
BTW, there's a simpler scenario here:
Postgres touches file.
rsync notices file has different timestamp, starts copying.
Postgres touches file again.
If those 3
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 1/20/17 9:06 AM, Stephen Frost wrote:
> >All the pages are the same size, so I'm surprised you didn't consider
> >just having a format along the lines of: magic+offset+page,
> >magic+offset+page, magic+offset+page, etc...
>
> Keep in mind that if
On 1/20/17 9:06 AM, Stephen Frost wrote:
All the pages are the same size, so I'm surprised you didn't consider
just having a format along the lines of: magic+offset+page,
magic+offset+page, magic+offset+page, etc...
Keep in mind that if you go that route you need to accommodate BLKSZ <>
8192.
On 1/18/17 6:09 PM, David G. Johnston wrote:
That would not be a productive exercise for me, or most people who just
want
some idea of what to expect in terms of behavior when they write and use a
Stable function (Immutable and Volatile seem fairly easy to reason about).
Yeah, this isn't an
16 matches
Mail list logo