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 un
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.
* 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/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
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
laten
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 p
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
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* pg_start_backup to tell t
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
* 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 anything, really). PG *will*
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.
> rsync notices file has differen
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 BASEDIR after pg_start
* 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 scenario here:
> >
> > Pos
* 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 anything, really). PG *will* c
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 Regards
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 function (Immutable and Vol
16 matches
Mail list logo
