Hi,
On Mon, Jan 12, 2009 at 1:10 AM, Simon Riggs wrote:
>> > Multiple standby is still possible, but just using old file based
>> > mechanisms. We would need to be careful about use of %R in that case.
>>
>> Yes. Synch Rep can work fine with existing warm-standby mechanism.
>
> If we want multipl
Hi,
On Tue, Jan 13, 2009 at 10:52 AM, Robert Haas wrote:
>> IMHO, the synchronous replication isn't in such good shape, I'm afraid. I've
>> said this before, but I'm not happy with the "built from spare parts" nature
>> of it. You shouldn't have to configure an archive, file-based log shipping
>>
Hi,
On Tue, Jan 13, 2009 at 3:32 AM, Robert Haas wrote:
> One thing I find interesting is that the "Infrastructure Changes for
> Recovery" patch became the foundation for both "Hot Standby" and
> "Synchronous Replication". That implies that those changes might be
> of somewhat more general inter
I updated patch set of SE-PostgreSQL and related stuff (r1403).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1403.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1403.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy
Tom Lane wrote:
> I'm thinking make_var is not the place to do this. The places that are
> supposed to be taking care of permissions are the ones that do this:
>
> /* Require read access --- see comments in setTargetTable() */
> rte->requiredPerms |= ACL_SELECT;
Indee
Hi,
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I've a question and ideas.
Bruce's modification directly points to my pgfoundry page. I'm not
sure what it means. Does it mean that I h
KaiGai Kohei writes:
> I reconsidered the previous walker implementation independent
> from other parser codes is more simple and better.
And slower, and equally subject to this bug, so I'm not convinced.
> Stephen, Tom, what is your opinion?
I'm thinking make_var is not the place to do this.
> I am just explaining how it works in practice. If the patch is still
> being improved, the feeling is that the author wants more time to adjust
> things, and with other things on our plate, we are glad to leave their
> patch until last.
Well, it's good that you have an explanation, but I'm not
I can find a matter on JOIN.
Please make sure the following function invocation chain:
transformSelectStmt()
-> transformFromClause()
-> transformFromClauseItem()
-> expandRTE(), if JoinExpr
-> expandRelation(), if rte->rtekind == RTE_RELATION
-> expandTupleDesc()
expandTupleDesc(
Stephen,
The revised patch can reproduce the original matter, as follows:
postgres=# CREATE TABLE t1 (a int, b text);
CREATE TABLE
postgres=# CREATE TABLE t2 (x int, y text);
CREATE TABLE
postgres=# GRANT select(a) on t1 to ymj;
GRANT
postgres=# GRANT select(x,y) on t2 TO ymj;
GRA
On Mon, Jan 12, 2009 at 2:05 PM, Heikki Linnakangas
wrote:
> Well, I've been keeping an eye on both Hot Standby and Synchronous
> Replication patches. IMHO the Hot Standby patch is architecturally sound,
> and while I suggested some pretty big changes just recently (which Simon
> picked up and did
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
---
Andrew Chernow wrote:
> for anyone interested
>
> Solaris 2.5.1 with --enable-thread-safety
>
>
Gregory Stark writes:
> Bruce Momjian writes:
>> As for the process used, I think it is useful to understand how
>> committers choose what to work on next. ...
> It's not just "unfair". It's counter-productive. It means you're ignoring the
> very patches whose authors are mostly likely to be res
Gregory Stark wrote:
> > Now, maybe this is unfair to patches that are frequently updated, but
> > this is the typical process we follow, and it explains why the patches
> > above have not gotten near commit status yet.
>
> It's not just "unfair". It's counter-productive. It means you're ignoring
> I feel no need to encourage people to send huge patches uncompressed ;-)
> gzip normally gets at least 3x or 4x on large diffs. So a limit around
> 250K ought to be enough.
To paraphrase a leading authority on PostgreSQL development, and with
tongue firmly in cheek, there's something to what yo
Bruce Momjian writes:
> As for the process used, I think it is useful to understand how
> committers choose what to work on next. One criteria is that the patch
> has stabilized; if a patch is still be modified regularly, the
> committer might as well work on another patch that has stabilized.
Alvaro Herrera writes:
> This was fixed on 1.84 of formatting.c for 8.0 (but not backpatched for
> no apparent reason), which also changed some other stuff in that file.
> The complete patch is attached.
I dunno why I didn't back-patch that; feel free to do so. Better do the
whole thing, because
On Mon, Jan 12, 2009 at 08:12:46PM -0500, Tom Lane wrote:
> 250K ought to be enough.
...for anybody ;)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider dona
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> David Fetter writes:
>>> 1. Remove the messages size limits on -hackers. They serve no useful
>>> purpose, and they interfere with our development process.
>>
>> Agreed, or at least boost it up a good bit more.
> the question really is how muc
Bruce Momjian wrote:
> In thinking about how to communicate to users about reducing continuous
> archiving storage requirements, I realized we don't mention pglesslog in
> our official documentation.
>
> The attached patch documents how to use pglesslog and gzip/gunzip to
> reduce storage requirem
Andreas 'ads' Scherbaum wrote:
>
> Hello all,
>
> On Mon, 12 Jan 2009 22:55:32 +0100 Andreas 'ads' Scherbaum wrote:
>
> > I tracked the problem done to the function str_numth() in
> > src/backend/utils/adt/formatting.c. The fix (attached) is easy: i
> > stole the function code from the latest 8.
Tom Lane wrote:
> "Christopher Browne" writes:
> > On Mon, Jan 12, 2009 at 12:27 PM, Dave Page wrote:
> >> On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane wrote:
> >>> In general, we have always regretted it in the past when we chose to
> >>> slip a release waiting for a specific feature...
> >>
> >>
>> > No. A developer can delete, move and rebase branches in his own
>> > repository as he likes, and all of those operations "modify
>> > history". In fact, a developer can completely destroy or take
>> > offline his published repository. It's *not* an archive.
>
> We could do this using git's co
Hello all,
On Mon, 12 Jan 2009 22:55:32 +0100 Andreas 'ads' Scherbaum wrote:
> I tracked the problem done to the function str_numth() in
> src/backend/utils/adt/formatting.c. The fix (attached) is easy: i
> stole the function code from the latest 8.0 version which looks fare
> more sane in handl
Andreas 'ads' Scherbaum writes:
> I tracked the problem done to the function str_numth() in
> src/backend/utils/adt/formatting.c. The fix (attached) is easy: i
> stole the function code from the latest 8.0 version which looks fare
> more sane in handling the string pointers.
I think you attached
Hello,
even if 7.4 is almost at the end of it's lifetime i found a bug/problem
on a fairly new laptop (not surprising: during upgrade tests). All
timestamp regression tests failed, only "th" was emitted.
I tracked the problem done to the function str_numth() in
src/backend/utils/adt/formatting.c
>>> "Joshua D. Drake" wrote:
> Who has integrated multi-master (transaction and power outage safe)
> replication now?
As far as I recall, nobody there was that specific about the form of
it. PostgreSQL arguably has non-integrated multi-master replication
now, and I've seen log-based implementa
On Mon, 2009-01-12 at 15:07 -0600, Kevin Grittner wrote:
> >>> "Dave Page" wrote:
> > project that aims to provide it's users with useful features. We
> > have two extremely useful features here (hot standby and sync
> > replication) which together will make this a killer release for many
> > peo
On Mon, 2009-01-12 at 16:02 -0500, Robert Haas wrote:
> > However I can say I would be fairly annoyed if everytime I checked
> > hackers I was pulling down 5 megs in various patches.
>
> Oh... really? I thought we were past the day when anyone cared how
> large the attachments were.
IMO the fact
>>> "Dave Page" wrote:
> project that aims to provide it's users with useful features. We
> have two extremely useful features here (hot standby and sync
> replication) which together will make this a killer release for many
> people
Without taking any particular position on this one way or the
> However I can say I would be fairly annoyed if everytime I checked
> hackers I was pulling down 5 megs in various patches.
Oh... really? I thought we were past the day when anyone cared how
large the attachments were.
At any rate, if we increased the limit from 100k to 1M, you could
conceivabl
On Mon, 2009-01-12 at 21:35 +0100, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > David Fetter writes:
> >> Two things to fix this, and several other problems:
> >
> >> 1. Remove the messages size limits on -hackers. They serve no useful
> >> purpose, and they interfere with our development
Tom Lane wrote:
David Fetter writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
the question really i
On Mon, Jan 12, 2009 at 12:20 PM, Joshua D. Drake
wrote:
>
> IMO, the reasons to delay a release:
>
> Our grammar looks like MySQL
>
mmm... you mean if we add things like VALUES statement, lastval() and
things like that? ;)
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
As
>> I think the problems it would solve for us are (1) emailing huge
>> patches around sucks (it sucks unnecessarily because of the
>> mailing-list size limit, but even if someone fixes that, it still
>> sucks), (2) no need for a CVS-to-GIT conversion that may incur dirty
>> reads; (3) retention of
On Mon, Jan 12, 2009 at 02:36:08PM -0500, Robert Haas wrote:
> On Mon, Jan 12, 2009 at 1:43 PM, Heikki Linnakangas
> wrote:
> > Robert Haas wrote:
> >> git IS a stable archive of what the patches really were.
> >
> > No. A developer can delete, move and rebase branches in his own
> > repository as
On Mon, 2009-01-12 at 14:33 -0500, Aidan Van Dyk wrote:
> * Joshua D. Drake [090112 14:22]:
> > > No. A developer can delete, move and rebase branches in his own
> > > repository as he likes, and all of those operations "modify history". In
> > > fact, a developer can completely destroy or take
On Mon, Jan 12, 2009 at 1:43 PM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> git IS a stable archive of what the patches really were.
>
> No. A developer can delete, move and rebase branches in his own repository
> as he likes, and all of those operations "modify history". In fact, a
> devel
On Mon, 2009-01-12 at 14:31 -0500, Robert Haas wrote:
> > Actually yes we did. There was a bug in git-cvs that we fixed. Its is
> > talked about here:
> > Actually the work is relatively minimal as we have git infrastructure in
> > place. The larger problem is:
> >
> > What is the problem we are t
> Actually yes we did. There was a bug in git-cvs that we fixed. Its is
> talked about here:
>
> http://archives.postgresql.org/pgsql-www/2008-12/msg00182.php
>
> But... that wasn't really the fault of git.
OK, but that's in the past now - good. I thought Tom was saying that
it might need to be d
* Joshua D. Drake [090112 14:22]:
> > No. A developer can delete, move and rebase branches in his own
> > repository as he likes, and all of those operations "modify history". In
> > fact, a developer can completely destroy or take offline his published
> > repository. It's *not* an archive.
>
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If that's what you want then you run the transaction in serializable
>> mode.
> If you run this at SERIALIZABLE transaction isolation level, would
> PostgreSQL currently roll something back before returning rows in an
> order different than that sp
On Mon, Jan 12, 2009 at 6:04 PM, Tom Lane wrote:
> "Dave Page" writes:
>> On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake
>> wrote:
>>> Well its really nobody's fault except the hacker that didn't step up to
>>> do the work. I believe all hackers have already been working diligently.
>
>> They
On Mon, 2009-01-12 at 20:43 +0200, Heikki Linnakangas wrote:
> Robert Haas wrote:
> > git IS a stable archive of what the patches really were.
>
> No. A developer can delete, move and rebase branches in his own
> repository as he likes, and all of those operations "modify history". In
> fact, a
Robert Haas wrote:
git IS a stable archive of what the patches really were.
No. A developer can delete, move and rebase branches in his own
repository as he likes, and all of those operations "modify history". In
fact, a developer can completely destroy or take offline his published
reposito
On Mon, 2009-01-12 at 13:35 -0500, Tom Lane wrote:
> I think the behavior Lee is expecting is only implementable with a
> full-table write lock, which is exactly what FOR UPDATE is designed
> to avoid. There are certain properties you don't get with a partial
> lock, and in the end I think we can'
Robert Haas wrote:
That's happened more than once, though my memory of details is fuzzy
and I don't have time to troll the archives for them right now.
Maybe Bruce can remember without a lot of searching. But our current
policy of time-based releases (ie deadlines) is born of hard experience
wit
>>> Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> A re-sort after locking doesn't really make things all nice and
>>> intuitive either.
>
>> Would it make any sense to roll back and generate a
>> SERIALIZATION_FAILURE?
>
> If that's what you want then you run the transact
On Mon, 2009-01-12 at 14:35 -0400, Jeff Davis wrote:
> ate: Mon, 12 Jan 2009 09:52:00 -0800
> On Mon, 2009-01-12 at 08:32 -0500, Tom Lane wrote:
> > That code has been working like this for eight or ten years now and
> this
> > is the first complaint, so taking away functionality on the grounds
>
"Kevin Grittner" writes:
> Tom Lane wrote:
>> A re-sort after locking doesn't really make things all nice and
>> intuitive either.
> Would it make any sense to roll back and generate a
> SERIALIZATION_FAILURE?
If that's what you want then you run the transaction in serializable
mode. The poin
>>> Tom Lane wrote:
> A re-sort after locking doesn't really make things all nice and
> intuitive either. Suppose that the values of X are 10,20,30,40,50
> and we do SELECT ... ORDER BY x LIMIT 3 FOR UPDATE. Concurrently
> someone updates the 20 to 100. The existing code locks the 10,20,30
> r
Euler Taveira de Oliveira escribió:
> Alvaro Herrera escreveu:
> > Alvaro Herrera escribió:
> >
> >> I have a separate branch on which I keep the old patch from Euler
> >> updated to the current reloptions code; so it is probably very similar
> >> to what Euler just sent. (I'll have a look at tha
On Mon, 2009-01-12 at 13:04 -0500, Tom Lane wrote:
> Simon didn't ramp up
> his effort until around September IIRC.
The main topic of snapshot creation was being discussed at PGcon in May
and another sponsors got serious then. I started working on a coherent
detailed design in July, but didn't
"Robert Haas" writes:
> On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane wrote:
>> That code has been working like this for eight or ten years now and this
>> is the first complaint, so taking away functionality on the grounds that
>> someone might happen to update the ordering column doesn't seem like
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
> >> No, git really does help with this. If Simon were making his changes
> >> in git and pushing them to a git branch on git.postgresql.org, you
> >> would be able to see exactly what he changed and when he changed it.
> >
> > Well, if that's
> That's happened more than once, though my memory of details is fuzzy
> and I don't have time to troll the archives for them right now.
> Maybe Bruce can remember without a lot of searching. But our current
> policy of time-based releases (ie deadlines) is born of hard experience
> with the negat
Please commit soon
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> The hot standby patch has some hacks to decide which full-page-images
> can be restored holding an exclusive lock and which ones need a
> vacuum-strength lock. It's not very pretty as is, as mentioned in
> com
>> No, git really does help with this. If Simon were making his changes
>> in git and pushing them to a git branch on git.postgresql.org, you
>> would be able to see exactly what he changed and when he changed it.
>
> Well, if that's actually an archival repository then it would work.
> But wasn't
"Christopher Browne" writes:
> On Mon, Jan 12, 2009 at 12:27 PM, Dave Page wrote:
>> On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane wrote:
>>> In general, we have always regretted it in the past when we chose to
>>> slip a release waiting for a specific feature...
>>
>> I don't recall such a time -
Alvaro Herrera escreveu:
> Alvaro Herrera escribió:
>
>> I have a separate branch on which I keep the old patch from Euler
>> updated to the current reloptions code; so it is probably very similar
>> to what Euler just sent. (I'll have a look at that soon anyway.)
>
> Huh, nevermind -- I thought
"Robert Haas" writes:
>> This is a red herring, unless your proposal also includes making the
>> master CVS^H^H^Hgit repository world-writable. The complaint I have
>> about people posting URLs is that there's no stable archive of what the
>> patches really were, and just because it came out of s
On Mon, Jan 12, 2009 at 5:30 PM, Joshua D. Drake wrote:
> On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
>
>> > In general, we have always regretted it in the past when we chose to
>> > slip a release waiting for a specific feature...
>>
>> I don't recall such a time - though perhaps the last
"Dave Page" writes:
> On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake
> wrote:
>> Well its really nobody's fault except the hacker that didn't step up to
>> do the work. I believe all hackers have already been working diligently.
> They have - but I see no reason why an imperfect process shoul
On Mon, 2009-01-12 at 12:47 -0500, Robert Haas wrote:
> If the only case where ORDER BY + FOR UPDATE are not strictly
> compatible is when the columns being updated are the same as the
> columns of the sort, a blanket prohibition against using the two
> together seems like it prohibits an awful lot
Robert Haas wrote:
>>> 2. Start using more git...
>> This is a red herring, unless your proposal also includes making the
>> master CVS^H^H^Hgit repository world-writable. The complaint I have
>> about people posting URLs is that there's no stable archive of what the
>> patches really were, and j
On Mon, 2009-01-12 at 08:32 -0500, Tom Lane wrote:
> That code has been working like this for eight or ten years now and this
> is the first complaint, so taking away functionality on the grounds that
> someone might happen to update the ordering column doesn't seem like the
> answer to me.
>
If
On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I can see two ways forward:
>
>> 1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
>> results, or
>
>> 2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
>> clauses. (There wo
On Mon, 2009-01-12 at 08:37 -0800, Joshua D. Drake wrote:
> On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
>
> > > My point is that what Simon currently has (and so what you tested) is
> > > different from what is going to be commited (note the "final" in what
> > > I wrote) and I suspect the
On Mon, Jan 12, 2009 at 12:27 PM, Dave Page wrote:
> On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane wrote:
>> In general, we have always regretted it in the past when we chose to
>> slip a release waiting for a specific feature...
>
> I don't recall such a time - though perhaps the last time it happen
On Mon, 2009-01-12 at 15:26 +0200, Peter Eisentraut wrote:
> 1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
> results, or
>
> 2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
> clauses. (There would be no loss of functionality, because you can run
Tom Lane writes:
> Yeah, but there are already a number of things in 8.4 that are killer
> features for various applications --- window functions and WITH to take
> two recently-committed examples. Should we sit on those for however
> long it will take to make replication release-worthy?
Do we
>> 2. Start using more git, as many hackers and committers have already
>> started to do. This is the kind of situation where CVS just plain
>> falls down because branching and merging are unmanageably difficult in
>> it, where in git, they're many-times-a-day operations.
>
> This is a red herrin
On Mon, Jan 12, 2009 at 5:20 PM, Joshua D. Drake wrote:
> The community are our shareholders.
Exactly - and their dividends are the features we release, not a share
of profits we make from pushing out something a few weeks earlier.
> Right. Except that isn't really the question at hand is it? T
Gregory Stark writes:
> t...@postgresql.org (Tom Lane) writes:
>> Tweak order of operations in BitmapHeapNext() to avoid the case of
>> prefetching
>> the same page we are nanoseconds away from reading for real. There should be
>> something left to do on the current page before we consider issui
On Mon, 2009-01-12 at 17:27 +, Dave Page wrote:
> > In general, we have always regretted it in the past when we chose to
> > slip a release waiting for a specific feature...
>
> I don't recall such a time - though perhaps the last time it happened
> was before I was so heavily involved in the
On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane wrote:
> "Dave Page" writes:
> Yeah, but there are already a number of things in 8.4 that are killer
> features for various applications --- window functions and WITH to take
> two recently-committed examples. Should we sit on those for however
> long it
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> Alvaro Herrera wrote:
> >>> Tom Lane wrote:
> Alvaro Herrera writes:
> > Alvaro Herrera wrote:
> >> I like Teodor's proposal; I'll see about implementing that.
> > Attached.
> You missed updatin
On Mon, 2009-01-12 at 16:48 +, Dave Page wrote:
> On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
> wrote:
> > On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
> >
> >> Basically I think we are up against the same type of project management
> >> decision we've had several times before: are
Peter Eisentraut wrote:
> Simon Riggs wrote:
>> Recovery doesn't have a test framework as yet.
>
> I have been having these concerns as well. In fact, I recall
> discussions at least 8 years back about how pg_dump doesn't really have
> any organized testing, and we also have little regular tes
"Dave Page" writes:
> On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
> wrote:
>> I would certainly not like to see 8.4 slip.
> I would. PostgreSQL is not a commercial application which has to be
> released on schedule to satisfy shareholders - it's an Open Source
> project that aims to provid
Tom Lane wrote:
> Alvaro Herrera writes:
> > My vote goes for 1.
>
> > I wonder why you think it's impossible. Is it because you must scan
> > the whole table before being able to print any of it? (For example to
> > add extra alignment for the escaping backslashes in a way that doesn't
> > ren
t...@postgresql.org (Tom Lane) writes:
> Log Message:
> ---
> Tweak order of operations in BitmapHeapNext() to avoid the case of prefetching
> the same page we are nanoseconds away from reading for real. There should be
> something left to do on the current page before we consider issuin
On Mon, Jan 12, 2009 at 5:48 PM, Dave Page wrote:
> I would. PostgreSQL is not a commercial application which has to be
> released on schedule to satisfy shareholders - it's an Open Source
> project that aims to provide it's users with useful features.
It has nothing to do with commercial/non com
Magnus Hagander writes:
> On 12 jan 2009, at 17.46, Tom Lane wrote:
>> However, one of the properties -1 is supposed to have is that any
>> failure aborts the whole restore; it's not immediately clear how to
>> preserve that with CREATE DATABASE issued separately.
> Good point. Declare as incomp
On 2009-01-12, at 16:48, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project
management
decision we've had several times before: are we willing to slip the
On 12 jan 2009, at 17.46, Tom Lane wrote:
Magnus Hagander writes:
It should be possible to make it compatible with -C by moving the
CREATE
DATABASE command to outside of the transaction. I have only had a
quick
look at the code wrt how much work this would be. One thing that
hit me
qui
On Mon, Jan 12, 2009 at 05:50:19PM +0100, Magnus Hagander wrote:
2. Start using more git, as many hackers and committers have
already started to do. This is the kind of situation where CVS
just plain falls down because branching and merging are
unmanageably difficult in it, wh
On 12 jan 2009, at 17.42, David Fetter wrote:
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
David Fetter writes:
Two things to fix this, and several other problems:
1. Remove the messages size limits on -hackers. They serve no
useful purpose, and they interfere with our de
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake wrote:
> On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
>
>> Basically I think we are up against the same type of project management
>> decision we've had several times before: are we willing to slip the
>> 8.4 release schedule for however long
On 1/12/09, Joshua D. Drake wrote:
>
> > Basically I think we are up against the same type of project management
> > decision we've had several times before: are we willing to slip the
> > 8.4 release schedule for however long it will take for hot standby
> > and the other replication-related
Magnus Hagander writes:
> It should be possible to make it compatible with -C by moving the CREATE
> DATABASE command to outside of the transaction. I have only had a quick
> look at the code wrt how much work this would be. One thing that hit me
> quickly: do we support multiple CREATE DATABASE s
On Mon, Jan 12, 2009 at 5:18 PM, Tom Lane wrote:
> Basically I think we are up against the same type of project management
> decision we've had several times before: are we willing to slip the
> 8.4 release schedule for however long it will take for hot standby
> and the other replication-related
On Mon, Jan 12, 2009 at 11:33:43AM -0500, Tom Lane wrote:
> David Fetter writes:
> > Two things to fix this, and several other problems:
>
> > 1. Remove the messages size limits on -hackers. They serve no
> > useful purpose, and they interfere with our development process.
>
> Agreed, or at le
On Mon, 2009-01-12 at 11:33 -0500, Tom Lane wrote:
> > If -hackers
> > isn't already subscriber-only, now would be the time to make it so.
>
> Not sure how that's relevant?
So we don't get spam patches.
Joshua D. Drake
>
> regards, tom lane
>
--
PostgreSQL
Consult
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
> > My point is that what Simon currently has (and so what you tested) is
> > different from what is going to be commited (note the "final" in what
> > I wrote) and I suspect there will be a certain number of non
> > negligible adjustments (see th
David Fetter writes:
> Two things to fix this, and several other problems:
> 1. Remove the messages size limits on -hackers. They serve no useful
> purpose, and they interfere with our development process.
Agreed, or at least boost it up a good bit more.
> If -hackers
> isn't already subscrib
Heikki Linnakangas writes:
> If _SPI_execute_plan reaches the above "if" and sets "my_res = res",
> SPI_processed is left at 0. So FOUND is always set to false if the
> rewritten command type doesn't match the original.
Right, and I think that's probably sane behavior. The original command
got
On Mon, Jan 12, 2009 at 11:11:20AM -0500, Greg Stark wrote:
> On Mon, Jan 12, 2009 at 9:55 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> On Mon, 2009-01-12 at 09:04 -0500, Tom Lane wrote:
> >
> > Well, one of the things that makes me uncomfortable is that it's
> > not even clear exactly which
Tom Lane wrote:
Heikki Linnakangas writes:
The problem is that mod_stmt is determined for the query that has
canSetTag set, but in case of an INSTEAD OF rule that rewrites the
statement into a different command, an INSERT into a DELETE in this
case, canSetTag is not set. The return code of SP
On Mon, Jan 12, 2009 at 11:07 AM, Guillaume Smet
wrote:
> On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure wrote:
>> I disagree at least with hot standby. I've been using/testing (as
>> have others) it under a variety of workloads for several months now
>> with no issues outside of corrected issu
1 - 100 of 152 matches
Mail list logo
