I found out "shared_preload_libraries" setting is ignored when we launch
postgres in single user mode.
In this case, postgres command is launched with "--single" argument,
then the main() directly invokes PostgresMain(); without going through
PostmasterMain() which calls process_shared_preload_lib
On Thu, Aug 05, 2010 at 06:21:18AM +0200, Pavel Stehule wrote:
> I hope, so next week you can do own work on this job - I am not a
> native speaker, and my code will need a checking and fixing comments
I haven't entirely figured out how the code in the old patch works, but I
promise I *can* edit c
On lör, 2010-07-24 at 20:32 +0100, Mike Fowler wrote:
> Attached is the revised version of the patch addressing all the
> issues
> raised in the review, except for the use of AexprConst and c_expr.
> With
> my limited knowledge of bison I've failed to resolve the shift/reduce
> errors that are i
2010/8/4 Joshua Tolley :
> On Wed, Aug 04, 2010 at 04:44:05AM +0200, Pavel Stehule wrote:
>> > Yeah, I seem to have done a poor job of producing the patch based on the
>> > repository I was working from. That said, it seems Pavel's working
>> > actively on
>> > a patch anyway, so perhaps my updati
On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
>> *) also, isn't it possible to change text cast influencing GUCs 'n'
>> times per statement considering any query can call a function and any
>> function can say, change datestyle? Should
On 08/04/2010 10:08 PM, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with
Greg Stark writes:
> On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
>> What we are doing here, IMO, is not just changing string_agg() but
>> instituting a project policy that we are not going to offer built-in
>> aggregates with the same names and different numbers of arguments ---
>> otherwise
Robert Haas writes:
> On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
>> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>>> Well, the thing about $EDITOR is that it's a very-widely-understood
>>> convention. This one won't be, so the argument for making it an
>>> environment variable seems p
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
> All those issues can be avoided if you only run "git gc" when all the
> working directories are in a clean state, with no staged but uncommitted
> changes or other funny things. I can live with that gun tied to my ankle
> ;-).
Does even
On Wed, Aug 4, 2010 at 7:43 PM, Greg Smith wrote:
>> 2) usage of a S5D to store instructions to a make a checkpoint. Instead of
>> write the "dirty" pages directly to database files, postgreSQL could dump to
>> SSD the dirty pages and the instructions of how update the data files.
>> Later, a deam
On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>> Well, the thing about $EDITOR is that it's a very-widely-understood
>> convention. This one won't be, so the argument for making it an
>> environment variable seems pretty thin.
>
> Fwiw the +l
On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
> *) also, isn't it possible to change text cast influencing GUCs 'n'
> times per statement considering any query can call a function and any
> function can say, change datestyle? Shouldn't the related functions
> be marked 'volatile', not sta
On Wed, Aug 4, 2010 at 7:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
>>> This would be good, but I'm not sure how to do it. The main problem
>>> again is NumericDigit alignment. Only about half the time is the digit
>>> array going to be alig
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
> What we are doing here, IMO, is not just changing string_agg() but
> instituting a project policy that we are not going to offer built-in
> aggregates with the same names and different numbers of arguments ---
> otherwise the problem will come rig
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
> Well, the thing about $EDITOR is that it's a very-widely-understood
> convention. This one won't be, so the argument for making it an
> environment variable seems pretty thin.
Fwiw the +linenumber convention has been part of $EDITOR since
basical
Josh Berkus wrote:
I haven't been able to test things like putting a "hot" table on a
specific SSD.
Putting a hot table or even better an index on them, where that relation
fits on SSD but the whole database doesn't, can work well. But it
doesn't give the speedup levels people expect beca
> And those two layers in the middle are already providing a significant
> speedup on burst workloads. Ultimately, all the burst stuff has to make
> it onto regular disks eventually though, if you can't fit the whole
> thing on SSD, and then you're back to solving the non-SSD problem
> again. Th
Nilson wrote:
1) usage of a S5D to temporarily store the WAL log files until a
deamon process copy them to the regular HD.
The WAL is rarely as much of a bottleneck as people think it is.
Because it's all sequential writes, so long as you put it onto a
dedicated disk there's minimal advantag
On Wed, Aug 4, 2010 at 7:00 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> While chatting with Haas off-list regarding how the new array/string
>> functions should work (see the thread in its glory here:
>> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
>> the debate m
Robert Haas writes:
> On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
>> This would be good, but I'm not sure how to do it. The main problem
>> again is NumericDigit alignment. Only about half the time is the digit
>> array going to be aligned the way you need, so that puts a real crimp
>> in t
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane wrote:
> for: tgl, josh, badalex, mmoncure
> against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
If we're not regarding this as beta-forcing, I abstain.
--
Robert Haas
EnterpriseDB: http://www.ente
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any thoughts on:
>> select string_agg(delim, expres
On Wed, Aug 4, 2010 at 7:07 PM, Tom Lane wrote:
>> Or in other words, any thoughts on:
>> select string_agg(delim, expression);
>
> That looks pretty weird to me anyway, with or without use of ORDER BY.
> Nobody would think to write the delimiter first. Usually you put the
> "most important" argu
On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have a couple ideas for further work on the numeric code that I want
>> to get feedback on.
>
>> 1. Cramming it down some more. I propose that we introduce a third
>> format with a one-byte header: 1 bit for sign, 3 bits
Alex Hunsaker writes:
> I dunno about anyone else but (a, ',' order by a) just looks weird.
I suppose, but aren't you just focusing on the argument being constant?
In the more general case I don't think there's anything unnatural about
this syntax.
> Or in other words, any thoughts on:
> select
Merlin Moncure writes:
> While chatting with Haas off-list regarding how the new array/string
> functions should work (see the thread in its glory here:
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
> the debate morphed into the relative pros and cons about the propos
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
On Wed, Aug 04, 2010 at 06:19:49PM -0400, Tom Lane wrote:
> I wrote:
> > Hm? I don't think that an initdb here would have any impact on whether
> > we can call the next drop RC1 or not. We're talking about removing a
> > single built-in entry in pg_proc --- it's one of the safest changes we
> > c
On Wed, Aug 4, 2010 at 5:09 PM, Nilson wrote:
> The prices of large capacity Solid State Disks (SLCs of course) are still
> too high to most of us.
>
> But it´s already possible to find SSDs of small size (8 to 32 GB) today with
> affordable prices and good performance (0,1ms access time and at le
While chatting with Haas off-list regarding how the new array/string
functions should work (see the thread in its glory here:
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
the debate morphed into the relative pros and cons about the proposed
concat() being marked stable
Thom Brown writes:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous.
Yes, of course, sorry if I confused anyone. It's the combination of
having both one- a
On 4 August 2010 23:19, Tom Lane wrote:
> I wrote:
>> Hm? I don't think that an initdb here would have any impact on whether
>> we can call the next drop RC1 or not. We're talking about removing a
>> single built-in entry in pg_proc --- it's one of the safest changes we
>> could possibly make.
>
I wrote:
> Hm? I don't think that an initdb here would have any impact on whether
> we can call the next drop RC1 or not. We're talking about removing a
> single built-in entry in pg_proc --- it's one of the safest changes we
> could possibly make.
Well, I forgot that an aggregate involves more
Michael Meskes wrote:
> I'd consider this a bug.
Could you explain why? The assertions that people consider it a bug
without explanation of *why* is confusing for me.
It sounds more like a feature of the ECPG interface that people
would really like, and which has been technically possible s
The prices of large capacity Solid State Disks (SLCs of course) are still
too high to most of us.
But it´s already possible to find SSDs of small size (8 to 32 GB) today with
affordable prices and good performance (0,1ms access time and at least
150MB/s r/w transfer rate).
So, would it possible t
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now
On Wed, Aug 04, 2010 at 09:02:43PM +0100, Thom Brown wrote:
> On 4 August 2010 20:58, Josh Berkus wrote:
> >
> >> Great, I was afraid people would want another beta if we forced
> >> an initdb. So a hearty +1 for fixing it and not doing another
> >> beta (pending other bugs obviously).
> >
> > An
Robert Haas writes:
> On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
>> I seriously doubt that there are many applications out there that are
>> actually depending on this aspect of rule execution; if anything, there
>> are probably more that will see it as a bug.
> Changing EXPLAIN ANALYZE see
Robert Haas writes:
> I have a couple ideas for further work on the numeric code that I want
> to get feedback on.
> 1. Cramming it down some more. I propose that we introduce a third
> format with a one-byte header: 1 bit for sign, 3 bits for dynamic
> scale, and 4 bits for weight (the first of
On 4 August 2010 20:58, Josh Berkus wrote:
>
>> Great, I was afraid people would want another beta if we forced an
>> initdb. So a hearty +1 for fixing it and not doing another beta
>> (pending other bugs obviously).
>
> And, btw, there has been a lot of testing of pg_upgrade due to the
> initdbs
> Great, I was afraid people would want another beta if we forced an
> initdb. So a hearty +1 for fixing it and not doing another beta
> (pending other bugs obviously).
And, btw, there has been a lot of testing of pg_upgrade due to the
initdbs and otherwise. I think 9.0 is going to have a prett
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force an initdb
>> anyway. And I real
On 8/4/2010 10:26 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
The other thing that was being argued was whether rules should be
changed to act that way too, and if not whether EXPLAIN ANALYZE should
be fixed to make sure it emulates rule execution better. Personally
Robert Haas wrote:
> Please put "contrib/isn" in the name somewhere so that there is
> some overlap between the subject line and the CF entry.
It is now "contrib/isn isbn update".
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
04.Ağu.2010 tarihinde 22:44 saatinde, Josh Berkus
şunları yazdı:
I'm OK with forcing an initDB for RC1.
I think beta5 will be a better choice than RC 1 here.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gundu
Josh Berkus writes:
> If it's causing bugs, drop it now. If we include it in 9.0, we're stuck
> with it for years.
Well, it's causing bug reports, which is not exactly the same thing as bugs.
But yeah, I'm thinking we should get rid of it.
regards, tom lane
--
Sent via
> Well, it'd take an initdb to get rid of it. In the past we've avoided
> forcing initdb post-beta1 unless it was Really Necessary. OTOH, we seem
> to be in the mode of encouraging beta testers to test pg_upgrade, so
> maybe that concern isn't worth much at the moment.
If it's causing bugs, dro
Robert Haas writes:
> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>> I think forcing an initdb might be more trouble than this wart is worth.
> +1. I would not make this change unless we have to force an initdb
> anyway. And I really hope we don't, because I'm sort of hoping the
> nex
On Wed, Aug 4, 2010 at 2:58 PM, Kevin Grittner
wrote:
> "Joshua D. Drake" wrote:
>> On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
>
>>> patch against HEAD is attached and validated against a lot of
>>> previously wrong and correct hyphenated isbn.
>
>> Great! Thanks. We will get it on the re
I have a couple ideas for further work on the numeric code that I want
to get feedback on.
1. Cramming it down some more. I propose that we introduce a third
format with a one-byte header: 1 bit for sign, 3 bits for dynamic
scale, and 4 bits for weight (the first of which is a sign bit). This
mi
On 4 August 2010 20:25, Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
If we were a bit earlier in the 9.0 cycle I would suggest that this
confusion is a sufficient reason to drop the one-
Alex Hunsaker writes:
> Either way, I don't have strong feelings on this other than if we dont
> fix it now when will we?
Well, we won't. If 9.0 ships with both forms of string_agg, we're stuck
with it IMO. It's not exactly a bug, so I won't cry if that's how
things go; but it is striking that
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
> I think forcing an initdb might be more trouble than this wart is worth.
+1. I would not make this change unless we have to force an initdb
anyway. And I really hope we don't, because I'm sort of hoping the
next 9.0 release will be rc1.
--
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
> The other thing that was being argued was whether rules should be
> changed to act that way too, and if not whether EXPLAIN ANALYZE should
> be fixed to make sure it emulates rule execution better. Personally
> I'd be in favor of changing rule exe
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now t
Alex Hunsaker writes:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>> confusion is a sufficient reason to drop the one-argument form of
>> string_agg. It's too late now though.
> FWIW I think we can still change it. Isn'
> No. Now I'm working at Forcia, Inc. (http://www.forcia.com/),
> where Postgres' extensibility is used very much to develop
> innovative applications. I can continue to develop Postgres
> thanks to the company's support!
Cool!
My condolences to Koichi-san, though. I know he'll miss having you
"Joshua D. Drake" wrote:
> On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
>> patch against HEAD is attached and validated against a lot of
>> previously wrong and correct hyphenated isbn.
> Great! Thanks. We will get it on the review list.
I added it as "isbn update" to the 2010-09 Commi
Yeb Havinga writes:
> Tom Lane wrote:
>> I agree, this idea seems completely nuts. It is *not* reasonable for
>> an action applied to a child to change the definition of the parent.
> Also not in the case that we're talking about here?
> A.a_columnB.a_column
> | /
> v v
Marko Tiikkaja writes:
> According to the latter commit, not updating the snapshot could be
> preferable for EXPLAIN ANALYZE, but I don't see why this is. Maybe we
> should wait until we hear from Tom?
Sorry for not catching up on my email sooner. On the whole I'm in
agreement with the argume
Tom Lane wrote:
Andrew Dunstan writes:
On 08/04/2010 06:41 AM, Robert Haas wrote:
Uh, really? Wow. You want to follow the inheritance hierarchy in
both directions, both down and up? That seems like it could be
confusing.
It seems more than confusing. It seems fundamentally wrong. It would
On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
> hi all,
>
> currently i am working on a big project for a german bookseller and
> publisher. one of the requirements was correct hyphenation of ISBN-13
> for about 14.400.000 books in postgresql database. so added support
> for hyphenating isbn
On Wed, Aug 4, 2010 at 12:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> *scratches head*
>
>> One of those tests uses < and the other uses <=
>
>> Which one is wrong?
>
> Well, neither, since NUMERIC(0,0) is disallowed. However, it's probably
> not the place of these functions to assume that,
hi all,
currently i am working on a big project for a german bookseller and
publisher. one of the requirements was correct hyphenation of ISBN-13
for about 14.400.000 books in postgresql database. so added support
for hyphenating isbn with the new 979-prefix and additionally added all
missing rang
Robert Haas writes:
> *scratches head*
> One of those tests uses < and the other uses <=
> Which one is wrong?
Well, neither, since NUMERIC(0,0) is disallowed. However, it's probably
not the place of these functions to assume that, so I'd suggest treating
equality as valid.
On Wed, Aug 4, 2010 at 11:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas wrote:
>>> The smallest value for precision which requires 2 numeric_digits is
>>> always 2; and the required number of numeric_digits increases by 1
>>> each time the number of
On Wed, Aug 04, 2010 at 04:44:05AM +0200, Pavel Stehule wrote:
> > Yeah, I seem to have done a poor job of producing the patch based on the
> > repository I was working from. That said, it seems Pavel's working actively
> > on
> > a patch anyway, so perhaps my updating the old one isn't all that
On Wed, 2010-08-04 at 15:36 +0100, Simon Riggs wrote:
> On Wed, 2010-08-04 at 17:23 +0800, Boxuan Zhai wrote:
> > Dear Robert,
> >
> > I am just considering that there may be some logical mistakes for my
> > rule rewriting strategy of MERGE actions.
> >
> > In my current design, if we find tha
Andrew Dunstan writes:
> On 08/04/2010 06:41 AM, Robert Haas wrote:
>> Uh, really? Wow. You want to follow the inheritance hierarchy in
>> both directions, both down and up? That seems like it could be
>> confusing.
> It seems more than confusing. It seems fundamentally wrong. It would
> cert
Robert Haas writes:
> On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas wrote:
>> The smallest value for precision which requires 2 numeric_digits is
>> always 2; and the required number of numeric_digits increases by 1
>> each time the number of base-10 digits increases by DEC_DIGITS.
> And here is
2010/8/3 Josh Berkus :
> On 8/2/10 3:42 PM, Itagaki Takahiro wrote:
>> Sorry for delayed reply. I moved to a new job,
>> and was very busy for it.
>
> Congratulations! Are you still at NTT Open Source?
No. Now I'm working at Forcia, Inc. (http://www.forcia.com/),
where Postgres' extensibility is
David Fetter writes:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> A side question is whether this should be an environment variable or
>> a psql variable.
> I'd say "yes." As with $EDITOR/PSQL_EDITOR, there should be something
> that looks for an overriding psql variable, dr
On Wed, 2010-08-04 at 17:23 +0800, Boxuan Zhai wrote:
> Dear Robert,
>
> I am just considering that there may be some logical mistakes for my
> rule rewriting strategy of MERGE actions.
>
> In my current design, if we find that an action type, say UPDATE, is
> replaced by INSTEAD rules, we wil
Hello
updated patch attached
2010/8/4 Robert Haas :
> On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
>> I hope so I found and fixed last issue - the longer functions was
>> showed directly - without a pager.
>
> As a matter of style, I suggest leaving bool *edited as the last
> argument to
On Wed, Aug 4, 2010 at 10:10 AM, David Fetter wrote:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>>
>> Well, it'd still work fine for \e foo. I
On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>
> Well, it'd still work fine for \e foo. It'll just blow up for \e
> foo 3. My concern isn't really t
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkaja wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the old
value after it was DELETEd, so it really is what the tuple was before the
DLETE, not what is seen by the snapshot. In a BEFORE D
On 4 August 2010 14:43, Marko Tiikkaja wrote:
>>> 3) You can't set the RETURNING results. You suggested that
>>> RETURNING for DELETE would return the OLD value, but that seems
>>> broken because that's not necessarily what was deleted.
>>
>> Well that's what happens for a table. A
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied to my ankle ;-).
But to make sure
On 8/4/10 4:31 PM +0300, Dean Rasheed wrote:
1) You can't re-evaluate the UPDATE expression like an UPDATE on a
table does. Consider for example UPDATE foo SET a=a+1; If the
tuples change before we get to them, we lose data because we
simply can't re-evaluate "a+1" in
On 02/08/10 11:45, Fujii Masao wrote:
On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas
wrote:
I don't think any of this quorum stuff makes much sense without explicitly
registering standbys in the master.
I'm not sure if this is a good idea. This requires users to do more
manual operations
On 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
wrote:
I'm a bit disappointed that the wiki page advises against git-new-workdir -
that's exactly what I was planning to use. It claims there's data loss
issues with that, does someone know the details? Is
On Wed, Aug 4, 2010 at 9:29 AM, Heikki Linnakangas
wrote:
> Hmm, if I understand correctly, Daniel talks about data loss when using
> "alternates", if you e.g delete a branch and run "git gc" in the parent
> repository, because the child repository referring to the parent via the
> alternate refer
On 4 August 2010 13:22, Marko Tiikkaja wrote:
> On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
>>
>> Does this sound like a useful feature? Is this a sane approach to
>> implementing it? If not, has anyone else given any thought as to how
>> it might be implemented?
>
> I didn't look at the patch, b
On Wednesday 04 August 2010 14:09:51 Heikki Linnakangas wrote:
> Yep. I believe Boxuan is using git in a simplistic way, doing just "git
> diff" to create patches. For adding new files, you need to do "git add
> ", but note that this adds the new file to "staging area". To
> view all changes in
On Tue, Aug 3, 2010 at 1:50 PM, Kolb, Harald (NSN - DE/Munich)
wrote:
> Or is "fsync" still not supported ?
Wouldn't you need to have it set to "apply" to get the behavior you want here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql
On 08/04/2010 06:41 AM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in
On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
> I hope so I found and fixed last issue - the longer functions was
> showed directly - without a pager.
As a matter of style, I suggest leaving bool *edited as the last
argument to do_edit() and inserting int lineno as the second-to-last
argum
On 04/08/10 12:23, Boxuan Zhai wrote:
I am just considering that there may be some logical mistakes for my rule
rewriting strategy of MERGE actions.
In my current design, if we find that an action type, say UPDATE, is
replaced by INSTEAD rules, we will remove all the actions of this type from
th
On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
Does this sound like a useful feature? Is this a sane approach to
implementing it? If not, has anyone else given any thought as to how
it might be implemented?
I didn't look at the patch, but so far, I've identified three problems
with the existing
Tom Lane wrote:
> Viktor Valy writes:
> > We are 2 Students from the Technical University of Vienna. At our internship
> > we would like to develop the item of the TODO list: "Allow SET CONSTRAINTS
> > to be qualified by schema/table name".
> > Is anyone working on it?
>
> Uh, it was done years a
On Aug3, 2010, at 21:16 , Greg Smith wrote:
>> That was a leftover of the trimming and comment skipping logic, which my
>> patch moves to process_command.
>
> I think there's still a trimming error here--line 195 of the new patch is now
> removing the declaration of "i" just before it sets it t
Now I think patch is as good as can be. :)
I'm going to prepare less-or-equal function in same manner as this patch.
With best regards,
Alexander Korotkov.
Hi,
After setting up a real SR cluster based on V9 beta3 and Fuji's SR patch
synch_rep_0722.patch
and doing some simple update_and_check tests, it seems that active and
standby are not in sync.
Can this be a problem of the SR or the HSB feature ?
Or is "fsync" still not supported ?
Used configu
On Mon, Aug 2, 2010 at 5:20 AM, Robert Haas wrote:
> I reviewed this code in a fair amount of detail today and ended up
> rewriting it. In general terms, it's best to avoid changing things
> that are not relevant to the central purpose of the patch. This patch
> randomly adds a whole bunch of w
Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in parent2, child a
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
>> If child inherits column A from parent1 and parent2, and it is then
>> renamed to B in parent2, what should the name be in the child after
>> the rename is completed?
>
> The column should be renamed to B in parent2, child and parent1.
Uh, rea
Robert Haas wrote:
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
I just read that thread. In the beginning there is a short discussion what
the non-astonishing behaviour of the RENAME in the case of multiple origin
inheritance should be, which is preventing renames or any property chang
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
> I just read that thread. In the beginning there is a short discussion what
> the non-astonishing behaviour of the RENAME in the case of multiple origin
> inheritance should be, which is preventing renames or any property change in
> that case. I
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
wrote:
> I'm a bit disappointed that the wiki page advises against git-new-workdir -
> that's exactly what I was planning to use. It claims there's data loss
> issues with that, does someone know the details? Is there really a risk of
> data loss
1 - 100 of 105 matches
Mail list logo
