Andrew Dunstan writes:
> On 09/18/2010 08:25 PM, Darren Duncan wrote:
>> Is this still the timetable, or is it being affected at all by the
>> delay in migrating repositories while the CVS is cleaned up?
> They aren't really connected. If you've been watching -committers you
> would have seen t
On Sat, Sep 18, 2010 at 11:48 PM, Joseph Adams
wrote:
> As for whitespace preservation, I don't think we should go out of our
> way to keep it intact. Sure, preserving formatting for input and
> output makes some sense because we'd have to go out of our way to
> normalize it, but preserving white
On Sat, Sep 18, 2010 at 4:03 PM, Robert Haas wrote:
> Hmm, yeah. I'd be tempted to try to keep the user's original
> whitespace as far as possible, but disregard it as far as equality
> comparison goes. However, I'm not quite sure what the right thing to
> do about 0 vs 0.0 is. Does the JSON sp
On Sat, Sep 18, 2010 at 6:35 PM, Robert Haas wrote:
> On Sat, Sep 18, 2010 at 3:11 PM, Tom Lane wrote:
>> This is at least inconsistent and at worst wildly misleading. ISTM
>> we ought to adopt some combination of the following ideas:
>
> I vote for this combination:
>
>> 3. Don't show either pg
On 09/18/2010 08:25 PM, Darren Duncan wrote:
Tom Lane wrote on 2010.09.08:
The core committee has decided that it's time to press forward with
releasing 9.0. Barring catastrophic bug reports in the next week,
9.0.0 will be wrapped Thursday 9/16 for public announcement Monday 9/20.
Is this s
Tom Lane wrote on 2010.09.08:
The core committee has decided that it's time to press forward with
releasing 9.0. Barring catastrophic bug reports in the next week,
9.0.0 will be wrapped Thursday 9/16 for public announcement Monday 9/20.
Is this still the timetable, or is it being affected at a
> I think that using a system catalog for this is going to be a
> non-starter,
Technically improbable? Darn.
> but we could use a flat file that is designed to be
> machine-editable (and thus avoid repeating the mistake we've made with
> postgresql.conf).
Well, even if we can't update it thro
On Sat, Sep 18, 2010 at 3:11 PM, Tom Lane wrote:
> This is at least inconsistent and at worst wildly misleading. ISTM
> we ought to adopt some combination of the following ideas:
I vote for this combination:
> 3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even
> for the curre
On Sat, Sep 18, 2010 at 5:42 PM, Josh Berkus wrote:
> There are considerable benefits to having a standby registry with a
> table-like interface. Particularly, one where we could change
> replication via UPDATE (or ALTER STANDBY) statements.
I think that using a system catalog for this is going
All,
I'm answering this strictly from the perspective of my company's
customers and what they've asked for. It does not reflect on what
features are reflected in whatever patch.
> * Support multiple standbys with various synchronization levels.
Essential. We already have two customers who want
Kris Jurka writes:
>> On Fri, 6 Aug 2010, James William Pye wrote:
>>> I think there's a snag in the patch:
> Oh, duh. It's a server side copy not going through the client at all.
> Here's a hopefully final patch.
Applied with a correction: this would've totally broken binary copy in
old-style
On Fri, Sep 17, 2010 at 11:12 PM, Itagaki Takahiro
wrote:
> On Sat, Sep 18, 2010 at 11:46 AM, Robert Haas wrote:
>> wrote:
>>> One of my proposal is we don't have to keep the original input text.
>>> We store JSON data in effective internal formats. If users want to get
>>> human-readable output
On Sat, Sep 18, 2010 at 2:30 PM, Andrew Dunstan wrote:
> On 09/18/2010 02:20 PM, David Blewett wrote:
>>
>> I was under the impression that git over http was just as efficient since
>> 1.6.6 [1].
>>
>> David Blewett
>> 1. http://github.com/blog/642-smart-http-support
>>
>
> It's hard to keep up, t
On Sat, Sep 18, 2010 at 4:50 AM, Simon Riggs wrote:
> Waiting might sound attractive. In practice, waiting will make all of
> your connections lock up and it will look to users as if their master
> has stopped working as well. (It has!). I can't imagine why anyone would
> ever want an option to se
On 18/09/10 21:52, Kevin Grittner wrote:
[Apologies for not reply-linking this; work email is down so I'm
sending from gmail.]
Based on feedback from Heikki and Tom I've reworked how I find the
top-level transaction. This is in the git repo, and the changes can
be viewed at:
http://git.postgre
psql's \dn command hides pg_temp_nn schemas, except for the current
backend's own temp schema (if any). However, when we added separate
pg_toast_temp_nn schemas for TOAST tables, \dn wasn't taught about that,
leading to such odd-looking output as this:
regression=# \dn
List of schemas
[Apologies for not reply-linking this; work email is down so I'm
sending from gmail.]
Based on feedback from Heikki and Tom I've reworked how I find the
top-level transaction. This is in the git repo, and the changes can
be viewed at:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git
Marko Tiikkaja writes:
> [ patch for a misleading error message ]
I've committed the attached revised version of this patch. The main
change is to only emit the hint if the insertion source can be shown
to be a RowExpr with exactly the number of columns expected by the
INSERT. This should avoid
On 09/18/2010 02:20 PM, David Blewett wrote:
I was under the impression that git over http was just as efficient
since 1.6.6 [1].
David Blewett
1. http://github.com/blog/642-smart-http-support
It's hard to keep up, the landscape is still changing quite fast.
cheers
andrew
--
Sent vi
Sorry for top-posting... I was under the impression that git over http was
just as efficient since 1.6.6 [1].
David Blewett
1. http://github.com/blog/642-smart-http-support
On Sep 18, 2010 12:26 PM, "Andrew Dunstan" wrote:
On 09/18/2010 11:37 AM, Tom Lane wrote:
>
> Andrew Dunstan wrote:
>>>
On 09/18/2010 11:37 AM, Tom Lane wrote:
Andrew Dunstan wrote:
Test machines belong in the buildfarm.
So? People are still going to want to git-ify their buildfarm critters.
Right. I was just reacting to Bruce's observation about what people said
about his moving off BSD/OS.
Bruce Momji
On Sat, 2010-09-18 at 18:01 +0200, Pavel Stehule wrote:
> who is psycopg maintainer, please?
Why don't you ask it to psycopg2 mailing list?
http://www.initd.org/ (I know, mailing lists are down nowadays. See
website)
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Po
I wrote:
> This commit occurred during that interval between where we'd initially
> branched 7.3 and where we moved it up to head. I think what happened
> was that I tried to back-patch a fix into what was then the 7.3 branch,
> and when Marc moved the branch point, these commits all ended up
> or
Dimitri Fontaine writes:
> Robert Haas writes:
>> What you just said is about what I had in mind. I admit I can't
>> articulate a more detailed design right off the top of my head, but
>> the architecture you're proposing seems dead certain to never cover
>> more than 0.1% of what people actuall
Hello
who is psycopg maintainer, please? Can somebody explains to me, why
psycopg doesn't support twophase commit still, although some
implementation was done in summer 2008?
Now two phase commit is part of DB-API, so can be implemented.
There are some bariers?
Regards
Pavel Stehule
--
Sent
Andrew Dunstan wrote:
>> Test machines belong in the buildfarm.
So? People are still going to want to git-ify their buildfarm critters.
Bruce Momjian writes:
> My big point in posting was to say that compiling git was not the
> nightmare I expected it to be.
FWIW, I've also successfully instal
Andrew Dunstan wrote:
>
>
> On 09/18/2010 10:22 AM, Bruce Momjian wrote:
> > Dave Page wrote:
> >> On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
> >>> FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
> >>> with the attached minor changes.
> >> I thought you were r
On 09/18/2010 10:22 AM, Bruce Momjian wrote:
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.
I thought you were replacing that old thing with pile of hardware tha
Dave Page wrote:
> On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
> > FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
> > with the attached minor changes.
>
> I thought you were replacing that old thing with pile of hardware that
> Matthew was putting together?
Ma
Robert Haas writes:
> What you just said is about what I had in mind. I admit I can't
> articulate a more detailed design right off the top of my head, but
> the architecture you're proposing seems dead certain to never cover
> more than 0.1% of what people actually do.
Well, considering what we
Simon Riggs writes:
> I've said COMMIT with no option because I believe that we have only two
> choices: commit or wait (perhaps forever), and IMHO waiting is not good.
>
> We can't ABORT, because we sent a commit to the standby.
Ah yes, I keep forgetting Sync Rep is not about 2PC. Sorry about th
On Fri, 2010-09-17 at 21:32 +0200, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
> >> According to what I heard, some people want to guarantee that all the
> >> transactions are *always* written in *all* the synchronous standbys.
> >
> > Yo
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
> FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
> with the attached minor changes.
I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?
--
Dave Page
Blog: http://pgs
33 matches
Mail list logo
