Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
while I agree that HS is very useful without SR, I think that it's
mostly the well known powerusers inthe community are actively waiting
for HS and not so much for SR. For the typical user outside of -hackers
or even
Robert Haas wrote:
If we're going to have any chance of getting
these patches in, we have to give the patch authors good feedback
early in the CommitFest so that they have time to make the necessary
revisions before the end of the CommitFest. If we think we can swing
it, I'm happy to handle thes
David E. Wheeler wrote:
> On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
>> No, I'm suggesting the mechanism needs to support source and binary
>> distribution. For most *nix users, source will be fine. For Windows
>> binaries are required.
>
> I would love to follow what Strawberry Perl has done to
On Thu, Jan 7, 2010 at 10:51 PM, Tom Lane wrote:
> Fair enough ;-). But I don't feel a need to make a decision now,
> either. We can at least wait a week and see if Heikki gets SR
> committed.
OK.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Robert Haas writes:
> On Thu, Jan 7, 2010 at 10:20 PM, Tom Lane wrote:
>> Looking at this list again, it strikes me that the listen/notify rewrite
>> might need to go in so that we have a sane framework for listen/notify
>> with HS.
> It's also related to this open issue, so possibly we could ki
On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
> Alex Hunsaker writes:
> We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in fork_process.c)
#ifdef LINUX
void oom_adjust()
{
...
}
#else
void oom_adjust() {}
#endif
So there is only one #if
On Thu, Jan 7, 2010 at 10:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK, we have a proposal on the table to bump some patches from this
>> CommitFest to free up more committer resources, particularly Tom, to
>> work on Hot Standby and Streaming Replication and attempt to
>> accelerate the pr
Alex Hunsaker writes:
> FWIW here is the patch I run. Stupid as the patch may be, count it as
> a +1 for people in the field doing this. Hence a reason to think
> about doing something in core. maybe.
Thanks for the patch --- it's certainly a fine starting point.
We can either drop this in co
Robert Haas writes:
> OK, we have a proposal on the table to bump some patches from this
> CommitFest to free up more committer resources, particularly Tom, to
> work on Hot Standby and Streaming Replication and attempt to
> accelerate the process of getting 8.5 out the door. This proposal
> need
On Tue, Jan 5, 2010 at 4:45 PM, Robert Haas wrote:
> On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Yep. It would also lower the barrier to future innovations of that
>>> type, which would be a good thing, IMO. Unfortunately we'd likely
>>> need to continue to supp
On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan wrote:
> This strikes me as quite premature. Heiki just said he expects to have SR
> committed next week.
Getting it committed is not what I'm worried about. What I'm
concerned about is Tom's statement that he believes that HS is not
close to being
On Thu, 2010-01-07 at 20:57 -0500, Robert Haas wrote:
> - Listen/Notify Rewrite.
> - Writeable CTEs.
...
> Votes?
I'm not qualified to vote on how other people spend their time, but here
are my thoughts:
SR was submitted quite some time ago, so I don't see it as breaking the
rules to put it first
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote:
> Hmm. Why would we use a GUC for this instead of an additional option
> to BEGIN TRANSACTION?
I'm with you. I feel pretty strongly that we should not have
behavior-changing GUCs.
I make an exception for compatibility GUCs where the eventual
* David Fetter (da...@fetter.org) wrote:
> > OK, we have a proposal on the table to bump some patches from this
> > CommitFest to free up more committer resources, particularly Tom, to
> > work on Hot Standby and Streaming Replication and attempt to
> > accelerate the process of getting 8.5 out the
Robert Haas wrote:
OK, we have a proposal on the table to bump some patches from this
CommitFest to free up more committer resources, particularly Tom, to
work on Hot Standby and Streaming Replication and attempt to
accelerate the process of getting 8.5 out the door. This proposal
needs input
On Thu, Jan 07, 2010 at 08:57:15PM -0500, Robert Haas wrote:
> On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
> >>> Robert Haas writes:
> I am tempted to say we should clamp down and go into damage control
>
>> I'm torn between thinking it would be good to spell it that way and
>> thinking that we should have "serializable_isolation_implementation"
>> GUC (or something to that effect) which maps to an enumeration
>> containing "snapshot" and "ssi". Opinions welcome, since I've put
>> that GUC at the t
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
>>> Robert Haas writes:
I am tempted to say we should clamp down and go into damage control
mode sooner rather than later.
>>>
>>> The more I see of the HS patch, t
On Thu, 2010-01-07 at 18:02 -0500, Robert Treat wrote:
> On Jan 7, 2010, at 5:18 PM, Simon Riggs wrote:
>
> > On Thu, 2010-01-07 at 16:56 -0500, Robert Treat wrote:
> >
> >> Not much more to send really.
> >
> > No problem. I can see what causes it, nothing more required, thanks.
> > What I don't
* Dave Page (dp...@pgadmin.org) wrote:
> Because if we (PostgreSQL) are going to support this effort, then it
> should not ignore such a huge percentage of our installation base.
Not doing it day 1 is not ignoring. It's using what resources *are*
being made available to the best extent we can. I
Bruce Momjian wrote:
> 2) Right now pg_migrator renames old tablespaces to .old, which fails
> if the tablespaces are on mount points. I have already received a
> report of such a failure. $PGDATA also has that issue, but that
> renaming has to be done by the user before pg_migrator is run, and
On Thu, Jan 07, 2010 at 03:32:28PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> >> No, I don't think so. �HS without SR means you still have to fool
> >> with setting up WAL-file-based replication, which despite the
> >> existence of pg_stan
Robert Haas wrote:
> I think so. I'm not sure if it will push out the comment that is
> immediately adjacent to the trailing semicolon, but I don't think it
> will decrease the indent on the ones you've indented more. I think
> this is close enough for now and you should go ahead and commit it
Robert Haas wrote:
> On Thu, Jan 7, 2010 at 5:41 PM, Bruce Momjian wrote:
> > It's my mailbox --- it is my time to decide when to look at it, or not.
>
> Absolutely.
>
> > There is nothing private about its contents.
>
> Understood.
>
> > You can do whatever you want with the release schedule.
* Josh Berkus (j...@agliodbs.com) wrote:
> What I'm getting from your e-mail, Dave, is "If it doesn't solve all
> problems for everyone in the world from Day 1, it's not worth doing."
> It's my experience that the way to get OSS software that works is to
> build a little bit at a time, each deliver
On Thu, Jan 7, 2010 at 5:41 PM, Bruce Momjian wrote:
> It's my mailbox --- it is my time to decide when to look at it, or not.
Absolutely.
> There is nothing private about its contents.
Understood.
> You can do whatever you want with the release schedule.
I should be so lucky. :-)
I'm sorry
On Mon, Jan 4, 2010 at 09:55, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Right. Which is why I like the idea of disabling the OOM killer for
>> the *postmaster*, but not the regular backends. Gives it a chance to
>> recover. It's not nice, but it's better than nothing.
>
> It doesn't soun
On Thu, Jan 7, 2010 at 15:16, Tim Bunce wrote:
> Is there any reason not to add .gitignore files into the repository?
> They'll make no difference to those who don't use git, but be very
> helpful to, and maintained by, those who do.
Since it seems we don't want them in CVS, maybe just add it to
On Thu, Jan 07, 2010 at 12:07:19PM -0800, David Wheeler wrote:
> Hackers,
>
> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
> extensions. I've tried to closely follow the [CPAN philosophy][] to
> come up with a plan that requires a minimum-work implementation that
> builds on th
On Thu, Jan 07, 2010 at 05:45:08PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
> >> Is there any reason not to add .gitignore files into the repository?
>
> > I already find the .cvsignore files to be useless and an annoyance to
> > ke
On Jan 7, 2010, at 5:18 PM, Simon Riggs wrote:
On Thu, 2010-01-07 at 16:56 -0500, Robert Treat wrote:
Not much more to send really.
No problem. I can see what causes it, nothing more required, thanks.
What I don't fully understand yet is why the error hasn't shown itself
before, because it
Jeff Davis wrote:
>> I'm torn between thinking it would be good to spell it that way
>> and thinking that we should have
>> "serializable_isolation_implementation" GUC (or something to that
>> effect) which maps to an enumeration containing "snapshot" and
>> "ssi". Opinions welcome, since I've
A.M. wrote:
On Jan 7, 2010, at 12:39 PM, Greg Sabino Mullane wrote:
I'm still *very* interested in making a libpq-less pure perl driver,
if anyone feels like funding it, let me know! :)
You mean this one:
http://search.cpan.org/~arc/DBD-PgPP-0.07/lib/DBD/PgPP.pm
?
It has a l
Peter Eisentraut writes:
> On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
>> Is there any reason not to add .gitignore files into the repository?
> I already find the .cvsignore files to be useless and an annoyance to
> keep up to date (well, I basically ignore them and someone else cleans
>
On Thu, 2010-01-07 at 16:27 -0600, Kevin Grittner wrote:
> Could you draft a proposed doc change? While my ideas have
> sometimes influenced the docs, my words don't tend to make it, so
> I'm probably not the best candidate to suggest something. (That's
> not actually a shocker for me, since I'm
On Jan 7, 2010, at 12:39 PM, Greg Sabino Mullane wrote:
> I'm still *very* interested in making a libpq-less pure perl driver,
> if anyone feels like funding it, let me know! :)
You mean this one:
http://search.cpan.org/~arc/DBD-PgPP-0.07/lib/DBD/PgPP.pm
?
Cheers,
M
--
Sent via pgsql-hackers
Robert Haas wrote:
> On Thu, Jan 7, 2010 at 4:03 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Bruce,
> >>
> >> Have you looked at this? ?Are there no other Open Items?
> >
> > I have 2k emails that I need to go through to see what I have kept as
> > open. ?I am working on pg_migrator stuff
Dimitri Fontaine writes:
> e.g. pg_execute_commands_from_file('path/ to/file.sql'). It would not
[...]
> Then you need to add a catalog for holding the extensions metadata, like
[...]
> Now you can hack a CREATE EXTENSION command to fill-in the catalog, and
> the commands INSTALL EXTENSION and DRO
On Thursday 07 January 2010 23:32:27 Peter Eisentraut wrote:
> On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
> > I've a .git/info/exclude file I pulled from a link on the dev wiki.
> >
> > Some of the changes I'm making create new files that ought to be added
> > to the excluded files. I can
On tor, 2010-01-07 at 17:18 -0500, Robert Haas wrote:
> On Thu, Jan 7, 2010 at 4:03 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Bruce,
> >>
> >> Have you looked at this? Are there no other Open Items?
> >
> > I have 2k emails that I need to go through to see what I have kept as
> > open.
On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
> I've a .git/info/exclude file I pulled from a link on the dev wiki.
>
> Some of the changes I'm making create new files that ought to be added
> to the excluded files. I can easily add them to my .git/info/exclude
> file but it's much more work
Jeff Davis wrote:
> I think we should document that REPEATABLE READ is SI, and >
> encourage people to use it rather than SERIALIZABLE if they want
> SI. Also, document that SERIALIZABLE may be changed in the future
> to be truly serializable, and that may have a performance penalty
> and cause
On Jan 7, 2010, at 2:23 PM, Dimitri Fontaine wrote:
> Maybe with a link to:
> http://www.postgresql.org/docs/8.4/static/extend.html
Good call, thanks.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
"David E. Wheeler" writes:
> On Jan 7, 2010, at 2:11 PM, Peter Eisentraut wrote:
>
>> You might want to clarify in your prose what an "extension" is. I
>> suspect I know what you mean, but perhaps not everyone does.
>
> Good suggestion, thanks. How about this in the FAQ?
>
> * WTF is an "extensi
On Thu, 2010-01-07 at 16:56 -0500, Robert Treat wrote:
> Not much more to send really.
No problem. I can see what causes it, nothing more required, thanks.
What I don't fully understand yet is why the error hasn't shown itself
before, because it appears such a basic error.
--
Simon Riggs
On Jan 7, 2010, at 2:11 PM, Peter Eisentraut wrote:
> You might want to clarify in your prose what an "extension" is. I
> suspect I know what you mean, but perhaps not everyone does.
Good suggestion, thanks. How about this in the FAQ?
* WTF is an "extension"?
An extension is a piece of softwar
On Thu, Jan 7, 2010 at 4:03 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Bruce,
>>
>> Have you looked at this? Are there no other Open Items?
>
> I have 2k emails that I need to go through to see what I have kept as
> open. I am working on pg_migrator stuff at the moment.
I am totally confu
I've a .git/info/exclude file I pulled from a link on the dev wiki.
Some of the changes I'm making create new files that ought to be added
to the excluded files. I can easily add them to my .git/info/exclude
file but it's much more work for me and others to spread those changes.
Is there any reas
On tor, 2010-01-07 at 12:07 -0800, David E. Wheeler wrote:
> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
> I've tried to closely follow the [CPAN philosophy][] to come up with a plan
> that requires a minimum-work implementation that builds on the existing
> Post
On Jan 7, 2010, at 1:59 PM, Joshua D. Drake wrote:
> So +1 on Wheeler's idea.
Thanks!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Building them is no problem - authors can easily use EC2 for which we
> have an AMI pre-configured for next to no cost, can build on their own
> platform, on a community provided system, or get a friend to do it.
So any module author, in order to submit any module, would be required
to build bin
Tom Lane writes:
> No, I don't think so. HS without SR means you still have to fool with
> setting up WAL-file-based replication, which despite the existence of
> pg_standby is a PITA. And you have to make a tradeoff of how often to
> flush WAL files to the standby. To be a real candidate for "
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>
>> Are we anywhere close to an agreement on what the multi-session
>> psql implementation would look like?
> See
>
http://archives.postgresql.org/message-id/8204.1207689...@sss.pgh.pa.us
> and followups.
Thanks, I had missed or forgotten this
On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
> Given that each of these would be the best choice for some
> transaction mixes, it might make sense to allow some mapping of the
> four ANSI transaction isolation levels to strategies for
> implementation. At the risk of generating some ba
Robert Haas writes:
> Hmm. There's something to what you say, but what about the people who
> were expecting their patches to be reviewed and perhaps committed in
> the forthcoming CommitFest. I proposed a schedule for this release
> that involved only three CommitFests and it was rejected, so i
On Thu, 2010-01-07 at 15:01 -0600, Kevin Grittner wrote:
> As I understand it, Greg's line of thinking is that we should use a
> technique which has never proven practical on a large scale:
> matching database changes against a list of predicate lock
> expressions. It's not that I want to do it an
On Thu, 2010-01-07 at 13:22 -0800, Josh Berkus wrote:
> Dave,
> What I'm getting from your e-mail, Dave, is "If it doesn't solve all
> problems for everyone in the world from Day 1, it's not worth doing."
I doubt that is Dave's intent because then we might as well stop work on
PostgreSQL too.
>
On Jan 7, 2010, at 4:15 PM, Simon Riggs wrote:
On Thu, 2010-01-07 at 14:41 -0500, Robert Treat wrote:
Doing some testing with 8.5alpha3, my standby crashed this morning
whilst
doing some testing. Seems I have a core file, so thought I would
send a report.
Version: PostgreSQL 8.5alpha3 on
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
> Andres Freund writes:
> > I did not want to suggest using Simons code there. Sorry for the brevity.
> > should have read as "revert to old code and add two step killing (thats
> > likely around 10 lines or so)".
> >
> > "two step killing" mean
Dave Page writes:
> We have discussed this sort of facility at previous developer
> meetings, and as I recall came to the conclusion that we need to have
> the ability to distribute pre-built binaries, not just source code as
> virtually no Windows users are ever going to have a build environment
On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
> No, I'm suggesting the mechanism needs to support source and binary
> distribution. For most *nix users, source will be fine. For Windows
> binaries are required.
I would love to follow what Strawberry Perl has done to solve this problem. In
2.0.
B
On Thu, Jan 7, 2010 at 9:22 PM, Josh Berkus wrote:
> Dave,
>
>> Whilst the aim is a noble one, glossing over 'it won't work on
>> Windows' which is by far our most popular platform these days seems
>> incredibly short sighted, and liable to lead to an endless stream of
>> 'why doesn't this work' q
On Jan 7, 2010, at 12:36 PM, Dave Page wrote:
> Whilst the aim is a noble one, glossing over 'it won't work on
> Windows' which is by far our most popular platform these days seems
> incredibly short sighted, and liable to lead to an endless stream of
> 'why doesn't this work' questions. It also d
Greg Stark wrote:
> On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner
> wrote:
>> No, it's an attempt to reflect the difference in costs for true
>> serializable transactions, so that the optimizer can choose a
>> plan appropriate for that mode, versus some other. In
>> serializable transaction iso
Andres Freund writes:
> I did not want to suggest using Simons code there. Sorry for the brevity.
> should have read as "revert to old code and add two step killing (thats
> likely
> around 10 lines or so)".
> "two step killing" meaning that we signal ERROR for a few times and if
> nothing
>
Robert Haas writes:
> On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I am tempted to say we should clamp down and go into damage control
>>> mode sooner rather than later.
>>
>> The more I see of the HS patch, the more I think the same. But my
>> proposal for "damag
Dave,
> Whilst the aim is a noble one, glossing over 'it won't work on
> Windows' which is by far our most popular platform these days seems
> incredibly short sighted, and liable to lead to an endless stream of
> 'why doesn't this work' questions. It also does the module authors no
> favours, by
On Thu, 2010-01-07 at 16:05 -0500, Tom Lane wrote:
> Robert Treat writes:
> > Doing some testing with 8.5alpha3, my standby crashed this morning whilst
> > doing some testing. Seems I have a core file, so thought I would send a
> > report.
>
> Hmm. Looks like it's crashing because DatabasePath
On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner
wrote:
> No, it's an attempt to reflect the difference in costs for true
> serializable transactions, so that the optimizer can choose a plan
> appropriate for that mode, versus some other. In serializable
> transaction isolation there is a higher co
On Thursday 07 January 2010 21:47:47 Tom Lane wrote:
> Andres Freund writes:
> > The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code
> > path was that it should allow a relatively "natural" handling of
> > canceling "IDLE IN TRANSACTION" queries without doing anything in the
> >
On Thu, 2010-01-07 at 14:41 -0500, Robert Treat wrote:
> Doing some testing with 8.5alpha3, my standby crashed this morning whilst
> doing some testing. Seems I have a core file, so thought I would send a
> report.
>
> Version: PostgreSQL 8.5alpha3 on i386-pc-solaris2.10, compiled by GCC gcc
>
On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> I am tempted to say we should clamp down and go into damage control
>> mode sooner rather than later.
>
> The more I see of the HS patch, the more I think the same. But my
> proposal for "damage control mode" would be to im
Tom Lane wrote:
> Heikki Linnakangas writes:
>> But FWIW I have dedicated today and tomorrow for SR, and plan to
>> dedicate 2-3 days next week as well.
>
> So you carefully avoided answering the question: when do you think it
> might be committable?
:-). I was hoping to commit it by the end of
Robert Haas wrote:
> thinking that fudging the tuple cost GUCs is going to work seems
> unrealistically optimistic. If you need the optimizer to know
> about this, you need the optimizer to REALLY know about this...
I rule nothing out. If you have a more refined idea, I welcome you
to includ
Robert Treat writes:
> Doing some testing with 8.5alpha3, my standby crashed this morning whilst
> doing some testing. Seems I have a core file, so thought I would send a
> report.
Hmm. Looks like it's crashing because DatabasePath is not set yet.
We could probably kluge around that by having
Josh Berkus wrote:
> Bruce,
>
> Have you looked at this? Are there no other Open Items?
I have 2k emails that I need to go through to see what I have kept as
open. I am working on pg_migrator stuff at the moment.
--
Bruce Momjian http://momjian.us
EnterpriseDB
David E. Wheeler wrote:
> Hackers,
>
> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
> extensions. I've tried to closely follow the [CPAN philosophy][] to
> come up with a plan that requires a minimum-work implementation that
> builds on the existing PostgreSQL tools and the exa
Jeff Davis wrote:
> Consider an exclusion constraint, which is a kind of predicate
> lock. You could say that the lock is in the index (now) -- but my
> first implementation used a shared memory structure instead, so
> it's clearly not required to exist in the index. You could also
> say that th
On Thu, Jan 7, 2010 at 3:43 PM, Kevin Grittner
wrote:
> "Albe Laurenz" wrote:
>> Kevin Grittner wrote:
>>> Another interesting thing which crossed my mind (and I should
>>> probably add a section for such things in the wiki) is that,
>>> given the overhead and conflict implications of using table
On Thu, 2010-01-07 at 15:49 -0500, Andrew Dunstan wrote:
> Right. As someone engaged in the marketplace, I can tell you that
> IMNSHO it is almost impossible to overstate the importance of getting
> both of these features. We will suffer an enormous loss of face and
> respect if we don't.
+1. T
Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> >> No, I don't think so. ?HS without SR means you still have to fool with
> >> setting up WAL-file-based replication, which despite the existence of
> >> pg_standby is a PITA. ?And you have to make a tra
On Thu, Jan 7, 2010 at 8:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> I am tempted to say we should clamp down and go into damage control
>> mode sooner rather than later.
>
> The more I see of the HS patch, the more I think the same. But my
> proposal for "damage control mode" would be to im
On Thu, Jan 7, 2010 at 7:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> That may well be so, but adding another one is not going to improve
>> the situation even a little bit. I don't think what you're saying
>> weakens in the slightest the argument that I was making, namely, that
>> if this is
Tom Lane wrote:
[ shrug... ] To me, HS+SR is actual replication, which would justify
tagging this release 9.0. With only one of them, it's 8.5. I
understand that there are power users who would find HS alone to be
tremendously useful, but in terms of what the average user sees, there's
a qu
On Thu, Jan 7, 2010 at 21:42, Joshua D. Drake wrote:
> On Thu, 2010-01-07 at 20:36 +, Dave Page wrote:
>> On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler
>> wrote:
>> > Hackers,
>> >
>> > I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
>> > extensions. I've tried to closel
Andres Freund writes:
> The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code path
> was
> that it should allow a relatively "natural" handling of canceling "IDLE IN
> TRANSACTION" queries without doing anything in the interrupt handler.
> I think it shouldn't be to hard to mak
"Albe Laurenz" wrote:
> Kevin Grittner wrote:
>> Another interesting thing which crossed my mind (and I should
>> probably add a section for such things in the wiki) is that,
>> given the overhead and conflict implications of using table scans
>> in serializable transactions, we should perhaps try
On Thu, 2010-01-07 at 20:36 +, Dave Page wrote:
> On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler wrote:
> > Hackers,
> >
> > I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
> > extensions. I've tried to closely follow the [CPAN philosophy][] to come up
> > with a plan that
On Thu, 2010-01-07 at 15:02 -0500, Robert Haas wrote:
> > I think we're still talking past the issue. Predicate locks are not
> > row level, nor page level, nor table level.
>
> They're not? They're just floating out in space somewhere? There are
> several possible ways to implement predicate lo
On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler wrote:
> Hackers,
>
> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
> I've tried to closely follow the [CPAN philosophy][] to come up with a plan
> that requires a minimum-work implementation that builds on the exist
Robert Haas writes:
> I am tempted to say we should clamp down and go into damage control
> mode sooner rather than later.
The more I see of the HS patch, the more I think the same. But my
proposal for "damage control mode" would be to immediately punt
everything else to the next release and foc
Heikki Linnakangas writes:
> Josh Berkus wrote:
>> Yes. I think there's tremendous value to PG if we could get HS+SR into
>> 8.5. And I know that SR is what Heikki is working on exclusively.
> That hasn't been true for some time, I haven't spent very much time on
> SR recently. Not enough, real
Magnus Hagander writes:
> On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
>> No, I don't think so. HS without SR means you still have to fool with
>> setting up WAL-file-based replication, which despite the existence of
>> pg_standby is a PITA. And you have to make a tradeoff of how often to
>> f
On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>>> However, HS is already in the tree, and HS without SR is a whole lot
>>> less compelling than HS with SR. So it's going to be pretty
>>> unsatisfying if we can't get SR in there.
>
>> I don't think that's the case.
"Greg Sabino Mullane" writes:
>> However, HS is already in the tree, and HS without SR is a whole lot
>> less compelling than HS with SR. So it's going to be pretty
>> unsatisfying if we can't get SR in there.
> I don't think that's the case. Having HS alone would be a huge win,
> and the sooner
On Jan 7, 2010, at 12:10 PM, Heikki Linnakangas wrote:
> But FWIW I have dedicated today and tomorrow for SR, and plan to
> dedicate 2-3 days next week as well.
Should we then await what you determine over the next week?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Josh Berkus wrote:
> Yes. I think there's tremendous value to PG if we could get HS+SR into
> 8.5. And I know that SR is what Heikki is working on exclusively.
That hasn't been true for some time, I haven't spent very much time on
SR recently. Not enough, really.
But FWIW I have dedicated today
Hackers,
I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
I've tried to closely follow the [CPAN philosophy][] to come up with a plan
that requires a minimum-work implementation that builds on the existing
PostgreSQL tools and the examples of the [CPAN][] and [JSAN][
On Thursday 07 January 2010 20:58:10 Heikki Linnakangas wrote:
> Robert Haas wrote:
> > Are there
> > really no other open issues for 8.5? That would be great, but I am
> > concerned that there may be other things that people just haven't
> > gotten around to mentioning yet.
>
> Well, there's sti
On Thu, 2010-01-07 at 14:41 -0500, Robert Treat wrote:
> Doing some testing with 8.5alpha3, my standby crashed this morning whilst
> doing some testing. Seems I have a core file, so thought I would send a
> report.
Thanks for the report.
--
Simon Riggs www.2ndQuadrant.com
--
Sen
1 - 100 of 225 matches
Mail list logo
