Tom Lane wrote:
> The idea of input functions that alter system tables scares me.
An example:
SELECT 'system_u:object_r:sepgsql_table_t:SystemHigh'::security_label;
can insert a new tuple into pg_security, but it is not a desirable behavior.
To fix this, I'll remove security_label type and def
Greg Smith <[EMAIL PROTECTED]> writes:
> I fully accept that it may be the case that it doesn't make technical
> sense to tackle them in any order besides sync->read-only slaves because
> of dependencies in the implementation between the two.
Well, it's certainly not been my intention to suggest
Josh Berkus wrote:
Greg,
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync->read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it would be nice to explicitly spell out what
On Thu, May 29, 2008 at 9:26 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
>> I fully accept that it may be the case that it doesn't make technical
>> sense to tackle them in any order besides sync->read-only slaves because
>> of dependencies in the implementation between the two. If that's the
>> ca
On Thu, May 29, 2008 at 07:02:56PM -0400, Tom Lane wrote:
> People want the bits to go from point A to point B; they don't want
> to have to research, design, test, and administer their own solution
> for moving the bits.
I agree with this. I think I probably know as well as most people --
per
Greg Sabino Mullane wrote:
there another way around this problem that can be somewhat
automated?
I don't think so. This is a particular case. So my advice is to hack
test_config_settings() and add your custom values to trial_conns[] and
trial_bufs[].
--
Euler Taveira de Oliveira
http:/
Greg,
> I fully accept that it may be the case that it doesn't make technical
> sense to tackle them in any order besides sync->read-only slaves because
> of dependencies in the implementation between the two. If that's the
> case, it would be nice to explicitly spell out what that was to deflect
Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
O.k. I was with you until here. Log shipping ala pg_standby works fine
now sans read-only slave. No, it isn't out of the box which I can see an
argument for b
* Tom Lane <[EMAIL PROTECTED]> [080529 20:22]:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > I think maybe my actual argument isn't coming through. What I am arguing
> > for is not shipping XY without Z. That is all. (and no, I don't think we
> > should hold up 8.4).
>
> So we should keep al
On Thu, 29 May 2008, Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
This is a key statement that highlights the difference in how you're
thinking about this compared to some other people here. As far as s
On Thu, May 29, 2008 at 7:12 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
>> I think we have nontrivial
>> work in front of us to build a simple, reliable, community-tested
>> log shipping solution; and it's not very sexy work either. But it
Is there a reason that we can't add a trigger to a table while a
select is running? This is a serious pain when trying to setup
londiste or slony.
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
smime.
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I think maybe my actual argument isn't coming through. What I am arguing
> for is not shipping XY without Z. That is all. (and no, I don't think we
> should hold up 8.4).
So we should keep all the work out of the tree until every part is done?
No tha
[EMAIL PROTECTED] (Tom Lane) writes:
> As I said originally, we have no expectation that the proposed features
> will displace the existing replication projects for "high end"
> replication problems ... and I'd characterize all of Robert's concerns
> as "high end" problems. We are happy to let tho
Jorgen Austvik - Sun Norway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The RPM packages have done this since approximately forever. You might
>> want to look at the patches used there.
> yes [1] is the same that we have been using internally.
> Let me reformulate my question: would it be b
On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > One customer does not make a hundred. I am not saying that the shipping
> > isn't valid, just that those that I talk to are more interested in the
> > read only slave. Consider that we have any
This is a proposal of a non-standard, albeit useful functionality in
Postgres (it is also a quite long email message).
Background:
I'm currently working on a GSoC project for PostgreSQL
(http://wiki.postgresql.org/wiki/Gsoc08-tss). But at the same time, I'm
now at the point where I need to cho
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> One customer does not make a hundred. I am not saying that the shipping
> isn't valid, just that those that I talk to are more interested in the
> read only slave. Consider that we have any number of ways to solve the
> problem we are considering impl
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
-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
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
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
>>> 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
"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.
-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
>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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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]
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
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
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
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
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
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.
-
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
* 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
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
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
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
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
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
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
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
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
* 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
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'
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
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
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
* 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
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
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
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
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
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:
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-
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
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
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
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
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,
1 - 100 of 118 matches
Mail list logo
