Re: [HACKERS] *sigh*

2004-01-03 Thread Simon Riggs
of cross-overs with the materialized view sub-project. Could you say a little more about why you wanted to achieve this? Best Regards Simon Riggs 2nd Quadrant +44-7900-255520 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kirkwood Sent: Monday

Re: [HACKERS] cache control?

2004-01-23 Thread Simon Riggs
Jan Wieck wrote: have you read src/backend/storage/buffer/README of current CVS tip? Tom Lane wrote: Um, did you read the discussion of the ARC buffer management algorithm that's already been implemented for 7.5? Tom, Jan, No, I hadn't read this. Thank you both for your time and

Re: [HACKERS] cache control?

2004-01-23 Thread Simon Riggs
performance tuning on DBT-3 with 7.5. Thanks again for adding the new algorithm. Best Regards, Simon ... Simon Riggs wrote: ... My suggestion would be to: - split the buffer cache into two, just as Oracle does: KEEP RECYCLE. This could default to KEEP=66% of total memory available

Re: [HACKERS] 7.5 change documentation

2004-01-26 Thread Simon Riggs
OK, I will attempt to draw together this information as currently stands. If this makes any sense, we can discuss what the requirement/process is for regular maintenance (daily/weekly/monthly etc). Understood to mean changes in next release (current progress) - items that have been

Re: [HACKERS] cache control?

2004-01-26 Thread Simon Riggs
Jan, Happy to continue the discussion...though without changing my suggestion that we defer any further more specialised improvements for now. Jan Wieck replied to... Simon Riggs wrote: If we know ahead of time that a large scan is going to have this effect, why wait for the ARC to play

Re: [HACKERS] cache control?

2004-01-26 Thread Simon Riggs
that exhibits the described properties and quantifying the effects and their frequency. If it IS worth it, and I accept that it may not be, I'll have a hack at the very specialised improvement I was suggesting, for very specific workload types. Best Regards Simon Riggs

Re: [HACKERS] Recursive optimization of IN subqueries

2004-01-27 Thread Simon Riggs
Tom Lane writes In the second place, what the code is doing is dependent on an understanding of the semantics of IN; I'm not sure it's applicable to, say, WHERE outervar ANY (SELECT innervar FROM ...) and it's definitely not applicable to WHERE outervar ALL (SELECT innervar

Re: [HACKERS] Recursive optimization of IN subqueries

2004-01-27 Thread Simon Riggs
Tom Lane writes In the second place, what the code is doing is dependent on an understanding of the semantics of IN; I'm not sure it's applicable to, say, WHERE outervar ANY (SELECT innervar FROM ...) and it's definitely not applicable to WHERE outervar ALL (SELECT innervar

Re: [HACKERS] Recursive optimization of IN subqueries

2004-01-27 Thread Simon Riggs
PROTECTED] Subject: Re: [HACKERS] Recursive optimization of IN subqueries Simon Riggs wrote: Tom Lane writesIn the second place, what the code is doing is dependent on anunderstandingof the semantics of IN; I'm not sure it's applicable to, say, WHERE outervar ANY (SELECT innervar FROM ...)and it's

Re: 7.5 change documentation (was Re: [HACKERS] cache control?)

2004-01-27 Thread Simon Riggs
Bruce Momjian wrote Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: If the TODO-list-with-dash isn't the correct place to have looked, is there another list of committed changes for the next release? We tend to rely on the CVS commit logs as the definitive source. You can

Re: [HACKERS] 7.5 change documentation

2004-01-27 Thread Simon Riggs
POSTGRESQL: Summary of Changes since last release (7.4.1) -- 26 Jan 2004 This is a summary of most changes since code versions marked 7_4_1, rather than a weekly news bulletin, a summary of desired future items, or the definitive list of

Re: [HACKERS] Write cache

2004-01-28 Thread Simon Riggs
noise, poorly wired cabling and intermittently used shared SCSI... Best of luck, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Question about indexes

2004-01-28 Thread Simon Riggs
without having persistent bitmap indices. IMHO, the longer term goal of a good star join plan is an important one - that may influence the design selection for this discussion. Hope some of that helps, Best regards, Simon Riggs ---(end of broadcast

Re: [HACKERS] lock related issues...

2004-01-28 Thread Simon Riggs
an awful hidden secret feature either. Best regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Idea about better configuration options for sort

2004-02-03 Thread Simon Riggs
raise the limit without changing everything else. Best regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] PITR Dead horse?

2004-02-04 Thread Simon Riggs
be a press-release: PostgreSQL community focuses new efforts towards Robustness features for its next major release. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your

Re: [HACKERS] [PATCHES] update i386 spinlock for hyperthreading

2004-02-08 Thread Simon Riggs
handling it blind - without regard to its contents, as ARC does now - that sounds expensive. Hope some of that helps.. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send

Re: [HACKERS] Transaction aborts on syntax error.

2004-02-10 Thread Simon Riggs
behaviour regarding this point. Anybody? Best regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend

[HACKERS] Summary of Changes since last release (7.4.1)

2004-02-10 Thread Simon Riggs
is that they haven't been cast in stone yet... -- Simon Riggs, [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can

Re: [HACKERS] Summary of Changes since last release (7.4.1)

2004-02-11 Thread Simon Riggs
my error, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Transaction aborts on syntax error.

2004-02-11 Thread Simon Riggs
Tom Lane Simon Riggs [EMAIL PROTECTED] writes: Most importantly, other references I have state that: the ANSI SQL-99 specification does require that if a statement errors then only that statement's changes are rolled back. ...if anybody has a copy of the actual spec could they check

Re: [HACKERS] Transaction aborts on syntax error.

2004-02-12 Thread Simon Riggs
Bruce Momjian Simon Riggs wrote: Tom Lane Simon Riggs [EMAIL PROTECTED] writes: Most importantly, other references I have state that: the ANSI SQL-99 specification does require that if a statement errors then only that statement's changes are rolled back. ...if anybody

Re: [HACKERS] Slow DROP INDEX

2004-02-16 Thread Simon Riggs
lock (and perhaps it shouldn't be). May not be the case...but the answer should be interesting. Hope it helps, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs

Re: [HACKERS] No Timeout in SELECT..FOR UPDATE

2004-02-16 Thread Simon Riggs
, don't use the SELECT..FOR UPDATE metaphor, try another design that doesn't require this style of locking. Application level locking can get you round many problems - the database can't do everything. Best regards, Simon Riggs ---(end of broadcast

Re: [HACKERS] Progress Report on Materialized Views

2004-02-21 Thread Simon Riggs
two best angles of attack on the DBT-3 workload, IMHO. I very much look forward to further news. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs

Re: [HACKERS] Progress Report on Materialized Views

2004-02-23 Thread Simon Riggs
Tom Lane Simon Riggs [EMAIL PROTECTED] writes: Could I suggest that your next step is to sync up with the work being done on tuning the DBT-3 query workload? As I'm sure you're aware, that is very similar to TPC-H workload, where most of the commercial RDBMS vendors utilise Materialized

Re: [HACKERS] Tablespaces

2004-02-26 Thread Simon Riggs
of a database without thinking... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] bgwriter never dies

2004-02-26 Thread Simon Riggs
never a case when we accidentally turn off archiving when there's some part of pg still up. Best regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Avoid MVCC using exclusive lock possible?

2004-03-01 Thread Simon Riggs
and the time spent would double other requirements. MySQL has multiple storage managers and that must slow them down enormously trying to test or even fine tune things. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: if posting/reading through

Re: [HACKERS] Tablespaces

2004-03-01 Thread Simon Riggs
are not recoverable from backup? - it might be desirable to allow recovery with less than all of the original tablespces - it might also be desirable to allow recovery when the tablespaces txn Ids don't match (though that is forbidden on many other dbms) Best Regards, Simon Riggs

Re: [HACKERS] Out of space situation and WAL log pre-allocation (was Tablespaces)

2004-03-02 Thread Simon Riggs
Tom Lane [mailto:[EMAIL PROTECTED] Simon Riggs [EMAIL PROTECTED] writes: You're absolutely right about the not-knowing when you're out of space issue. However, if the xlog has been written then it is not desirable, but at least acceptable that the checkpoint/bgwriter cannot complete

Re: [HACKERS] Out of space situation and WAL log pre-allocation (was Tablespaces)

2004-03-03 Thread Simon Riggs
. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

[HACKERS] The Return of PITR

2004-03-03 Thread Simon Riggs
! Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-03 Thread Simon Riggs
Neil Conway Simon Riggs wrote: Josh Berkus wrote Simon Riggs wrote Please set WAL_DEBUG to 1 so we can see a bit more info: thanks. I'm pretty sure that WAL_DEBUG requires a compile-time option. I'm surprised, but you are right, the manual does SAY this requires a compile time

[HACKERS] PITR Functional Design v2 for 7.5

2004-03-08 Thread Simon Riggs
comments, Best Regards, Simon Riggs, 2nd Quadrant Review of current Crash Recovery Crash recovery is catered for by the use of WAL logging, or xlogs. xlogs are written to disk immediately before a transaction is acknowledged as committed. xlogs contain REDO information sufficient to rollforward any

Re: [HACKERS] Out of space situation and WAL log pre-allocation (was

2004-03-08 Thread Simon Riggs
Bruce Momjian Simon Riggs wrote: User-selectable behaviour? OK. That's how we deal with fsync; I can relate to that. That hadn't been part of my thinking because of the importance I'd attached to the log files themselves, but I can go with that, if that's what was meant. So, if we had

Re: [HACKERS] Out of space situation and WAL log pre-allocation (was Tablespaces)

2004-03-08 Thread Simon Riggs
Joe Conway [mailto:[EMAIL PROTECTED] Simon Riggs wrote: Tom Lane [mailto:[EMAIL PROTECTED] That should be user-scriptable policy, in my worldview. O... and other dbms will freeze when this situation is hit, rather than continue and drop archive logs.] Been there, done that, don't see

Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-08 Thread Simon Riggs
Tom Lane Simon Riggs [EMAIL PROTECTED] writes: The behaviour I wish to add is: Keep wal_debug as a value between 0 and 16. If =0 then no debug output (default). Use following bitmasks against the value Mask 1 = XLOG Checkpoints get logged Mask 2 = Archive API calls get logged Mask 4

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-09 Thread Simon Riggs
Andreas Pflug Josh Berkus wrote: Related to the above, what I don't see in your paper or the proposed API is a way to coordinate full back-ups and WAL archiving. Obviously, the PITR Archive is only useful in reference to an existing full backup, so it is important to be able to associate a

[HACKERS] PITR: Request for assistance with alpha test plan

2004-03-09 Thread Simon Riggs
...but there will be a list of credits somewhere down the line Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-09 Thread Simon Riggs
Richard Huxton On Monday 08 March 2004 23:28, Simon Riggs wrote: PITR Functional Design v2 for 7.5 Review of current Crash Recovery Is there any value in putting this section on techdocs or similar? We do get a small but steady trickle of people asking for details on internals, and I

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-09 Thread Simon Riggs
Josh Berkus [mailto:[EMAIL PROTECTED] First off, let me compliment you on such a thorough proposal. I'm feeling very enthusiastic about 7.5 PITR Thank you, though please realise that I am in many ways summarising a wide range of suggestions and earlier work into a coherent whole. Me too! I'm

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-10 Thread Simon Riggs
for full xlogs and then executes XLogArchiveNotify() for them? Thoughts anyone? Best Regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-10 Thread Simon Riggs
From: Josh Berkus [mailto:[EMAIL PROTECTED] SIGHUP - seems to allow different parameter settings in each backend Nope. SIGHUP means that you need to send a HUP to the postmaster, such as you would with changes to pg_hba.conf. SUSET - maybe what you're looking for??? Yes.

Re: [HACKERS] Default Stats Revisited

2004-03-12 Thread Simon Riggs
to set it down as well as up, remember). That way, the default behaviour improves even when the index stats parameter is not actually set, yet is still controllable when you do. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe

Re: [HACKERS] PITR Functional Design v2 for 7.5

2004-03-12 Thread Simon Riggs
being able to ask that question, if that is a business requirement. Best regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] Update on PITR

2004-03-30 Thread Simon Riggs
. Not uncommon, I grant you, but in the circumstances I didn't really need the extra recovery practice... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

FW: [HACKERS] Increasing security in a shared environment ...

2004-03-31 Thread Simon Riggs
security in just the same way other systems already do. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [HACKERS] Update on PITR

2004-03-31 Thread Simon Riggs
Bruce Momjian wrote Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: [ expecting to finish PITR by early June ] Is this all still OK for 7.5? (My attempts at cataloguing changes has fallen by the wayside in concentrating on the more important task of PITR.) Do we have

Re: [HACKERS] PITR for replication?

2004-04-02 Thread Simon Riggs
. This mode requires more thought, but is certainly possible, in time. Best Regards Simon Riggs ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your

Re: [HACKERS] Function to kill backend

2004-04-06 Thread Simon Riggs
that in a script if they choose. Internally, we could then implement it however we chose. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Function to kill backend

2004-04-06 Thread Simon Riggs
Bruce Momjian Simon Riggs wrote: The function to kill backend seems no longer in doubt, but the *reason* is still blurred, other than we don't want to bring down the postmaster to do this. So far, reasons given have been: 1. to kill idlers 2. to kill runaway queries/statements

Re: [HACKERS] PostgreSQL configuration

2004-04-14 Thread Simon Riggs
concepts from other industry areas are probably more important to the success of pg than conformance to internet/LINUX norms.] Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your

Re: [HACKERS] Analysis/Overview of PostgreSQL and SQL2003

2004-04-14 Thread Simon Riggs
. Sounds great. That would save me looking further into it, so I will be happy to read drafts and ask more detailed questions based upon what you find, or be willing to look at specific parts if you want to chunk out the work. I'm sure you'll get lets of support. Best regards, Simon Riggs

Re: [HACKERS] XLog: how to log?

2004-05-11 Thread Simon Riggs
in the WAL file and choose the xid for recovery. Bruce, As I started this e-mail (1st time), I completely agreed with you. I've now had to switch my thinking. (Doesn't effect archiving architecture) I'm a little dazedcomments anyone? Best regards, Simon Riggs

[HACKERS] PITR Signalling the Archiver

2004-05-11 Thread Simon Riggs
have answers, but I strive for the best answer. Thanks very much, Best regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] XLog: how to log?

2004-05-11 Thread Simon Riggs
On Tue, 2004-05-11 at 21:29, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Currently, recovery loops until end of xlogs. There is no exit condition from the loop. There is not currently a timestamp on the xlogs - anywhere apart from the file date on each xlog. Sure

Re: [HACKERS] PITR Signalling the Archiver

2004-05-11 Thread Simon Riggs
On Tue, 2004-05-11 at 22:15, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I need to send a signal from a backend to the archiver process. 1. What signal should I use? SIGUSR1 or SIGUSR2 would be the safest choices. 2. How do I give the processid of the archiver

Re: [HACKERS] XLog: how to log?

2004-05-11 Thread Simon Riggs
On Tue, 2004-05-11 at 22:01, Bruce Momjian wrote: Anyway, I though we agreed to just get total recovery working for 7.5 and we can deal with recovery to a particular point later. Back on target now! Regards, Simon ---(end of broadcast)--- TIP 1:

Re: [HACKERS] XLog: how to log?

2004-05-11 Thread Simon Riggs
Thanks to all of you for such swift advice and correction! Have a good evening... On Tue, 2004-05-11 at 22:26, Alvaro Herrera wrote: On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote: On Tue, 2004-05-11 at 16:33, Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera [EMAIL

Re: [HACKERS] XLog: how to log?

2004-05-12 Thread Simon Riggs
clear for me. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] XLog: how to log?

2004-05-11 Thread Simon Riggs
X, but do not include this one. Does that make sense? Does everything we have support that? Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] PITR logging control program

2004-05-10 Thread Simon Riggs
and make any comments or questions now...time for rework is now slipping fast. Best Regards, Simon Riggs, 2nd Quadrant ...detail chatter follows On Thu, 2004-05-06 at 05:38, Bruce Momjian wrote: Simon Riggs wrote: Bruce, was this OK with you...shall I post? Some items occurred to me during

Re: [HACKERS] database errors

2004-05-14 Thread Simon Riggs
, what is the benefit of using NFS? PostgreSQL offers client/server access - so why not use that instead? Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] PITR logging control program

2004-05-04 Thread Simon Riggs
On Fri, 2004-04-30 at 04:02, Bruce Momjian wrote: Simon Riggs wrote: Agreed we want to allow the superuser control over writing of the archive logs. The question is how do they get access to that. Is it by running a client program continuously or calling an interface script from

Re: [HACKERS] PITR logging control program

2004-04-30 Thread Simon Riggs
to an arbitrary point but have a strained implementation that we have to revisit for 7.6. Interesting thought, I see now your priorities. Will read and digest over next few days. Thanks for your help and attention, Best regards, Simon Riggs ---(end of broadcast

Re: [HACKERS] btbulkdelete

2004-04-26 Thread Simon Riggs
sequence. i.e. my thinking was about a way to keep logical looking more like physical, in certain situations. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

[HACKERS] PITR Phase 1 - Test results

2004-04-26 Thread Simon Riggs
. Best Regards, Simon Riggs, 2ndQuadrant http://www.2ndquadrant.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

[HACKERS] PITR Phase 2 - Design Planning

2004-04-26 Thread Simon Riggs
, Simon Riggs, 2ndQuadrant http://www.2ndquadrant.com ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] PITR Phase 1 - Test results

2004-04-26 Thread Simon Riggs
sets too solid. Regards, Simon On Mon, 2004-04-26 at 17:48, Bruce Momjian wrote: I want to come hug you --- where do you live? !!! :-) --- Simon Riggs wrote: I've now completed the coding of Phase 1 of PITR

[HACKERS] PITR Phase 1 - Code Overview (1)

2004-04-26 Thread Simon Riggs
On Mon, 2004-04-26 at 16:37, Simon Riggs wrote: I've now completed the coding of Phase 1 of PITR. This allows a backup to be recovered and then rolled forward (all the way) on transaction logs. This proves the code and the design works, but also validates a lot of the earlier assumptions

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-26 Thread Simon Riggs
On Mon, 2004-04-26 at 22:05, Bruce Momjian wrote: Simon Riggs wrote: Transaction log files currently have timestamps, so that is straightforward, but probably not the best we can do. We would rollforward until the xlog file time desired point in time. To make (2) work we would have

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-26 Thread Simon Riggs
On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote: On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote: Simon Riggs wrote: Transaction log files currently have timestamps, so that is straightforward, but probably not the best we can do. We would rollforward until the xlog

Re: [HACKERS] PITR Phase 1 - Test results

2004-04-26 Thread Simon Riggs
On Mon, 2004-04-26 at 18:08, Bruce Momjian wrote: Simon Riggs wrote: Well, I guess I was fairly happy too :-) YES! I'd be more comfortable if I'd found more bugs though, but I'm sure the kind folk on this list will see that wish of mine comes true! The code is in a needs more

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 10:38, Richard Huxton wrote: On Tuesday 27 April 2004 00:32, Bruce Momjian wrote: Simon Riggs wrote: On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote: On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote: I was thinking --- how would someone know

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 08:56, Hans-Jürgen Schönig wrote: Simon Riggs wrote: Since Phase1 is functioning and should hopefully soon complete, we can now start thinking about Phase 2: full recovery to a point-in-time. Previous thinking was that a command line switch would be used

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
irrelevant to me. For long running transactions where you want to recover as much as possible, one might also want to recover up until just before a specific transaction committed (as opposed to started). Sounds like the difference between and =, so should be possible... Best Regards, Simon

Re: [HACKERS] PITR Phase 1 - Code Overview (1)

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 18:10, Peter Eisentraut wrote: Simon Riggs wrote: New utility aimed at being located in src/bin/pg_arch Why isn't the archiver process integrated into the server? Number of reasons Overall, I initially favoured the archiver as another special backend, like

Re: [HACKERS] btbulkdelete

2004-04-27 Thread Simon Riggs
On Mon, 2004-04-26 at 17:24, Manfred Koizar wrote: On Mon, 26 Apr 2004 14:29:58 +0100, Simon Riggs [EMAIL PROTECTED] wrote: Now that FSM covers free btree index pages this access pattern might be highly nonsequential. I had considered implementing a mode where the index doesn't keep

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
to a PIT directly 3. Recovery to a named checkpoint Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 21:56, scott.marlowe wrote: On Mon, 26 Apr 2004, Andrew Payne wrote: Bruce asked an excellent question: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Ignore the opposition

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
. PostgreSQL already has crash recovery...this is for restore from backup scenarios. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 23:11, Rod Taylor wrote: On Tue, 2004-04-27 at 17:36, Simon Riggs wrote: On Tue, 2004-04-27 at 21:56, Rod Taylor wrote: Overall, I'd refer back to the points Bruce raised - you certainly do need a way of finding out the time to recover to, and as others have

Re: [HACKERS] OLAP versus Materialized Views?

2004-04-27 Thread Simon Riggs
On Tue, 2004-04-27 at 23:47, Jonathan Gardner wrote: I've just discovered OLAP and it looks like a competing technology with materialized views. Yes. Read up some more, but don't get sucked in by the marketing. In a nutshell, OLAP seems to be pre-storing the results of potential queries.

[HACKERS] PITR Phase 1 Code Review

2004-04-28 Thread Simon Riggs
. I'll be around daily to answer queries and fix reported bugs. Thanks, Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] PITR Phase 1 - Code Overview (1)

2004-04-28 Thread Simon Riggs
On Wed, 2004-04-28 at 16:14, Peter Eisentraut wrote: Am Tuesday 27 April 2004 19:59 schrieb Bruce Momjian: Peter Eisentraut wrote: Simon Riggs wrote: New utility aimed at being located in src/bin/pg_arch Why isn't the archiver process integrated into the server? I think

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-28 Thread Simon Riggs
On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote: Simon Riggs wrote: On Tue, 2004-04-27 at 21:56, Rod Taylor wrote: Overall, I'd refer back to the points Bruce raised - you certainly do need a way of finding out the time to recover to, and as others have said also, time isn't

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-28 Thread Simon Riggs
On Wed, 2004-04-28 at 18:35, Andrew Dunstan wrote: Simon Riggs wrote: On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote: What if we added transaction id to log_line_prefix? The user could then log all queries and find the xid where they want to stop, but of course that assumes

Re: [HACKERS] PITR Phase 2 - Design Planning

2004-04-29 Thread Simon Riggs
On Thu, 2004-04-29 at 16:09, Peter Eisentraut wrote: Simon Riggs wrote: I'd suggest extending the CHECKPOINT command so you can say: CHECKPOINT text message e.g. CHECKPOINT 'starting payroll Feb04'; (I'm sure some other DBMS does this...head spinning can;t recall...) the text could just

Re: [HACKERS] PITR logging control program

2004-04-29 Thread Simon Riggs
- and in any case any practically focused API has a reference port as a way of showing how to use it and exposing any bugs in the server side implementation. The point is...everybody is now empowered to write tape drive code, whatever you fancy go do. Best regards, Simon Riggs

Re: [HACKERS] PITR logging control program

2004-04-29 Thread Simon Riggs
On Thu, 2004-04-29 at 20:24, Bruce Momjian wrote: Simon Riggs wrote: The archiver should be able to do a whole range of things. Basically, that point was discussed and the agreed approach was to provide an API that would allow anybody and everybody to write whatever they wanted

Re: [HACKERS] PITR logging control program

2004-04-29 Thread Simon Riggs
documentation Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Call for 7.5 feature completion

2004-04-29 Thread Simon Riggs
tripped over on various issues, nor even 1 press-worthy user was unable to recover correctly. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do

[HACKERS] Small OS ports Handheld devices

2004-04-29 Thread Simon Riggs
, then /bin/sync: what percentage of the device's erase blocks get hit? Thanks, Simon Riggs 2nd Quadrant ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-05 Thread Simon Riggs
that this should be a session settable parameter, to allow session transaction semantics to mimic particular DBMS. I want the behaviour but not the effort... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Call for 7.5 feature completion

2004-05-17 Thread Simon Riggs
, how long has PITR been brewing? And, who thinks that we'll get increased adoption without the big ticket items? (Even if your opinion is that PITR isn't one of them). I can't complete by 1 June. Think worse of me if you choose. Best Regards, Simon Riggs ---(end

Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004

2004-05-31 Thread Simon Riggs
freeze. ...as-early-as-possible is understood... Best Regards, Simon Riggs, 2nd Quadrant ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Fast index build vs. PITR

2004-06-01 Thread Simon Riggs
data in the event of a crash... i.e. default=NOLOGGING on all statements Best regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004

2004-06-01 Thread Simon Riggs
might have helped all of us to understand the impact of an extra weeks discussion etc.. Personally, I feel I had good notice, but that doesn't mean it was possible for me to finish by that time... Best Regards, Simon Riggs ---(end of broadcast

Re: [HACKERS] Fast index build vs. PITR

2004-06-01 Thread Simon Riggs
recover-to-a point scenario. It *MIGHT* make it into this release, if we get the other stuff done first. I think we need to explore the procedures we are going to use for PITR. Much of that has already been discussed. Best Regards, Simon Riggs ---(end of broadcast

  1   2   3   4   5   6   7   8   9   10   >