> > Is there a way to start with yesterday's dump and load each transaction
> > log dump in order until you have a complete restore of the database?
WAL based BAR is not implemented in 7.1
Try to use Rserv from 7.1' contrib - it generates consistent incremental
snapshots.
> Also, does a pg_dump
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I have to say that I'm going to change on-disk database/table/index
> >> file names to _OID_! This is required by WAL because of inside of
> >> log records there will be just database/table/index oids, not names,
> >> and after cr
Bruce Momjian wrote:
>
> > >
> > > Wow, that is a major pain. Anyone else think so?
> >
> > Why it's so painful?
> > We can write utility to construct database dir with table names
> > symlinked to real table files -:)
> > Actually, I don't understand
> > for what would you need to know what is
Bruce Momjian wrote:
>
> > I have to say that I'm going to change on-disk database/table/index
> > file names to _OID_! This is required by WAL because of inside of
> > log records there will be just database/table/index oids, not names,
> > and after crash recovery will not be able to read pg_cl
Mike Mascari wrote:
>
> Will that aid in fixing a problem such as this:
>
> session 1:
>
> CREATE TABLE example1(value int4);
> BEGIN;
>
> session 2:
>
> BEGIN;
> ALTER TABLE example1 RENAME TO example2;
>
> session 1:
>
> INSERT INTO example1 VALUES (1);
> END;
> NOTICE: Abort Transaction
Bruce Momjian wrote:
>
> > if PostgreSQL could successfully rollback DDL statements sanely (and thus
> > diverge from ORACLE). I guess I don't expect that to happen successfully
> > until
> > something the equivalent of TABLESPACES is implemented and there is a
> > disassociation between table na
V Krishnaraj wrote:
>
> After a few times, there lots of messages are spewed out in the postgres
> server log. A typical message looks like this.
> NOTICE: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend died abnormally a
> nd possibly corrupted shared me
V Krishnaraj wrote:
>
> This application works fine when we are in single user. When we
> go into multi-user, the app has concurrency problems.
>
> The application has a sql query and updates onto the base table in
> the sql query. We are using Select FOR UPDATE to open the
> cursor and multiple
Marcin Inkielman wrote:
>
> I 'm using :
>
> LOCK <> IN ACCESS EXCLUSIVE MODE;
^^
This blocks concurrent read access - is it what you really want?
> to control concurrent transactions - it works for me
> (postgres 6.5.2)
Vadim
Lincoln Yeoh wrote:
>
> At 04:38 PM 20-10-1999 +0800, Vadim Mikheev wrote:
> >You hit buffer manager/disk manager problems or eat all disk space.
> >As for "modifying" - I meant insertion, deletion, update...
>
> There was enough disk space (almost another
Lincoln Yeoh wrote:
>
> At 04:12 PM 20-10-1999 +0800, Vadim Mikheev wrote:
> >It doesn't seem as MVCC problem. MVCC uses transaction ids,
> >not tuple ones, and so should work with any number of rows
> >modified by concurrent transaction... In theory... -:))
>
Lincoln Yeoh wrote:
>
> It's now a lot faster. Now only about 5 or so times slower. Cool.
>
> But it wasn't unexpected that I got the following after a while ;).
>
> NOTICE: BufferAlloc: cannot write block 990 for joblist/central
>
> NOTICE: BufferAlloc: cannot write block 991 for joblist/ce
amy cheng wrote:
>
> >1. all applications should use BEGIN/END;
> B) what does that mean for perl? or just limited to PL/pgSQL--
> then, isn't BEGIN/END the common syntax in PL/pgSQL?
>
> C) can you give me an outline of PL/pgSQL for 2. and 3. ?
> >2. in first transaction (deleting/updating
Leon wrote:
>
> speed of joins and sudden client death. :) The third question
> should be: what do I do with transaction deadlock, since there
> is no lock wait timeouts?
Server should abort one of transaction to resolve deadlock -
we don't use timeouts for this.
Did you get unresolved deadlock
Mark Wilson wrote:
>
> Last night I reformatted the disk, create a new filesystem and restored
> the last good full backup (from about a week ago) hoping I could get a
^^^
What did you use for backup ?
pg_dump/copy or you cp-ed datafiles to another place ?
> version of th
Stuart Rison wrote:
>
> Since I thought that probably left the table a bit messed up, I started a:
>
> VACUUM blast_hits;
>
> It's using 95% of the cpu and seems to be going nowhere (at least not in
> the 30 minutes it has been running so far).
>
> QUESTION 2: What do I do now? Is there any w
Bruce Momjian wrote:
>
> > I would like to make one small request for future releases. Is there a
> > setup parameter that could be enabled that would put a timeout for a query
> > that runs too long or endangers the integrity of the system? With the
> > systems that I use, there are times that
Leon wrote:
>
> Ah, you mean MVCC! That's what I replied to Tom Lane:
>
> > This problem can be solved. An offhand solution is to have
> > an additional system field which will point to new tuple left after
> > update. It is filled at the same time as the original tuple is
> > marked invalid. S
Hiroshi Inoue wrote:
>
> My words might be obscure.
>
> What I meant was
>
> How writers block other writers in LLL ?
>
> Certainly readers block no writers(readers) in LLL.
> But writers block no writers or the same-row writers or the same-table
> writers ?
>
> Currently writers block the s
Hiroshi Inoue wrote:
>
> > And note - this will be not row level locking, but
> > multi-version concurrency control.
> >
>
> What does it mean ?
> LLL in 6.5 doesn't include row level locking ?
One systems (Informix, Sybase) use locking for concurrency control,
another ones (Oracle, Interbase)
claudio navarro wrote:
>
> I would like to know wich isolation level has PostgreSQL?
> Dirtyread, readcommited or repeatableread?
Serialized only.
Vadim
We've discovered very old bug in btree indices.
It's present in all PostgreSQL versions.
This bug affects UPDATE and INSERT INTO _table_ SELECT FROM _table_
under some circumstances.
Patch for 6.3.2 is available via
ftp://ftp.postgresql.org/pub/patches/btree_adj-980730.gz.
Thanks to Tom Lane fo
Matt McClure wrote:
> > >
> > > If vacuum does not alter row oids, then I have another question. How does
> > > postgres re-use oids? I've seen the numbers grow and grow, but despite
> >
> > It doesn't.
>
> Doesn't the fact that postgres never re-uses deleted (and therefo
Matt McClure wrote:
>
> You say that vacuum "re-writes" the database. Does it alter row oids???
^^
No.
> If so, my scheme completely corrupts my database whenever I do a vacuum,
> since in concert and song the row oids would c
24 matches
Mail list logo
