[HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <[EMAIL PROTECTED]> wrote: > > Hello, in my particular case I need to configure Postgres to handle only > a > > few concurrent connections, but I need it to be blazingly fast,

Re: [HACKERS] Upcoming back-branch update releases

On Wed, May 28, 2008 at 4:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > If you've got any bug fixes you've been working on, now is a good time > to get them finished up and sent in... Has the s/\x09//g patch for psql from Bruce and you been backported to 8.3? I didn't see it on pgsql-commiters.

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 4:26 AM, Sabbiolina <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <[EMAIL PROTECTED]> wrote: >> > Hello, in my particular case I need to configure Postgres to handle on

Re: [HACKERS] pg_regress: referencing shared objects from tests

Tom Lane wrote: Jorgen Austvik - Sun Norway <[EMAIL PROTECTED]> writes: we would like to be able to use and ship pg_regress and the PostgreSQL test suite independently of the PostgreSQL build environment, for testing and maybe even as a separate package to be build and shipped with the OS for

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 01:05:22AM +0200, Sabbiolina wrote: > I have 4 Gigs of RAM, how do I force Postgres to use a higher part of such > memory in order to cache more indexes, queries and so on? PG relies on the operating system to cache most disk accesses. Looking at the amount of memory a pro

Re: [HACKERS] Upcoming back-branch update releases

"Guillaume Smet" <[EMAIL PROTECTED]> writes: > On Wed, May 28, 2008 at 4:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote: >> If you've got any bug fixes you've been working on, now is a good time >> to get them finished up and sent in... > Has the s/\x09//g patch for psql from Bruce and you been > b

Re: [HACKERS] [PERFORM] Memory question on win32 systems

Sabbiolina wrote: On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <[EMAIL PROTECTED] > wrote: On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <[EMAIL PROTECTED] > wrote: > Hello, in my particular case I need to configure Postgres t

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19:46AM -0400, Justin wrote: > To my understanding Postgresql only caches queries and results in memory > for that specific connection. So when that connection is closed those > cached results are cleared out.So cached indexs and queries are for > that connection

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19 AM, Justin <[EMAIL PROTECTED]> wrote: > To my understanding Postgresql only caches queries and results in memory for > that specific connection. So when that connection is closed those cached > results are cleared out.So cached indexs and queries are for that > co

[HACKERS] Core team statement on replication in PostgreSQL

The Postgres core team met at PGCon to discuss a few issues, the largest of which is the need for simple, built-in replication for PostgreSQL. Historically the project policy has been to avoid putting replication into core PostgreSQL, so as to leave room for development of competing solutions, reco

Re: [HACKERS] Upcoming back-branch update releases

Tom Lane wrote: > "Guillaume Smet" <[EMAIL PROTECTED]> writes: > > On Wed, May 28, 2008 at 4:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > >> If you've got any bug fixes you've been working on, now is a good time > >> to get them finished up and sent in... > > > Has the s/\x09//g patch for psql

Re: [HACKERS] Upcoming back-branch update releases

On Thu, May 29, 2008 at 4:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > No, nothing's been done about that AFAIK. What's the consensus, > do we want to change that behavior in 8.3.2? IIRC, noone voted against backpatching it after Alvaro and you agreed with doing so. Archives link: http://archive

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Tom Lane <[EMAIL PROTECTED]> wrote: > The Postgres core team met at PGCon to discuss a few issues, the largest > of which is the need for simple, built-in replication for PostgreSQL. > Historically the project policy has been to avoid putting replication > into core PostgreSQL, so as

Re: [HACKERS] Upcoming back-branch update releases

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> No, nothing's been done about that AFAIK. What's the consensus, >> do we want to change that behavior in 8.3.2? > I think everyone but me wanted it backpatched, so let's do it. I have > posted both patches but I am unable to apply yo

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: > The Postgres core team met at PGCon to discuss a few issues, the > largest of which is the need for simple, built-in replication for > PostgreSQL. Historically the project policy has been to avoid > putting replication into core PostgreSQ

Re: [HACKERS] Proposal - Collation at database level

Radek Strnad napsal(a): I'm thinking of dividing the problem into two parts - in beginning pg_collation will contain two functions. One will have hard-coded rules for these basic collations (SQL_CHARACTER, GRAPHIC_IRV, LATIN1, ISO8BIT, UCS_BASIC). It will compare each string character bitwise

Re: [HACKERS] Upcoming back-branch update releases

On Thu, May 29, 2008 at 4:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > IIRC I made a few cosmetic cleanups along with the actual bug fix. > I'll take a look this afternoon and put it in. Thanks. -- Guillaume -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote: > On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: > This part is a deal-killer. It's a giant up-hill slog to sell warm > standby to those in charge of making resources available because the > warm standby machine consumes SA time,

Re: [HACKERS] [PERFORM] Memory question on win32 systems

Merlin Moncure wrote: On Thu, May 29, 2008 at 10:19 AM, Justin <[EMAIL PROTECTED]> wrote: To my understanding Postgresql only caches queries and results in memory for that specific connection. So when that connection is closed those cached results are cleared out.So cached indexs and q

Re: [HACKERS] Core team statement on replication in PostgreSQL

Marko, But Tom's mail gave me impression core wants to wait until we get "perfect" read-only slave implementation so we wait with it until 8.6, which does not seem sensible. If we can do slightly inefficient (but simple) implementation right now, I see no reason to reject it, we can always impr

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 4:45 PM, Justin <[EMAIL PROTECTED]> wrote: > > Then what is the purpose of shared buffers if nothing is being reused is it > only used to keep track locks, changes and what is to being spooled to the > kernel??? It caches disk pages (and holds other data structures), not q

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote: > On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote: > > This part is a deal-killer. It's a giant up-hill slog to sell > > warm standby to those in charge of making resources available > > because the warm standby machine consume

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > The only question I have is... what does this give us that PITR doesn't > give us? I think the idea is that WAL records would be shipped (possibly via socket) and applied as they're generated, rather than on a file-by-

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, 29 May 2008, Justin wrote: I'm confussed trying to figure out how caches are being use and being moving through postgresql backend. The shared_buffers cache holds blocks from the database files. That's it. If you want some more information about how that actually works head to http:

Re: [HACKERS] Core team statement on replication in PostgreSQL

Josh Berkus wrote: > Marko, > > > But Tom's mail gave me impression core wants to wait until we get "perfect" > > read-only slave implementation so we wait with it until 8.6, which does > > not seem sensible. If we can do slightly inefficient (but simple) > > implementation > > right now, I see n

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > >> The only question I have is... what does this give us that PITR doesn't >> give us? > > I think the idea is that WAL records would be ship

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 4:52 PM, Dave Page <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 4:45 PM, Justin <[EMAIL PROTECTED]> wrote: >> >> Then what is the purpose of shared buffers if nothing is being reused is it >> only used to keep track locks, changes and what is to being spooled to the

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thursday 29 May 2008 09:54:03 am Marko Kreen wrote: > On 5/29/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > The Postgres core team met at PGCon to discuss a few issues, the largest > >  of which is the need for simple, built-in replication for PostgreSQL. > >  Historically the project policy has b

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, David Fetter <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: > > Ideally this would be coupled with the ability to execute read-only > > queries on the slave servers, but we see technical difficulties that > > might prevent that from being compl

Re: [HACKERS] Core team statement on replication in PostgreSQL

* Josh Berkus <[EMAIL PROTECTED]> [080529 11:52]: > Marko, > > >But Tom's mail gave me impression core wants to wait until we get "perfect" > >read-only slave implementation so we wait with it until 8.6, which does > >not seem sensible. If we can do slightly inefficient (but simple) > >implementa

Re: [HACKERS] Core team statement on replication in PostgreSQL

Joshua D. Drake wrote: On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote: On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: This part is a deal-killer. It's a giant up-hill slog to sell warm standby to those in charge of making resources available because the warm standby machin

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote: > Josh Berkus wrote: > > Publishing the XIDs back to the master is one possibility. We > > also looked at using "spillover segments" for vacuumed rows, but > > that seemed even less viable. > > > > I'm also thinking, for *async replic

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter wrote: This part is a deal-killer. It's a giant up-hill slog to sell warm standby to those in charge of making resources available because the warm standby machine consumes SA time, bandwidth, power, rack space, etc., but provides no tangible benefit, and this feature would have e

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter wrote: > On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote: > > Josh Berkus wrote: > > > Publishing the XIDs back to the master is one possibility. We > > > also looked at using "spillover segments" for vacuumed rows, but > > > that seemed even less viable. > > > > > > I'

Re: [HACKERS] Core team statement on replication in PostgreSQL

* Dave Page <[EMAIL PROTECTED]> [080529 12:03]: > On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <[EMAIL PROTECTED]> wrote: > > I think the idea is that WAL records would be shipped (possibly via > > socket) and applied as they're generated, rather than on a > > file-by-file basis. At least th

Re: [HACKERS] Core team statement on replication in PostgreSQL

Bruce, Another idea I discussed with Tom is having the slave _delay_ applying WAL files until all slave snapshots are ready. Well, again, that only works for async mode. I personally think that's the correct solution for async. But for synch mode, I think we need to push the xids back to

Re: [HACKERS] Core team statement on replication in PostgreSQL

Dave Page wrote: On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <[EMAIL PROTECTED]> wrote: On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote: The only question I have is... what does this give us that PITR doesn't give us? I think the idea is that

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote: > > On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: > > This part is a deal-killer. It's a giant up-hill slog to sell warm > > standby to those in charge of making resources

Re: [HACKERS] Core team statement on replication in PostgreSQL

Josh Berkus wrote: > Bruce, > > > Another idea I discussed with Tom is having the slave _delay_ applying > > WAL files until all slave snapshots are ready. > > > > Well, again, that only works for async mode. I personally think that's > the correct solution for async. But for synch mode, I th

Re: [HACKERS] Core team statement on replication in PostgreSQL

On May 29, 2008, at 9:12 AM, David Fetter wrote: On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote: Josh Berkus wrote: Publishing the XIDs back to the master is one possibility. We also looked at using "spillover segments" for vacuumed rows, but that seemed even less viable. I'm

Re: [HACKERS] Core team statement on replication in PostgreSQL

Tom Lane wrote: In practice, simple asynchronous single-master-multiple-slave replication covers a respectable fraction of use cases, so we have concluded that we should allow such a feature to be included in the core project. We emphasize that this is not meant to prevent continued development

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 09:10 -0700, Josh Berkus wrote: > Joshua D. Drake wrote: > > > > The only question I have is... what does this give us that PITR doesn't > > give us? > > Since people seem to be unclear on what we're proposing: > > 8.4 Synchronous Warm Standby: makes PostgreSQL more suita

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Aidan Van Dyk <[EMAIL PROTECTED]> wrote: > * Dave Page <[EMAIL PROTECTED]> [080529 12:03]: > > On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <[EMAIL PROTECTED]> wrote: > > > I think the idea is that WAL records would be shipped (possibly via > > > socket) and applied as they're gen

Re: [HACKERS] Core team statement on replication in PostgreSQL

* Marko Kreen <[EMAIL PROTECTED]> [080529 12:27]: > I don't think thats a problem. If the user runs its server at the > limit of write-bandwidth, thats its problem. > > IOW, with synchronous replication, we _want_ the server to lag behind > slaves. > > About the single-threading problem - afaik

Re: [HACKERS] Core team statement on replication in PostgreSQL

Andrew Dunstan <[EMAIL PROTECTED]> writes: > Dave Page wrote: >> Yes, we're talking real-time streaming (synchronous) log shipping. > That's not what Tom's email said, AIUI. Sorry, I was a bit sloppy about that. If we go with a WAL-shipping solution it would be pretty easy to support both synchr

[HACKERS] Duplicate Key Error from ANALYZE

While running a database-wide analyze on 8.3.1, I received the following: ERROR: duplicate key value violates unique constraint "pg_statistic_relid_att_index" I've only seen this once before, and because I don't have time to look at the code at the moment, I figured I'd post it as a heads-up. -

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter wrote: This part is a deal-killer. It's a giant up-hill slog to sell warm standby to those in charge of making resources available because the warm standby machine consumes SA time, bandwidth, power, rack space, etc., but provides no tangible benefit, and this feature would have ex

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter <[EMAIL PROTECTED]> writes: > On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote: >> The only question I have is... what does this give us that PITR >> doesn't give us? > It looks like a wrapper for PITR to me, so the gain would be ease of > use. A couple of points about

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 29 May 2008, David Fetter wrote: It's a giant up-hill slog to sell warm standby to those in charge of making resources available because the warm standby machine consumes SA time, bandwidth, power, rack space, etc., but provides no tangible benefit, and this feature would have exactly

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 09:18 -0700, Josh Berkus wrote: > Bruce, > > > Another idea I discussed with Tom is having the slave _delay_ applying > > WAL files until all slave snapshots are ready. > > > > Well, again, that only works for async mode. It depends on what we mean by synchronous. Do we me

Re: [HACKERS] Core team statement on replication in PostgreSQL

Josh, What does this give us that Solaris Cluster, RedHat Cluster, DRBD etc.. doesn't give us? Actually, these solutions all have some serious drawbacks, not the least of which is difficult administration (I speak from bitter personal experience). Also, most of them require installation at

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote: > > Being able to do read-only queries makes this feature more valuable in more > situations, but I disagree that it's a deal-breaker. Your managers are apparently more enlightened than some. ;-) A -- Andrew Sullivan [EMAIL PROTECTED]

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 07:20:37PM +0300, Marko Kreen wrote: > > So you can do lossless failover. Currently there is no good > solution for this. Indeed. Getting lossless failover would be excellent. I understand David's worry (having had those arguments more times than I care to admit), but i

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 02:13:26PM -0400, Andrew Sullivan wrote: > On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote: > > Being able to do read-only queries makes this feature more > > valuable in more situations, but I disagree that it's a > > deal-breaker. > > Your managers are apparent

Re: [HACKERS] Core team statement on replication in PostgreSQL

in this case too. So each slave just needs to report its own longest open tx as "open" to master. Yes, it bloats master but no way around it. Slaves should not report it every time or every transaction. Vacuum on master will ask them before doing a real work. -- Teodor Sigaev

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 12:19 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > That's not what Tom's email said, AIUI. "Synchronous" replication surely > means that the master and slave always have the same set of transactions > applied. Streaming <> synchronous. But streaming log shipping will allo

Re: [HACKERS] Core team statement on replication in PostgreSQL

Hi everyone, First of all, I'm absolutely delighted that the PG community is thinking seriously about replication. Second, having a solid, easy-to-use database availability solution that works more or less out of the box would be an enormous benefit to customers. Availability is the single bi

Re: [HACKERS] [PERFORM] Memory question on win32 systems

> On Thu, May 29, 2008 at 10:19 AM, Justin <[EMAIL PROTECTED]> wrote: > Quoting You "Also, postgresql doesn't as a rule cache 'results and queries'. > > Then what is the purpose of shared buffers if nothing is being reused is it > only used to keep track locks, changes and what is to being spooled

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 3:05 PM, Robert Hodges <[EMAIL PROTECTED]> wrote: > Third, you can't stop with just this feature. (This is the BUT part of the > post.) The use cases not covered by this feature area actually pretty > large. Here are a few that concern me: > > 1.) Partial replication. > 2

Re: [HACKERS] Core team statement on replication in PostgreSQL

Andrew Sullivan wrote: On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote: Being able to do read-only queries makes this feature more valuable in more situations, but I disagree that it's a deal-breaker. Your managers are apparently more enlightened than some. ;-) A No do

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Teodor Sigaev <[EMAIL PROTECTED]> wrote: > > in this case too. So each slave just needs to report its own longest > > open tx as "open" to master. Yes, it bloats master but no way around it. > > Slaves should not report it every time or every transaction. Vacuum on > master will ask

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote: > people are starting to get religion on this issue I would strongly > advocate a parallel effort to put in a change-set extraction API > that would allow construction of comprehensive master/slave > replication. You know, I gave a

Re: [HACKERS] Core team statement on replication in PostgreSQL

On 5/29/08, Tom Lane <[EMAIL PROTECTED]> wrote: > * The proposed approach is trying to get to "real" replication > incrementally. Getting rid of the loss window involved in file-by-file > log shipping is step one, and I suspect that step two is going to be > fixing performance issues in WAL re

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter wrote: > Either one of these would be great, but something that involves > machines that stay useless most of the time is just not going to work. Lots of people do use warm standby already anyway, just not based on mechanisms built into PostgreSQL. So defining away this need is comp

Re: [HACKERS] Core team statement on replication in PostgreSQL

Jeff Davis wrote: > It depends on what we mean by synchronous. Do we mean "the WAL record > has made it to the disk on the slave system," or "the WAL record has > been applied on the slave system"? DRBD, which is a common warm standby solution for PostgreSQL at the moment, provides various levels

Re: [HACKERS] Core team statement on replication in PostgreSQL

Merlin Moncure wrote: > Read only slave is the #1 most anticipated feature in the > circles I run with. Do these circles not know about slony and londiste? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

[HACKERS] Initial max_connections for initdb on FreeBSD.

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I've got a BSD system I work on that is jailed and has low shared memory settings. So low that I cannot even initdb to create a test 8.3.1 database. It tries to create template1 with shared_buffers of 50 and max_connections of 13. Is there any w

[HACKERS] replication hooks

On 5/29/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote: > > people are starting to get religion on this issue I would strongly > > advocate a parallel effort to put in a change-set extraction API > > that would allow construction of

Re: [HACKERS] Core team statement on replication in PostgreSQL

Joshua D. Drake wrote: > What does this give us that Solaris Cluster, RedHat Cluster, DRBD etc.. > doesn't give us? I personally think that DRBD is a fine solution. But it only runs on Linux. And Solaris Cluster isn't the same as DRBD. -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

Re: [HACKERS] Core team statement on replication in PostgreSQL

Andrew Sullivan <[EMAIL PROTECTED]> writes: > On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote: >> people are starting to get religion on this issue I would strongly >> advocate a parallel effort to put in a change-set extraction API >> that would allow construction of comprehensive ma

Re: [HACKERS] Core team statement on replication in PostgreSQL

Andrew Sullivan wrote: > The big missing piece is lossless failover.  People are currently > doing it with DRBD, various clustering things, &c., and those are > complicated to set up and maintain. Well, we'll see at the end of this (we hope) how a setup procedure of DRBD vs. PG warm standby works

Re: [HACKERS] Core team statement on replication in PostgreSQL

Mathias Brossard wrote: >  From what I gather from those slides it seems to me that the NTT solution > is synchronous not asynchronous. In my opinion it's even better, but I do > understand that others might prefer asynchronous. I'm going to speculate, > but I would think it should be possible (wit

Re: [HACKERS] Core team statement on replication in PostgreSQL

Tom Lane wrote: > We believe that the most appropriate base technology for this is > probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon. Now how do we get our hands on their code? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 3:59 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Merlin Moncure wrote: >> Read only slave is the #1 most anticipated feature in the >> circles I run with. > > Do these circles not know about slony and londiste? Sure. For various reasons mentioned elsewhere on this th

Re: [HACKERS] Core team statement on replication in PostgreSQL

Robert, 1.) Partial replication. 2.) WAN replication. 3.) Bi-directional replication. (Yes, this is evil but there are problems where it is indispensable.) 4.) Upgrade support. Aside from database upgrade (how would this ever really work between versions?), it would not support zero-downtime

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote: > David Fetter wrote: > > Either one of these would be great, but something that involves > > machines that stay useless most of the time is just not going to > > work. > > Lots of people do use warm standby already anyway, just not

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter <[EMAIL PROTECTED]> writes: > On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote: >> I think the consensus in the core team was that having synchronous >> log shipping in 8.4 would already be a worthwhile feature by itself. > If that was in fact the consensus of the core

Re: [HACKERS] Initial max_connections for initdb on FreeBSD.

Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I've got a BSD system I work on that is jailed and has low shared memory settings. So low that I cannot even initdb to create a test 8.3.1 database. It tries to create template1 with shared_buffers of 50 and max_conne

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 04:44:19PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote: > >> I think the consensus in the core team was that having > >> synchronous log shipping in 8.4 would already be a worthwhile >

Re: [HACKERS] Core team statement on replication in PostgreSQL

David Fetter wrote: > > What is your justification for denigrating this plan with that? Or > > are you merely complaining because we know we won't be all the way > > there in 8.4? > > Again, just my humble opinion, but given the stated goal, which I > agree with, I'd say it's worth holding up 8.4

Re: [HACKERS] replication hooks

On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote: > There is this tiny matter of replicating schema changes asynchronously, > but I suspect nobody actually cares. I know that Slony's users call this their number one irritant, so I have my doubts nobody cares. But maybe nobody cares

Re: [HACKERS] Core team statement on replication in PostgreSQL

David, I think the consensus in the core team was that having synchronous log shipping in 8.4 would already be a worthwhile feature by itself. If that was in fact the consensus of the core team, It is. and what I've been seeing from several core members in this thread makes that idea uncl

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 04:54:04PM -0400, Bruce Momjian wrote: > David Fetter wrote: > > > What is your justification for denigrating this plan with that? > > > Or are you merely complaining because we know we won't be all > > > the way there in 8.4? > > > > Again, just my humble opinion, but give

Re: [HACKERS] Core team statement on replication in PostgreSQL

Bruce Momjian <[EMAIL PROTECTED]> writes: > David Fetter wrote: >> Again, just my humble opinion, but given the stated goal, which I >> agree with, I'd say it's worth holding up 8.4 until some kind of >> out-of-the-box replication advances that goal, where Yet Another >> Toolkit Suitable For People

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 01:55:42PM -0700, Josh Berkus wrote: > David, > >>> I think the consensus in the core team was that having synchronous >>> log shipping in 8.4 would already be a worthwhile feature by itself. >> >> If that was in fact the consensus of the core team, > > It is. > >> and what

Re: [HACKERS] Core team statement on replication in PostgreSQL

David, I think having master-slave replication in the core using WAL is a *great* thing to do, doable, a good path to go on, etc., and I think it's worth holding up 8.4 until we have at least one actual out-of-the-box version of same. Ah, ok. Well, I can tell you that the core team is also un

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, May 29, 2008 at 01:39:29PM -0700, David Fetter wrote: > > I think the consensus in the core team was that having synchronous > > log shipping in 8.4 would already be a worthwhile feature by itself. > > If that was in fact the consensus of the core team, and what I've been > seeing from se

Re: [HACKERS] Core team statement on replication in PostgreSQL

Peter Eisentraut wrote: Mathias Brossard wrote: From what I gather from those slides it seems to me that the NTT solution is synchronous not asynchronous. In my opinion it's even better, but I do understand that others might prefer asynchronous. I'm going to speculate, but I would think it shou

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thursday 29 May 2008 12:13:20 Bruce Momjian wrote: > David Fetter wrote: > > On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote: > > > Josh Berkus wrote: > > > > Publishing the XIDs back to the master is one possibility. We > > > > also looked at using "spillover segments" for vacuum

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote: > > I would have thought the read only piece would have been more important than > the synchronous piece. In my experience readable slaves is the big selling > point in both Oracle and MySQL's implementations, and people are not nearly >

Re: [HACKERS] Core team statement on replication in PostgreSQL

Robert Treat <[EMAIL PROTECTED]> writes: > I would have thought the read only piece would have been more important than > the synchronous piece. In my experience readable slaves is the big selling > point in both Oracle and MySQL's implementations, and people are not nearly > as concerned if the

Re: [HACKERS] replication hooks

On 5/29/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote: > > There is this tiny matter of replicating schema changes asynchronously, > > but I suspect nobody actually cares. > > I know that Slony's users call this their number one irrit

Re: [HACKERS] intercepting WAL writes

>On Wed, May 28, 2008 at 8:30 PM, Mike <[EMAIL PROTECTED]> wrote: >> When you say a bit of decoding, is that because the data written to the logs >> is after the query parser/planner? Or because it's written in several >> chunks? Or? > >Because that's the actual recovery record. There is no SQL te

Re: [HACKERS] Core team statement on replication in PostgreSQL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd first want to applaud core decision: having bare PostgreSQL propose a reliable and simple to set-up synchronous replication solution is an excellent perspective! ... Le 29 mai 08 à 23:42, Robert Treat a écrit : I would have thought the

Re: [HACKERS] intercepting WAL writes

"Mike" <[EMAIL PROTECTED]> writes: > Is there another place in the code, I can get access to the statements (or > statement "like" information), after a transaction commit? No. Bear in mind that what you have decided to do amounts to rolling your own replication system. This is a Hard Problem.

Re: [HACKERS] Hint Bits and Write I/O

>>> On Wed, May 28, 2008 at 6:26 PM, in message <[EMAIL PROTECTED]>, "Florian G. Pflug" <[EMAIL PROTECTED]> wrote: > I think we should put some randomness into the decision, > to spread the IO caused by hit-bit updates after a batch load. Currently we have a policy of doing a VACUUM FREEZE AN

Re: [HACKERS] Core team statement on replication in PostgreSQL

Dimitri Fontaine <[EMAIL PROTECTED]> writes: > While at it, would it be possible for the "simple" part of the core > team statement to include automatic failover? No, I think it would be a useless expenditure of energy. Failover includes a lot of things that are not within our purview: switchin

Re: [HACKERS] Core team statement on replication in PostgreSQL

Joshua D. Drake wrote: On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote: I would have thought the read only piece would have been more important than the synchronous piece. In my experience readable slaves is the big selling point in both Oracle and MySQL's implementations, and peopl

Re: [HACKERS] replication hooks

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Yeah. The main problem is that unless you do WAL based replication, > you cannot achieve transparency. So you need to pick few use cases > and tailor you solution for them, which gets uninteresting very fast > - user _will_ stumble upon spac

Re: [HACKERS] Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 18:39 -0400, Andrew Dunstan wrote: > > Joshua D. Drake wrote: > > On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote: > > > > You must be gauging a different market from the one I'm in. I have just > come back from a meeting with a (quite technically savvy) customer w

  1   2   >