Re: [GENERAL] How to make replica and use it when master is down ?
On 13.10.2011 22:47, Mark Keisler wrote: > It is possible. See http://www.postgresql.org/docs/9.0/interactive/high-availability.html [3] > > On Wed, Oct 12, 2011 at 3:31 AM, Condor wrote: > >> Hello everyone, >> from a few days I want to ask how to make replica server of my database and when spontaneously my master server going down due to loosing power or has been offline more then 5 min, replica server to become >> master server and accept all querys to database like select, insert, update and so on and when original master server become online to sync his db or just to stay slave / replica server until one of >> the servers does not going down ? >> >> Well, I don't know if this is possibly. >> >> -- >> Regards, >> Condor >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org [1]) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general [2] Yеs I see this, but I actually want user comments and problems that can arise. -- Regards, Condor Links: -- [1] mailto:pgsql-general@postgresql.org [2] http://www.postgresql.org/mailpref/pgsql-general [3] http://www.postgresql.org/docs/9.0/interactive/high-availability.html [4] mailto:con...@stz-bg.com
Re: [GENERAL][HACKERS] register creation date of table
On Fri, Oct 14, 2011 at 6:20 AM, Willy-Bas Loos wrote: > 1. I think that there is no such information in the system tables. is > that correct? Yes. It's been discussed before but some people (particularly, Tom, IIRC) are not convinced that it's useful enough to justify its existence. > 2. i would like to go back in time. I think that i will just look up > the creation date for the files in the data directory and translate > their oid's to the object names and then update their dates. This > would of course only work from the last restore. Is that a good way to > do it? Well, that timestamp will get bumped on TRUNCATE, CLUSTER, VACUUM FULL, and rewriting versions of ALTER TABLE. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 9.1 got really fast ;)
I have to share this, a statement that is finished before I even run it ;) Limit (cost=0.00..527.34 rows=20 width=4) (actual time=0.046..-2.436 rows=20 loops=1) Output: id, (count(*)) Buffers: shared hit=191 -> GroupAggregate (cost=0.00..12403455.78 rows=470416 width=4) (actual time=0.044..-2.448 rows=20 loops=1) Output: id, count(*) Buffers: shared hit=191 -> Index Scan using idx_pid on prodlink z (cost=0.00..12373751.62 rows=500 width=4) (actual time=0.021..-2.578 rows=183 loops=1) Output: id, pid, bid Buffers: shared hit=191 Total runtime: -2.368 ms << this is amazing ;) This is with 9.1.1 on a Windows XP machine -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 9.1 got really fast ;)
On 15 Oct 2011, at 21:20, Thomas Kellerer wrote: > > Total runtime: -2.368 ms << this is amazing ;) > wow :) > This is with 9.1.1 on a Windows XP machine That explains it ;) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 9.1 got really fast ;)
On Sat, Oct 15, 2011 at 1:33 PM, Grzegorz Jaskiewicz wrote: > > On 15 Oct 2011, at 21:20, Thomas Kellerer wrote: > > > > Total runtime: -2.368 ms << this is amazing ;) > > > wow :) > > > This is with 9.1.1 on a Windows XP machine > That explains it ;) > > > Are you saying that Windows XP is the ultimate server OS for high performance PostgreSQL installations? Are there optimizations that this platform can take advantage of, perhaps extending Pg timelines into actual time travel that are not available on other platforms? ;-) Best Wishes, Chris Travers
Re: [GENERAL] 9.1 got really fast ;)
On 10/15/11 1:59 PM, Chris Travers wrote: Are you saying that Windows XP is the ultimate server OS for high performance PostgreSQL installations? Are there optimizations that this platform can take advantage of, perhaps extending Pg timelines into actual time travel that are not available on other platforms? powered by Neutrinos? [*] wait, never mind, they think they found the error that lead to those "FTL" results http://arxiv.org/PS_cache/arxiv/pdf/1110/1110.2685v1.pdf -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are file system level differential/incremental backups possible?
On 10/13/2011 05:30 AM, Bob Hatfield wrote: Is it possible to do a full file system level backup of the data directory, say once a week, and differentials or incrementals daily? I'd love to be able to do this, but you can't do it usefully at a file-system level. There's too much churn in the data files for even a binary diff to be much use - and even if it were, the performance of it would be miserable. You *could* do a differential so long as it's a proper one that tracks file removals as well as additions/changes. It'd be pretty pointless though as you wouldn't save much if any storage. I've looked into database-level diffs, but from what I can find out it seems that PostgreSQL's MVCC system doesn't store enough information to produce a differential dump, either. There's no way to detect and record tuples that were deleted then vacuumed away since the last backup was taken, so a trigger-based or WAL-based system is necessary. I'd love a way to "collapse" or merge a set of WAL segments into a minimal diff that only contained just enough information to get from the start to end state of the series of WAL segments, rather than all the churn in-between. This would be great for storing longer PITR histories (but more coarsely) and being able to do faster restores. Unfortunately given how scattered writes are I doubt it'd actually be possible or any faster if it was. SQL-level differentials would be great, though. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
