On Tue, 2006-04-18 at 08:44 -0400, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > ?hel kenal p?eval, E, 2006-04-17 kell 17:14, kirjutas Bruce Momjian:
> > > Jim C. Nasby wrote:
> > > > Are you going to back-patch this? If I understand correctly current
> > > > behavior could mean people using PITR
Hannu Krosing wrote:
> ?hel kenal p?eval, E, 2006-04-17 kell 17:14, kirjutas Bruce Momjian:
> > Jim C. Nasby wrote:
> > > Are you going to back-patch this? If I understand correctly current
> > > behavior could mean people using PITR may have invalid backups. In the
> > > meantime, perhaps we shoul
Ühel kenal päeval, E, 2006-04-17 kell 17:14, kirjutas Bruce Momjian:
> Jim C. Nasby wrote:
> > Are you going to back-patch this? If I understand correctly current
> > behavior could mean people using PITR may have invalid backups. In the
> > meantime, perhaps we should send an email to -annouce rec
On Sun, 2006-04-16 at 16:44 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > It seems that we should write an API to allow a backup device to ask for
> > blocks from the database.
>
> I don't think we have the manpower or interest to develop and maintain
> our own backup tool
Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
> > > I've applied a patch for this. On reflection, the CHECKPOINT during
> > > pg_start_backup was actually necessary for torn-page safety even without
> > > full_page_writes off. The reason
Jim C. Nasby wrote:
> On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
> > I've applied a patch for this. On reflection, the CHECKPOINT during
> > pg_start_backup was actually necessary for torn-page safety even without
> > full_page_writes off. The reason is that the torn-page risk occu
On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
> I've applied a patch for this. On reflection, the CHECKPOINT during
> pg_start_backup was actually necessary for torn-page safety even without
> full_page_writes off. The reason is that the torn-page risk occurs when
> we write a page fr
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> If we were to do this, I'd want some more-bulletproof mechanism for
> >> forcing full_page_writes on during the backup. We could probably
> >> keep a "backup in progress" flag in shared memory, and examine that
> >> along with the G
Bruce Momjian writes:
> Tom Lane wrote:
>> If we were to do this, I'd want some more-bulletproof mechanism for
>> forcing full_page_writes on during the backup. We could probably
>> keep a "backup in progress" flag in shared memory, and examine that
>> along with the GUC variable before deciding
Tom Lane wrote:
> Bruce Momjian writes:
> > This is a much simpler fix than people talking about writing their own
> > backup programs.
>
> Well, it's still not exactly trivial. The hack that was being proposed
> involved having the admin manually do
>
> full_page_writes = ON (ie, edit co
Bruce Momjian writes:
> This is a much simpler fix than people talking about writing their own
> backup programs.
Well, it's still not exactly trivial. The hack that was being proposed
involved having the admin manually do
full_page_writes = ON (ie, edit config file and SIGHUP)
> Come to think of it, someone not too long ago was proposing an API to
> allow a 'PITR slave' to subscribe to a master for WAL segments/changes;
> it seems logical to me for that API to also provide the ability to send
> relation data as well.
Is that what replication is for?
Joshua D. Drake
-
Tom Lane wrote:
> Bruce Momjian writes:
> >> Think harder: we are only safe if the first write to a given page after
> >> it's mis-copied by the archiver is a full page write. The requirement
> >> therefore continues after pg_stop_backup. Unless you want to add
> >> infrastructure to keep track
Bruce Momjian writes:
>> Think harder: we are only safe if the first write to a given page after
>> it's mis-copied by the archiver is a full page write. The requirement
>> therefore continues after pg_stop_backup. Unless you want to add
>> infrastructure to keep track for *every page* in the DB
On Sun, Apr 16, 2006 at 04:44:50PM -0400, Tom Lane wrote:
> > It seems that we should write an API to allow a backup device to ask for
> > blocks from the database.
>
> I don't think we have the manpower or interest to develop and maintain
> our own backup tool --- or tools, actually, as you'd at
Bruce Momjian writes:
> > I am thinking we should throw an error on pg_start_backup() and
> > pg_stop_backup if full_page_writes is off.
>
> No, we'll just change the test in xlog.c so that fullPageWrites is
> ignored if XLogArchivingActive.
>
> > Seems archive_command and
> > full_page_writes c
Martijn van Oosterhout writes:
> I must be missing something obvious, but why don't we compress the
> xlogs? They appear to be quite compressable (>75%) with standard gzip...
Might be worth experimenting with, but I'm a bit dubious. We've seen
several tests showing that XLogInsert's calculation
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2006-04-15 at 11:45 -0400, Tom Lane wrote:
>> No, we'll just change the test in xlog.c so that fullPageWrites is
>> ignored if XLogArchivingActive.
> I can see the danger of which you speak, but does it necessarily apply
> to all forms of backup?
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But if we do need to consider the kernel-level behaviour mentioned, then
> the whole PITR thing becomes an impossibility. Consider the case when we
> get a torn page during the initial copy with tar/cpio/rsync/whatever,
> and no WAL record updates it.
Th
Ühel kenal päeval, P, 2006-04-16 kell 11:31, kirjutas Tom Lane:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > So we should probably document that rsync is only working solution.
>
> No, we're just turning off the variable. One experiment on one version
> of rsync doesn't prove it's "safe", even
On Sat, Apr 15, 2006 at 01:31:58PM +0300, Hannu Krosing wrote:
> > (No, I don't think tar's blocksize options control this
> > necessarily --- those indicate the blocking factor on the *tape*.
> > And not everyone uses tar anyway.)
>
> If I'm desperate enough to get the 2x reduction of WAL writes,
On Sat, 2006-04-15 at 11:45 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should throw an error on pg_start_backup() and
> > pg_stop_backup if full_page_writes is off.
>
> No, we'll just change the test in xlog.c so that fullPageWrites is
> ignored if XLogArchivingActive.
I
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> So we should probably document that rsync is only working solution.
No, we're just turning off the variable. One experiment on one version
of rsync doesn't prove it's "safe", even if there weren't the kernel-
behavior issue to consider.
On 4/16/06, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > I guess that writing our own pg_tar, which cooperates with postgres
> > backends to get full pages, is still in the realm of possible things,
> > even on kernels which dont guarantee atomic visibility of write() calls.
> >
> > But until s
Hannu Krosing wrote:
> ?hel kenal p?eval, L, 2006-04-15 kell 11:49, kirjutas Tom Lane:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > If I'm desperate enough to get the 2x reduction of WAL writes, I may
> > > even write my own backup solution.
> >
> > Given Florian's concern, sounds like you
Ühel kenal päeval, L, 2006-04-15 kell 11:49, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If I'm desperate enough to get the 2x reduction of WAL writes, I may
> > even write my own backup solution.
>
> Given Florian's concern, sounds like you might have to write your own
> ke
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should throw an error on pg_start_backup() and
> > pg_stop_backup if full_page_writes is off.
>
> No, we'll just change the test in xlog.c so that fullPageWrites is
> ignored if XLogArchivingActive.
We should probably throw a LOG messa
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If I'm desperate enough to get the 2x reduction of WAL writes, I may
> even write my own backup solution.
Given Florian's concern, sounds like you might have to write your own
kernel too. In which case, generating a variant build of Postgres
that allows
Bruce Momjian writes:
> I am thinking we should throw an error on pg_start_backup() and
> pg_stop_backup if full_page_writes is off.
No, we'll just change the test in xlog.c so that fullPageWrites is
ignored if XLogArchivingActive.
> Seems archive_command and
> full_page_writes can still be used
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > ??hel kenal p??eval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
> >> If the backup-taker reads, say, 4K at a time then it's
> >> certainly possible that it gets a later version of the second half of a
> >> page than it got of the fir
Ühel kenal päeval, R, 2006-04-14 kell 17:31, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Ühel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
> >> If the backup-taker reads, say, 4K at a time then it's
> >> certainly possible that it gets a later version of the sec
* Tom Lane:
> I think we had originally argued that there was no problem anyway
> because the kernel should cause the page write to appear atomic to other
> processes (since we issue it in a single write() command).
I doubt Linux makes any such guarantees. See this recent thread on
linux-kernel:
Quoting Tom Lane <[EMAIL PROTECTED]>:
> I fear we still have to disable full_page_writes (force it ON) if
> XLogArchivingActive is on. Comments?
Yeah - if you are enabling PITR, then you care about safety and integrity, so it
makes sense (well, to me anyway).
Cheers
Mark
---
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
>> If the backup-taker reads, say, 4K at a time then it's
>> certainly possible that it gets a later version of the second half of a
>> page than it got of the first half. I don't know abo
Ühel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
> I think we had originally argued that there was no problem anyway
> because the kernel should cause the page write to appear atomic to other
> processes (since we issue it in a single write() command). But that's
> only true if the
35 matches
Mail list logo
