Tom Lane wrote:
> "J. R. Nield" <[EMAIL PROTECTED]> writes:
> >> Uh, why? Why not just force a checkpoint and remember the exact
> >> location of the checkpoint within the current log file?
>
> > If I do a backup with PITR and save it to tape, I need to be able to
> > restore it even if my machi
"J. R. Nield" <[EMAIL PROTECTED]> writes:
>> Uh, why? Why not just force a checkpoint and remember the exact
>> location of the checkpoint within the current log file?
> If I do a backup with PITR and save it to tape, I need to be able to
> restore it even if my machine is destroyed in a fire, a
On Wed, 2002-08-07 at 23:41, Tom Lane wrote:
> "J. R. Nield" <[EMAIL PROTECTED]> writes:
> > The xlog code must allow us to force an advance to the next log file,
> > and truncate the archived file when it's copied so as not to waste
> > space.
>
> Uh, why? Why not just force a checkpoint and re
Sounds like a win all around; make PITR easier and temp tables faster.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > There is debate on whether the local buffers are even valuable
> > considering the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> There is debate on whether the local buffers are even valuable
> considering the headache they cause in other parts of the system.
More specifically, the issue is that when (if) you commit, the contents
of the new table now have to be pushed out to shar
Christopher Kings-Lynne wrote:
> > The main area where it seems to get heavy use is during index builds,
> > and for 'CREATE TABLE AS SELECT...'.
> >
> > So I will remove the local buffer manager as part of the PITR patch,
> > unless there is further objection.
>
> Would someone mind filling me i
> The main area where it seems to get heavy use is during index builds,
> and for 'CREATE TABLE AS SELECT...'.
>
> So I will remove the local buffer manager as part of the PITR patch,
> unless there is further objection.
Would someone mind filling me in as to what the local bugger manager is and
> > Well, PITR without log archiving could be alternative to
> > pg_dump/pg_restore, but I agreed that it's not the big
> > feature to worry about.
>
> Seems like a pointless "feature" to me. A pg_dump dump serves just
> as well to capture a snapshot --- in fact better, since it's likely
> small
Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> It should be sufficient to force a checkpoint when you
> >> start and when you're done --- altering normal operation in between is
> >> a bad design.
>
> > But you have to prevent log files reusing while you copy data files.
>
>
> >> It should be sufficient to force a checkpoint when you
> >> start and when you're done --- altering normal operation
> in between is
> >> a bad design.
>
> > But you have to prevent log files reusing while you copy data files.
>
> No, I don't think so. If you are using PITR then you presu
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> It should be sufficient to force a checkpoint when you
>> start and when you're done --- altering normal operation in between is
>> a bad design.
> But you have to prevent log files reusing while you copy data files.
No, I don't think so. If you a
> I really dislike the notion of turning off checkpointing. What if the
> backup process dies or gets stuck (eg, it's waiting for some
> operator to
> change a tape, but the operator has gone to lunch)? IMHO, backup
> systems that depend on breaking the system's normal
> operational behavior
>
> So I think what will work then is pg_copy (hot backup) would:
> 1) Issue an ALTER SYSTEM BEGIN BACKUP command which turns on
> atomic write,
> checkpoints the database and disables further checkpoints (so
> wal files
> won't be reused) until the backup is complete.
> 2) Change ALTER SYSTEM BAC
Richard Tucker <[EMAIL PROTECTED]> writes:
> 1) Issue an ALTER SYSTEM BEGIN BACKUP command which turns on atomic write,
> checkpoints the database and disables further checkpoints (so wal files
> won't be reused) until the backup is complete.
> 2) Change ALTER SYSTEM BACKUP DATABASE TO read the d
> Are you sure this is true for all ports?
Well, maybe you're right and it's not.
But with "after-image blocks in log after checkpoint"
you really shouldn't worry about block atomicity, right?
And ability to turn blocks logging on/off, as suggested
by Richard, looks as appropriate for everyone, ?
Are you sure this is true for all ports? And if so, why would it be
cheaper for the kernel to do it in its buffer manager, compared to us
doing it in ours? This just seems bogus to rely on. Does anyone know
what POSIX has to say about this?
On Fri, 2002-08-02 at 18:01, Mikheev, Vadim wrote:
> >
> > > As long as whole block is saved in log on first after
> > > checkpoint (you made before backup) change to block.
> >
> I thought half the point of PITR was to be able to
> turn off pre-image logging so you can trade potential
> recovery time for speed without fear of data-loss.
> Didn't we h
> > How do you get atomic block copies otherwise?
>
> Eh? The kernel does that for you, as long as you're reading the
> same-size blocks that the backends are writing, no?
Good point.
Vadim
---(end of broadcast)---
TIP 2: you can get off all lis
> > You don't need it.
> > As long as whole block is saved in log on first after
> > checkpoint (you made before backup) change to block.
>
> I thought half the point of PITR was to be able to turn
> off pre-image logging so you can trade potential recovery
Correction - *after*-image.
> time fo
> > So, we only have to use shared buffer pool for local (but probably
> > not for temporary) relations to close this issue, yes? I personally
> > don't see any performance issues if we do this.
>
> Hmm. Temporary relations are a whole different story.
>
> It would be nice if updates on temp re
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> So, we only have to use shared buffer pool for local (but probably
> not for temporary) relations to close this issue, yes? I personally
> don't see any performance issues if we do this.
Hmm. Temporary relations are a whole different story.
It woul
"J. R. Nield" <[EMAIL PROTECTED]> writes:
>> (In particular, I *strongly* object to using the buffer manager at all
>> for reading files for backup. That's pretty much guaranteed to blow out
>> buffer cache. Use plain OS-level file reads. An OS directory search
>> will do fine for finding what
On Fri, 2002-08-02 at 16:59, Mikheev, Vadim wrote:
> You don't need it.
> As long as whole block is saved in log on first after
> checkpoint (you made before backup) change to block.
I thought half the point of PITR was to be able to turn off pre-image
logging so you can trade potential recovery
> > (In particular, I *strongly* object to using the buffer
> manager at all
> > for reading files for backup. That's pretty much
> guaranteed to blow out
> > buffer cache. Use plain OS-level file reads. An OS
> directory search
> > will do fine for finding what you need to read, too.)
>
>
> > The predicate for files we MUST (fuzzy) copy is:
> > File exists at start of backup && File exists at end of backup
>
> Right, which seems to me to negate all these claims about needing a
> (horribly messy) way to read uncommitted system catalog entries, do
> blind reads, etc. What's wron
On Fri, 2002-08-02 at 16:01, Tom Lane wrote:
> "J. R. Nield" <[EMAIL PROTECTED]> writes:
> > The predicate for files we MUST (fuzzy) copy is:
> > File exists at start of backup && File exists at end of backup
>
> Right, which seems to me to negate all these claims about needing a
> (horribly m
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> The predicate for files we MUST (fuzzy) copy is:
> File exists at start of backup && File exists at end of backup
Right, which seems to me to negate all these claims about needing a
(horribly messy) way to read uncommitted system catalog entries, do
On Fri, 2002-08-02 at 13:50, Richard Tucker wrote:
> pg_copy does not handle "local relations" as you would suspect. To find the
> tables and indexes to backup the backend in processing the "ALTER SYSTEM
> BACKUP" statement reads the pg_class table. Any tables in the process of
> coming into exi
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> What would happen if a transaction with a local relation commits during
> backup, and there are log entries inserting the catalog tuples into
> pg_class. Should I not apply those on restore? How do I know?
This is certainly a non-problem. You see a WAL
On Fri, 2002-08-02 at 10:01, Tom Lane wrote:
>
> Just out of curiosity, though, what does it matter? On re-reading your
> message I think you are dealing with a non problem, or at least the
> wrong problem. Local relations do not need to be checkpointed, because
> by definition they were create
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> Ok. This is what I wanted to hear, but I had assumed someone decided to
> put it in for a reason, and I wasn't going to submit a patch to pull-out
> the local buffer manager without clearing it first.
> The main area where it seems to get heavy use is d
Ok. This is what I wanted to hear, but I had assumed someone decided to
put it in for a reason, and I wasn't going to submit a patch to pull-out
the local buffer manager without clearing it first.
The main area where it seems to get heavy use is during index builds,
and for 'CREATE TABLE AS SELEC
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> I am working on a way to do this with a signal, using holdoffs around
> calls into the storage-manager and VFS layers to prevent re-entrant
> calls. The local buffer manager is simple enough that it should be
> possible to flush them from within a signal
On Thu, 2002-08-01 at 17:14, Bruce Momjian wrote:
>
> J.R needs comments on this. PITR has problems because local relations
> aren't logged to WAL. Suggestions?
>
I'm sorry if it wasn't clear. The issue is not that local relations
aren't logged to WAL, they are. The issue is that you can't che
J.R needs comments on this. PITR has problems because local relations
aren't logged to WAL. Suggestions?
---
J. R. Nield wrote:
> As per earlier discussion, I'm working on the hot backup issues as part
> of the PITR suppo
As per earlier discussion, I'm working on the hot backup issues as part
of the PITR support. While I was looking at the buffer manager and the
relcache/MyDb issues to figure out the best way to work this, it
occurred to me that PITR will introduce a big problem with the way we
handle local relatio
36 matches
Mail list logo
