2010/8/6 David Fetter :
> On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
>> 2010/8/6 Andrew Dunstan :
>> > On 08/05/2010 06:56 PM, Mike Fowler wrote:
>> >> SELECT
>> >> xslt_process('cim30400'::text,
>> >> $$http://www.w3.org/1999/XSL/Transform";
>> >> version="1.0">
>> >>
>> >>
>>
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
> 2010/8/6 Andrew Dunstan :
> > On 08/05/2010 06:56 PM, Mike Fowler wrote:
> >> SELECT
> >> xslt_process('cim30400'::text,
> >> $$http://www.w3.org/1999/XSL/Transform";
> >> version="1.0">
> >>
> >>
> > [snip]
> >>
> >> $$::text, 'n1=v
On tis, 2010-07-27 at 16:33 -0700, David Fetter wrote:
> * Do we already have it?
>
> Not really. There are kludges to accomplish these things, but
> they're available mostly in the sense that a general-purpose
> language allows you to write code to do anything a Turing machine
>
2010/8/6 Andrew Dunstan :
>
>
> On 08/05/2010 06:56 PM, Mike Fowler wrote:
>>
>> SELECT
>> xslt_process('cim30400'::text,
>> $$http://www.w3.org/1999/XSL/Transform";
>> version="1.0">
>>
>>
> [snip]
>>
>> $$::text, 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
>>
>>
>
> I haven't been paying attention to
http://groups.yahoo.com/group/pedranmarcksld/message
vielmehr an das Vorhandensein eines
{688 Voraussetzung fur die Befreiung verlorener Gebiete}
wenn auch noch so kleinen Restes dieses Volkes und Staates, der, im B
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://www.w3.org/1999/XSL/Transform";
version="1.0">
[snip]
$$::text, 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
I haven't been paying attention to this, so sorry if this has been
discussed before, but
2010/8/6 Mike Fowler :
> Hi Pavel,
>
> On 02/08/10 09:21, Pavel Stehule wrote:
>>
>> Hello
>>
>> 2010/8/2 Mike Fowler:
>>>
>>> Hi Pavel,
>>>
>>> Currently your patch isn't applying to head, from the looks of things a
>>> function signature has changed. Can you update your patch please?
>>>
>>
>> ye
Excerpts from Mike Fowler's message of mar jun 29 06:37:28 -0400 2010:
> After seeing some other posts in the last couple of days, I realised I
> hadn't documented the function in the SGML. I have now done so, and
> added a couple of tests with XML literals. Please find the patch
> attached. No
It seems suspicious to me that LockSharedObject() calls
AcceptInvalidationMessges() and LockDatabaseObject() does not. Since
the only caller of LockSharedObject() at present is
AcquireDeletionLock(), I'm not sure there's an observable bug here at
the moment, but then again, I'm also not sure there
Dear All,
I have seen a lively discussion about the DO NOTING action in MERGE command.
And, I think most people want it. So it will be added to my next patch.
Before the implementation, I still have some questions to confirm:
1. If we have a DO NOTHING action specified, it should be the last WHE
>> I've never had the deadlock detector successfully deal with the above.
>> Let alone a 4-way.
> Hm. I have seen 5way deadlocks getting resolved just recently. I can
> find the relevant if you find it interesting, but I doubt it is.
Ah, I didn't know that it was even *supposed* to resolve
larger
Josh Berkus writes:
>> Hm? Please explain what you're talking about.
> Transaction A locks 1 and wants a lock on 2
> Transaction B locks 2 and wants a lock on 3
> Transaction C locks 3 and wants a lock on 1
> I've never had the deadlock detector successfully deal with the above.
> Let alone a 4
On Thu, Aug 05, 2010 at 03:49:05PM -0700, Josh Berkus wrote:
>
> > Hm? Please explain what you're talking about.
>
> Transaction A locks 1 and wants a lock on 2
> Transaction B locks 2 and wants a lock on 3
> Transaction C locks 3 and wants a lock on 1
>
> I've never had the deadlock detector succ
On 06/08/10 10:49, Josh Berkus wrote:
Hm? Please explain what you're talking about.
Transaction A locks 1 and wants a lock on 2
Transaction B locks 2 and wants a lock on 3
Transaction C locks 3 and wants a lock on 1
I've never had the deadlock detector successfully deal with the abov
Robert Haas writes:
> [ BackendRelFileNode patch ]
One thing that I find rather distressing about this is the 25% bloat
in sizeof(SharedInvalidationMessage). Couldn't we avoid that? Is it
really necessary to *ever* send an SI message for a backend-local rel?
I agree that one needs to send relc
Hi Pavel,
On 02/08/10 09:21, Pavel Stehule wrote:
Hello
2010/8/2 Mike Fowler:
Hi Pavel,
Currently your patch isn't applying to head, from the looks of things a
function signature has changed. Can you update your patch please?
yes - see attachment
Thanks, the new patch applies cleanly. H
> Hm? Please explain what you're talking about.
Transaction A locks 1 and wants a lock on 2
Transaction B locks 2 and wants a lock on 3
Transaction C locks 3 and wants a lock on 1
I've never had the deadlock detector successfully deal with the above.
Let alone a 4-way.
> Not sure I believe thi
Josh Berkus writes:
> Yes; it's a major project. Our detector works pretty well for deadlocks
> which are 2-process locks or even several processes all locking against
> the same first process. However, triangular and quadralateral deadlocks
> (which I've seen more than once) it completely cannot
On 8/5/10 1:59 PM, Kevin Grittner wrote:
> Oh, and if deadlocks are that broken, it's a bit scary that we have
> let that go. Is it the problem that technically intractable?
Yes; it's a major project. Our detector works pretty well for deadlocks
which are 2-process locks or even several processe
Andrew Dunstan writes:
> On 08/05/2010 05:11 PM, Tom Lane wrote:
>> This example doesn't seem terribly compelling. Why would you bother
>> using USING with constants?
> In a more complex example you might use $1 in more than one place in the
> query.
Well, that's better than no justification,
On Aug4, 2010, at 13:58 , Florian Pflug wrote:
> 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 re
On 08/05/2010 05:11 PM, Tom Lane wrote:
Heikki Linnakangas writes:
There's a little problem with EXECUTE USING when the parameters are of
type unknown (going back to 8.4 where EXECUTE USING was introduced):
do $$
BEGIN
EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
END;
Heikki Linnakangas writes:
> There's a little problem with EXECUTE USING when the parameters are of
> type unknown (going back to 8.4 where EXECUTE USING was introduced):
> do $$
> BEGIN
>EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
> END;
> $$;
> ERROR: failed to find c
Peter Eisentraut writes:
> On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
>> Huh? The functionality proposed for removal is only that of omitting
>> an explicit delimiter argument for string_agg(). Since the default
>> value (an empty string) doesn't seem to be the right thing all that
>> of
Josh Berkus wrote:
> Overall, you're missing the point: there are workarounds for all
> of these things now. However, they are *workarounds*, which means
> that they are awkward, expensive, and/or hard to administrate;
> having predicate locks would make things much easier.
Well, if some form
Hello
2010/8/5 Heikki Linnakangas :
> There's a little problem with EXECUTE USING when the parameters are of type
> unknown (going back to 8.4 where EXECUTE USING was introduced):
>
> do $$
> BEGIN
> EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
> END;
> $$;
> ERROR: failed to
There's a little problem with EXECUTE USING when the parameters are of
type unknown (going back to 8.4 where EXECUTE USING was introduced):
do $$
BEGIN
EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
END;
$$;
ERROR: failed to find conversion function from unknown to text
CONT
Kevin,
Overall, you're missing the point: there are workarounds for all of
these things now. However, they are *workarounds*, which means that
they are awkward, expensive, and/or hard to administrate; having
predicate locks would make things much easier.
> I don't see how that can be resolved wi
On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
> Huh? The functionality proposed for removal is only that of omitting
> an explicit delimiter argument for string_agg(). Since the default
> value (an empty string) doesn't seem to be the right thing all that
> often anyway, I'm not following wh
Josh Berkus wrote:
> Anyway, here's some of the uses I'm thinking of:
>
> (1) Pre-insert lock: you know that you're going to insert a record
> with PK="X" later in a long-running SP, so you want to lock out
> other inserts of PK="X" at the beginning of the procedure.
Well, if we added a liste
Josh Berkus writes:
> On 8/5/10 12:18 PM, Robert Haas wrote:
>> Could we arrange to emit this error message only when there is an
>> aggregate with the same name but different arguments?
> Personally, I don't see this as really necessary. Just mentioning ORDER
> BY in the hint will be enough to
On 8/5/10 12:33 PM, Kevin Grittner wrote:
> I don't know whether this is the right time to discuss those 9
> different uses, but just so everyone knows, the SIRead locks needed
> for the SSI implementation in the current serializable patch have
> some characteristics which may be exactly what you
Josh Berkus wrote:
> Well, we *still* want predicate locking regardless of what MERGE
> supports. It's useful in about 9 different ways.
I don't know whether this is the right time to discuss those 9
different uses, but just so everyone knows, the SIRead locks needed
for the SSI implementatio
On 8/5/10 12:18 PM, Robert Haas wrote:
> Could we arrange to emit this error message only when there is an
> aggregate with the same name but different arguments?
Personally, I don't see this as really necessary. Just mentioning ORDER
BY in the hint will be enough to give people the right place t
Robert Haas writes:
> On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
>> Next question: exactly how should the variant HINT be phrased?
>> I'm inclined to drop the bit about explicit casts and make it read
>> something like
>>
>> HINT: No aggregate function matches the given name and argument
>>
On Aug 5, 2010, at 12:16 PM, Tom Lane wrote:
> HINT: No aggregate function matches the given name and argument
> types. Perhaps you misplaced ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Well, maybe we need to expend some more sweat on the error message then.
>>> But this patch was still a prerequisite thing, because without it there
>>> is no error that we can complain about.
>
>> Yes, I'd say an addition
Josh Berkus writes:
>> Well, maybe we need to expend some more sweat on the error message then.
>> But this patch was still a prerequisite thing, because without it there
>> is no error that we can complain about.
> Yes, I'd say an addition to the HINT is in order *assuming* at that
> stage we ca
> Well, maybe we need to expend some more sweat on the error message then.
> But this patch was still a prerequisite thing, because without it there
> is no error that we can complain about.
Yes, I'd say an addition to the HINT is in order *assuming* at that
stage we can tell if the user passed a
Merlin Moncure writes:
> On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane wrote:
>> I was not persuaded that there's a real bug in practice. IMO, his
>> problem was a broken trigger not broken upsert logic. Even if we
>> conclude this is unsafe, simply removing the example is of no help to
>> anyone.
On Aug 5, 2010, at 11:45 AM, Tom Lane wrote:
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>
> Yeah, the whole point of the thread: that's not a call of a two-argument
> aggregate. It's a call of a one-argument aggregate, using a two-column
> sort key
On Aug 5, 2010, at 11:42 AM, Thom Brown wrote:
>>> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
>>> ^
>>
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>>
>>> HINT: No function matches the given name and argument types.
"David E. Wheeler" writes:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
> I'm confused: that looks like t
On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Attached is a patch to remove the upsert example from the pl/pgsql
>> documentation. It has a serious bug (see:
>> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
>> to fix. IMNSHO, our code examp
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
On 5 August 2010 19:39, David E. Wheeler wrote:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>>
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
>> LINE
"Kevin Grittner" wrote:
New numbers on where we are with this CommitFest, at the end of the
third week:
72 patches were submitted
3 patches were withdrawn (deleted) by their authors
12 patches were moved to CommitFest 2010-09
--
57 patches in CommitFest 2010-07
--
3 committed to 9.0
--
54 pa
On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
> Applied to HEAD and 9.0. The mistaken case will now yield this:
>
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
Peter Eisentraut writes:
> I vote against this patch. There are plenty of other places that SQL is
> confusing, and this move seems excessive to me, and I find the
> functionality that is proposed for removal quite useful.
Huh? The functionality proposed for removal is only that of omitting an
On ons, 2010-08-04 at 18:19 -0400, Tom Lane wrote:
>
> This policy also implies that we are never going to allow default
> arguments for aggregates, or at least never have any built-in ones
> that use such a feature.
>
> By my count the following people had offered an opinion on making
> this cha
I wrote:
> Well, I forgot that an aggregate involves more than one catalog row ;-).
> So it's a bit bigger patch than that, but still pretty small and safe.
> See attached.
Applied to HEAD and 9.0. The mistaken case will now yield this:
regression=# select string_agg(f1 order by f1, ',') from te
On 08/05/2010 02:09 PM, Tom Lane wrote:
Merlin Moncure writes:
Attached is a patch to remove the upsert example from the pl/pgsql
documentation. It has a serious bug (see:
http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
to fix. IMNSHO, our code examples should encoura
mmonc...@gmail.com (Merlin Moncure) writes:
> On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
>> mmonc...@gmail.com (Merlin Moncure) writes:
>>> 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
Merlin Moncure writes:
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
> to fix. IMNSHO, our code examples should encourage good practices and
> style.
I was
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
> to fix. IMNSHO, our code examples should encourage good
I started taking a look at the internals of the detoast functions and I came
to the conclusion that I didn't have sufficient understanding of what was
going on to make the correct changes, nor sufficient time to gain that
understanding. Sorry for not getting back sooner. There are a lot of
differ
Merlin Moncure wrote:
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is
> nontrivial to fix. IMNSHO, our code examples should encourage
> good practices and style.
>
>
On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> 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 p
On 8/5/10 6:58 AM, Peter Eisentraut wrote:
> pg_stat_user_functions has an inconsistent notion of what "user" is.
> Whereas the other pg_stat_user_* views filter out non-user objects by
> schema, pg_stat_user_functions checks for language "internal", which
> does not successfully exclude builtin fu
Robert Haas wrote:
> On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis
> wrote:
>>>
>>> > 1. As-is, it's a significant *pessimization* for small arrays,
>>> > because the heap_tuple_untoast_attr_slice code does a
>>> > palloc/copy even when one is not needed because the data is
>>> > already not toaste
Attached is a patch to remove the upsert example from the pl/pgsql
documentation. It has a serious bug (see:
http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
to fix. IMNSHO, our code examples should encourage good practices and
style.
The 'correct' way to do race free upser
I wrote:
> So... No, it's not directly a problem on the server itself.
I just had a thought -- the MERGE code isn't doing anything fancy
with snapshots, is it? I haven't been tracking that discussion too
closely or read the patch. My previous comments assume that the
*snapshot* is stable for
> At 2010 Dev Mtg, we put me down to work on making merge work
> concurrently. That was garbled slightly and had me down as working on
> predicate locking which is the general solution to the problem.
Well, we *still* want predicate locking regardless of what MERGE
supports. It's useful in about
Chris Browne wrote:
> robertmh...@gmail.com (Robert Haas) writes:
>> I suspect Kevin's patch will solve it if using a sufficiently
>> high transaction isolation level, but something else might be
>> needed otherwise. However, I confess to ignorance as to the
>> underlying issues? Why is MERGE
Chris Browne writes:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> yeah -- perhaps you shouldn't be allowed set things like datestyle in
>> functions then.
> That would cause grief for Slony-I, methinks, and probably other things
> that behave somewhat similar.
Yeah, it's not really practical
On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> 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 p
http://groups.yahoo.com/group/syrilalwinl/message
n Bayern 646
Ludwig III. von Bayern: Gesuch Hitlers an L. 179
Lueger, Dr. Karl, BegrunderderChristlich-sozialen Partei (s. diese): L. und die
Christlich-soziale Partei
mmonc...@gmail.com (Merlin Moncure) writes:
> 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 a
robertmh...@gmail.com (Robert Haas) writes:
> On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
>> Looks like MERGE is progressing well.
>>
>> At 2010 Dev Mtg, we put me down to work on making merge work
>> concurrently. That was garbled slightly and had me down as working on
>> predicate lockin
Heikki Linnakangas wrote:
>> However, I confess to ignorance as to the underlying
>> issues? Why is MERGE worse in this regard than, say, UPDATE?
>
> MERGE can be used to implement "upsert", where a row is updated if
> it exists and inserted if it doesn't. I don't think Kevin's patch
> will s
Let's be clear. If you change the postgres code and then things break I
think you're pretty much on your own. We can accept some responsibility
for helping you if you're running our code, but not if you're running
our code which you have subsequently mangled. If you break things you
get to fi
Boszormenyi Zoltan writes:
> Alvaro Herrera Ãrta:
>> Since we're still in the beta phase, it makes sense to apply the fix
>> right now so that it appears in 9.0. No point in waiting for 9.0.1.
> It boils down to the fact that Michael doesn't have too much time
> and no one else knows ECPG in de
On 05/08/10 18:57, Robert Haas wrote:
On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
Looks like MERGE is progressing well.
At 2010 Dev Mtg, we put me down to work on making merge work
concurrently. That was garbled slightly and had me down as working on
predicate locking which is the gene
sub...@cse.iitb.ac.in writes:
> I need suggestion about how region based memory management is done in
> postgres.
Have you read src/backend/utils/mmgr/README ? It's old but still
reasonably accurate.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 05/08/10 18:43, Simon Riggs wrote:
Do we still need me to work on concurrent MERGE, or is that included in
the current MERGE patch (can't see it), or ...
It's not in the current MERGE patch.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mail
Alvaro Herrera írta:
> Excerpts from Michael Meskes's message of jue ago 05 05:39:46 -0400 2010:
>
>> Sorry I thought Zoltan's explanation was clear enough. All prior ECPG
>> versions were fine because dynamic cursor names were only added in 9.0.
>> Apparently only this one place was missed. S
On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
> Looks like MERGE is progressing well.
>
> At 2010 Dev Mtg, we put me down to work on making merge work
> concurrently. That was garbled slightly and had me down as working on
> predicate locking which is the general solution to the problem.
>
>
Excerpts from Michael Meskes's message of jue ago 05 05:39:46 -0400 2010:
> Sorry I thought Zoltan's explanation was clear enough. All prior ECPG
> versions were fine because dynamic cursor names were only added in 9.0.
> Apparently only this one place was missed. So this is a bug in the new
> f
Sorry, wrong word, it should be job.
You mean the wrong type of checkpoint causes XLOG file recovery fail?
I was confused, the XLOG files seem corrupted, is it also caused by the
checkpoint type? If so , why it can do this?
--
Richard
2010-08-05
---
On Thu, Aug 5, 2010 at 7:25 AM, Simon Riggs wrote:
> Also had these fragments as well, if they're still useful. Probably just
> useful as pointers as to what else to change to include the docs.
>
>
> The tests and docs were written from SQL standard, so any deviations
> would need to be flagged. T
Looks like MERGE is progressing well.
At 2010 Dev Mtg, we put me down to work on making merge work
concurrently. That was garbled slightly and had me down as working on
predicate locking which is the general solution to the problem.
Do we still need me to work on concurrent MERGE, or is that inc
2010/8/5 Richard :
> All jods are done by client code, not manually.
What is a jod?
> I still did't not understand what you said.
> What break what?
The fact that you replaced CHECKPOINT_WAIT with CHECKPOINT_IMMEDIATE
is the cause of your problem. You "broke" the correctness of the
system by do
Sorry I thought Zoltan's explanation was clear enough. All prior ECPG versions
were fine because dynamic cursor names were only added in 9.0. Apparently only
this one place was missed. So this is a bug in the new feature, however not
such a major one that it warrants the complete removal IMO. I'
I need suggestion about how region based memory management is done in
postgres. I know the concept of region based memory management and also
know about the functions like memorycontextswitch().
But I am not understanding how Postgres uses hierarchical, region-based
memory management. That is I a
On Thu, Aug 5, 2010 at 11:35 AM, Simon Riggs wrote:
> * It appears we would be in violation of the standard on
> 14.12 General Rule 6 a) i) 2) B), p.890
> (Oh, I wish I was joking, there really is such a paragraph number)
Just shoot me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
All jods are done by client code, not manually.
I still did't not understand what you said.
What break what?
Thandks!
--
Richard
2010-08-05
-
发件人：Heikki Linnakangas
发送日期：2010-08-05 23:21:54
On Thu, 2010-08-05 at 18:17 +0300, Heikki Linnakangas wrote:
> On 05/08/10 17:22, Simon Riggs wrote:
> > On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> >
> >> In the contrary, Simon's instruction says that the DEFAULT action for
> >> the tuple caught by no actions is
> >> WHEN NOT MATCHED
I found other issue :(
postgres=# select name, place from cars group by grouping sets(name, place,());
name | place
---+
bmw |
skoda |
opel |
| germany
| czech rep.
skoda | czech rep.
skoda | germany
bmw | czech rep.
bmw | germany
opel | czech rep
On 05/08/10 17:56, Richard wrote:
> I am sorry, my English is poor.
> I was confused by what you said.
> What do you mean by saying "that'd break it"!
Replacing CHECKPOINT_WAIT with CHECKPOINT_IMMEDIATE broke it. Don't do that.
If you want to change the behavior of pg_start_backup() to perform
On 05/08/10 17:22, Simon Riggs wrote:
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
In the contrary, Simon's instruction says that the DEFAULT action for
the tuple caught by no actions is
WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
From the user's point of view, these two kinds of MER
On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
> So Joshua, can you look on code?
Sure... thanks :)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
I am sorry, my English is poor.
I was confused by what you said.
What do you mean by saying "that'd break it"!
--
Richard
2010-08-05
-
发件人：Tom Lane
发送日期：2010-08-05 22:44:50
收件人：Richard
抄送：
I am sorry, my English is poor.
I was confused by what you said.
What do you mean by saying "that'd break it"!
--
Richard
2010-08-05
-
发件人：Tom Lane
发送日期：2010-08-05 22:44:50
收件人：Richard
抄送：
Thanks for your patience.
I use XLogCtl->Insert.forcePageWrites for XLOG recycling flag. So after
pg_start_backup, no more XLOG files will be recycled. And as I said above,
I make a CHECKPOINT_IMMEDIATE checkpoint in pg_start_backup, instead
CHECKPOINT_WAIT. That all I did to code.
I wonder wh
"Richard" writes:
> For perfromance purpose , I change the pg_start_backup checkpoint type from
> CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
Oh, so this isn't so much "8.3.7" as "randomly-hacked-up 8.3.7".
Yes, that'd break it, I believe. CHECKPOINT_IMMEDIATE doesn't imply
waiti
Kevin Grittner írta:
> Michael Meskes wrote:
>
>> All prior ECPG versions were fine because dynamic cursor names
>> were only added in 9.0. Apparently only this one place was
>> missed. So this is a bug in the new feature, however not such a
>> major one that it warrants the complete removal I
On Thu, Aug 5, 2010 at 10:20 AM, Richard wrote:
> Oh sorry, I missed something. I turned off the XLOG archive in code after
> pg_start_backup so the pg_xlog directory contains all the xlog files.
> And for performance purpose, I change the checkpoint type in pg_start_backup
> to CHECKPOINT_IMMED
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> In the contrary, Simon's instruction says that the DEFAULT action for
> the tuple caught by no actions is
> WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
>
> From the user's point of view, these two kinds of MERGE command may
> have not much
Thanks for replying.
But I could't find relation between the RequestXLogSwitch function and the
error I met.
For perfromance purpose , I change the pg_start_backup checkpoint type from
CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
--
Ri
On Thu, Aug 05, 2010 at 09:55:29PM +0800, Boxuan Zhai wrote:
> On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
>
> > On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > > On 05/08/10 10:46, Simon Riggs wrote:
> > > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > > >> T
1 - 100 of 125 matches
Mail list logo
