On 08/09/10 23:07, Martijn van Oosterhout wrote:
On Mon, Sep 06, 2010 at 07:24:59PM +0200, Markus Wanner wrote:
Do I understand correctly that the purpose of this patch is to work
around the brokenness of select() on very few platforms? Or is there any
additional feature that plain signals don't
On Mon, Sep 06, 2010 at 07:24:59PM +0200, Markus Wanner wrote:
> Do I understand correctly that the purpose of this patch is to work
> around the brokenness of select() on very few platforms? Or is there any
> additional feature that plain signals don't give us?
If the issue is just that selec
Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié sep 08 18:29:35 -0400 2010:
Personally I like the idea of developers not always having to be forced to
choose among two equally good names, and making a wrapper function would be
overkill for this feature.
While I don't agree
Excerpts from Darren Duncan's message of mié sep 08 18:29:35 -0400 2010:
> Personally I like the idea of developers not always having to be forced to
> choose among two equally good names, and making a wrapper function would be
> overkill for this feature.
While I don't agree with the idea of p
Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié sep 08 17:41:40 -0400 2010:
For example, if it wouldn't conflict with anything, one could use the "|" symbol
(mnemonic is that means "alternation" in regular expressions) like this:
CREATE FUNCTION func_very_very_very_very_
Excerpts from Darren Duncan's message of mié sep 08 17:41:40 -0400 2010:
> For example, if it wouldn't conflict with anything, one could use the "|"
> symbol
> (mnemonic is that means "alternation" in regular expressions) like this:
>
>CREATE FUNCTION func_very_very_very_very_long_name|shor
Robert Haas wrote:
On Sep 8, 2010, at 3:17 PM, Darren Duncan wrote:
Bruce Momjian wrote:
Sergey Konoplev wrote:
3.
CREATE FUNCTION func_very_very_very_very_long_name() RETURNS integer AS $$
<< func_alias >>
DECLARE
var_name text := 'bla';
BEGIN
RAISE INFO '%', func_alias.var_name;
...
On Sep 8, 2010, at 3:17 PM, Darren Duncan wrote:
> Bruce Momjian wrote:
>> Sergey Konoplev wrote:
>>> 1.
>>> CREATE FUNCTION func_name(arg_name text) RETURNS integer AS $$
>>> BEGIN
>>>RAISE INFO '%', func_name.arg_name;
>>> ...
>>>
>>> 2.
>>> CREATE FUNCTION func_name() RETURNS integer AS $$
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
Martijn van Oosterhout writes:
> If the issue is just that select() doesn't get interrupted and we don't
> care about a couple of syscalls, would it not be better to simply use
> sigaction to turn on SA_RESTART just prior to the select() and turn it
> off just after. Or are these systems so broken
On tis, 2010-07-13 at 20:28 -0500, Chris wrote:
> So if I have to explicitly set the python interpretor, how would you
> ever have a plpython2u and plpython3u function in the same DB
> (regardless of the fact that they can't run in the same session)? The
> manual implies you could have them both i
OK, so I tried a conversion with the it.po hack I showed before; not
trying to fix any of the other instances yet, but just see what happens
with the 8.4.3/8.4.4 case. It's definitely better:
* Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the
previous commits in the branch ar
Boszormenyi Zoltan writes:
> equal() is called over 8 million times with or without our patch:
>From where, though? You've provided not a shred of evidence that
searching large ec_member lists is the problem.
Also, did the test case you're using ever make it to the list?
Bruce Momjian wrote:
Sergey Konoplev wrote:
1.
CREATE FUNCTION func_name(arg_name text) RETURNS integer AS $$
BEGIN
RAISE INFO '%', func_name.arg_name;
...
2.
CREATE FUNCTION func_name() RETURNS integer AS $$
DECLARE
var_name text := 'bla';
BEGIN
RAISE INFO '%', func_name.var_name;
Bruce Momjian writes:
> ... but if you supply parameters to the function, it does not work:
> test=> CREATE OR REPLACE FUNCTION xxx(aaa INTEGER) RETURNS void AS $$
> ERROR: cannot change name of input parameter "yyy"
> HINT: Use DROP FUNCTION first.
This is failing because yo
On Wed, Sep 8, 2010 at 20:11, Tom Lane wrote:
> Magnus Hagander writes:
I'm using svn trunk revision 5244 from
http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
>
> Just to make sure everybody is on the same page: I've installed svn
> revision 5270, which is the version currently available f
Sergey Konoplev wrote:
> Hi,
>
> On 7 September 2010 20:35, Tom Lane wrote:
> > How does $subject differ from what we already do? ?See
> > http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html
>
> So will it be possible to do things like this?
>
> 1.
> CREATE FUNCTION func_name(arg_n
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> AFAIR, canonical pathkeys are the *only* thing in the planner where pure
>>> pointer equality is interesting. So I doubt this hack is of any use for
>>> EquivalenceClass, even if the lists were likely to be long which
Heikki Linnakangas writes:
> On 08/09/10 20:36, Markus Wanner wrote:
>> It should be possible to reliably determine the platforms that provide
>> an atomic pselect(). For those, I'm hesitant to use a "trick", where
>> pselect() clearly provides a simpler and more "official" alternative.
>> Especia
Magnus Hagander writes:
>>> I'm using svn trunk revision 5244 from
>>> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
Just to make sure everybody is on the same page: I've installed svn
revision 5270, which is the version currently available from that URL,
and is also what Max indicated he was usin
On 08/09/10 20:36, Markus Wanner wrote:
On 09/06/2010 11:03 PM, Tom Lane wrote:
I don't entirely see the point of opening ourselves up to the risk of
using a pselect that's not safe under the hood.
It should be possible to reliably determine the platforms that provide
an atomic pselect(). For
Hi,
On 09/06/2010 11:03 PM, Tom Lane wrote:
I don't entirely see the point of opening ourselves up to the risk of
using a pselect that's not safe under the hood.
It should be possible to reliably determine the platforms that provide
an atomic pselect(). For those, I'm hesitant to use a "trick
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> AFAIR, canonical pathkeys are the *only* thing in the planner where pure
>> pointer equality is interesting. So I doubt this hack is of any use for
>> EquivalenceClass, even if the lists were likely to be long which they
>> aren't.
> No, for Equival
Tom Lane írta:
> Stephen Frost writes:
>
>> I'm not really happy with the naming, comments, or some of the code
>> flow, but I think the concept looks reasonable.
>>
>
> There seems to be a lot of unnecessary palloc/pfree traffic in this
> implementation. Getting rid of that might help th
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> This applies to anything else that may need to be converted
>> from list to tree to decrease planning time. Like ec_members
>> in EquivalenceClass.
>>
>
> AFAIR, canonical pathkeys are the *only* thing in the planner where pure
> pointer equ
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié sep 08 12:12:31 -0400 2010:
>> AFAIR it doesn't keep the first snapshot around. If it did, most of
>> your work on snapshot list trimming would have been useless, no?
> That's my point precisely. The name "IsolationUsesXactSnapsh
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Kevin Grittner's message of vie sep 03 19:06:17 -0400 2010:
> >>> How about IsolationUsesXactSnapshot
>
> > I find this name confusing :-( Doesn't a READ COMMITTED transaction use
> > transaction snapshots as well?
>
> AFAIR it doesn't
Excerpts from Tom Lane's message of mié sep 08 12:12:31 -0400 2010:
> Alvaro Herrera writes:
> > Excerpts from Kevin Grittner's message of vie sep 03 19:06:17 -0400 2010:
> >>> How about IsolationUsesXactSnapshot
>
> > I find this name confusing :-( Doesn't a READ COMMITTED transaction use
> > t
Stephen Frost writes:
> I'm not really happy with the naming, comments, or some of the code
> flow, but I think the concept looks reasonable.
There seems to be a lot of unnecessary palloc/pfree traffic in this
implementation. Getting rid of that might help the speed.
reg
Alvaro Herrera writes:
> Excerpts from Kevin Grittner's message of vie sep 03 19:06:17 -0400 2010:
>>> How about IsolationUsesXactSnapshot
> I find this name confusing :-( Doesn't a READ COMMITTED transaction use
> transaction snapshots as well?
AFAIR it doesn't keep the first snapshot around.
Boszormenyi Zoltan writes:
> This applies to anything else that may need to be converted
> from list to tree to decrease planning time. Like ec_members
> in EquivalenceClass.
AFAIR, canonical pathkeys are the *only* thing in the planner where pure
pointer equality is interesting. So I doubt this
Excerpts from Kevin Grittner's message of vie sep 03 19:06:17 -0400 2010:
> Tom Lane wrote:
>
> > +1 for adding parens; we might want to make a function of it
> > someday.
>
> > How about IsolationUsesXactSnapshot
>
> Patch attached.
I find this name confusing :-( Doesn't a READ COMMITTED
Stephen Frost writes:
> Indeed, but code like this makes me wonder if this is really working the
> way it's supposed to:
> + val1 = (long)pk_left->pk_eclass;
> + val2 = (long)pk_right->pk_eclass;
Ugh. Casting a pointer to long? We do have portable ways to do what
this is trying to do, but
Alvaro Herrera írta:
> Excerpts from Stephen Frost's message of mié sep 08 11:26:55 -0400 2010:
>
>> * Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
>>
>>> but, it seems the problem we are looking is not sufficiently fixed yet.
>>> in our case we shaved off some 18% of planning time or
Stephen Frost írta:
> * Robert Haas (robertmh...@gmail.com) wrote:
>
>> 2010/9/8 Hans-Jürgen Schönig :
>>
>>> but, it seems the problem we are looking is not sufficiently fixed yet.
>>> in our case we shaved off some 18% of planning time or so - looking at the
>>> other top 2 functions i g
=?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= writes:
> here is the patch again.
This patch seems remarkably documentation-free. What is it trying to
accomplish and what is it doing to the planner data structures?
(Which do have documentation BTW.) Also, what will it do to runtime
in normal cases wh
Excerpts from Stephen Frost's message of mié sep 08 11:26:55 -0400 2010:
> * Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
> > but, it seems the problem we are looking is not sufficiently fixed yet.
> > in our case we shaved off some 18% of planning time or so - looking at the
> > other top 2
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/9/8 Hans-Jürgen Schönig :
> > but, it seems the problem we are looking is not sufficiently fixed yet.
> > in our case we shaved off some 18% of planning time or so - looking at the
> > other top 2 functions i got the feeling that more can be done
2010/9/8 Hans-Jürgen Schönig :
> On Sep 8, 2010, at 4:57 PM, Stephen Frost wrote:
>
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> Neat. Have you checked what effect this has on memory consumption?
>>>
>>> Also, don't forget to add it to
>>> https://commitfest.postgresql.org/action/commitfest
* Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
> but, it seems the problem we are looking is not sufficiently fixed yet.
> in our case we shaved off some 18% of planning time or so - looking at the
> other top 2 functions i got the feeling that more can be done to reduce this.
> i guess we h
On Sep 8, 2010, at 4:57 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Neat. Have you checked what effect this has on memory consumption?
>>
>> Also, don't forget to add it to
>> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Would be good to have
* Robert Haas (robertmh...@gmail.com) wrote:
> Neat. Have you checked what effect this has on memory consumption?
>
> Also, don't forget to add it to
> https://commitfest.postgresql.org/action/commitfest_view/open
Would be good to have the patch updated to be against HEAD before
posting to the c
On Wed, Sep 8, 2010 at 10:22 AM, Simon Riggs wrote:
> On Wed, 2010-09-08 at 09:50 -0400, Robert Haas wrote:
>
>> So that means we have to make sure that none of the effects of a
>> transaction can be seen until WAL is fsync'd on the master AND the
>> slave has acked.
>
> Yes, that's right. And I l
On Wed, Sep 8, 2010 at 16:44, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
>>> Where can I find the version of cvs2git we're using?
>
>> I'm using svn trunk revision 5244 from
>> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
>
> [ blink... ] That URL
Magnus Hagander writes:
> On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
>> Where can I find the version of cvs2git we're using?
> I'm using svn trunk revision 5244 from
> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
[ blink... ] That URL seems to want a password.
regar
On Wed, Sep 08, 2010 at 03:22:46PM +0100, Simon Riggs wrote:
> On Wed, 2010-09-08 at 09:50 -0400, Robert Haas wrote:
>
> > So that means we have to make sure that none of the effects of a
> > transaction can be seen until WAL is fsync'd on the master AND the
> > slave has acked.
>
> Yes, that's r
On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> Well, even if the goal is to faithfully represent the bogus history
>>> shown by CVS, cvs2git isn't doing a good job of it.
>
>> Them's fightin' words :-)
>
> Yeah ;-), but they were mainly directed at
here is the patch again.
we accidentally attached a wrong test file to the original posting so it grew
to big. we had to revoke it from the moderator (this happens if you code from
8am to 10pm).
here is just the patch - it is nice and small.
you can easily test it by making yourself a nice paren
On 9/8/10, Tom Lane wrote:
> Marko Kreen writes:
> > Although it does seem unnecessary.
>
>
> The reason I asked for this to be spelled out is that ordinarily,
> a backslash escape \nnn is a very low-level thing that will insert
> exactly what you say. To me it's quite unexpected that the sys
On Wed, 2010-09-08 at 09:50 -0400, Robert Haas wrote:
> So that means we have to make sure that none of the effects of a
> transaction can be seen until WAL is fsync'd on the master AND the
> slave has acked.
Yes, that's right. And I like your example; one for the docs.
There is a slight complex
Michael Haggerty writes:
> Tom Lane wrote:
>> Well, even if the goal is to faithfully represent the bogus history
>> shown by CVS, cvs2git isn't doing a good job of it.
> Them's fightin' words :-)
Yeah ;-), but they were mainly directed at Robert, who AIUI was
asserting that the behavior of "cvs
* Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
> no, we have not checked memory consumption.
> there is still some stuff left to optimize away - it seems we are going close
> to O(n^2) somewhere.
> "equal" is called really often in our sample case as well:
Did the mail with the scripts, etc,
hello ...
no, we have not checked memory consumption.
there is still some stuff left to optimize away - it seems we are going close
to O(n^2) somewhere.
"equal" is called really often in our sample case as well:
ach sample counts as 0.01 seconds.
% cumulative self self tota
Marko Kreen writes:
> Although it does seem unnecessary.
The reason I asked for this to be spelled out is that ordinarily,
a backslash escape \nnn is a very low-level thing that will insert
exactly what you say. To me it's quite unexpected that the system
would editorialize on that to the extent
On Tue, Sep 7, 2010 at 2:14 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> Robert Haas írta:
>> 2010/9/3 PostgreSQL - Hans-Jürgen Schönig :
>>
>>> i tried this one with 5000 unindexed tables (just one col):
>>>
>>> test=# \timing
>>> Timing is on.
>>> test=# prepare x(int4) AS select * from t_data order
On Wed, Sep 8, 2010 at 9:32 AM, Fujii Masao wrote:
> On Wed, Sep 8, 2010 at 10:07 PM, Robert Haas wrote:
>> On Wed, Sep 8, 2010 at 8:30 AM, Fujii Masao wrote:
And in any event, there is ALWAYS a window of
time during which the client doesn't know the transaction has
committed but
On Wed, Sep 8, 2010 at 10:07 PM, Robert Haas wrote:
> On Wed, Sep 8, 2010 at 8:30 AM, Fujii Masao wrote:
>>> And in any event, there is ALWAYS a window of
>>> time during which the client doesn't know the transaction has
>>> committed but other transactions can potentially see its effects.
>>
>>
For the headline generation to work properly, email/file/url/host need
to become skip tokens. Updating the patch with that change.
-Sushant.
On Sat, 2010-09-04 at 13:25 +0530, Sushant Sinha wrote:
> Updating the patch with emitting parttoken and registering it with
> snowball config.
>
> -Sushan
On Wed, Sep 8, 2010 at 8:30 AM, Fujii Masao wrote:
>> And in any event, there is ALWAYS a window of
>> time during which the client doesn't know the transaction has
>> committed but other transactions can potentially see its effects.
>
> Yep. The problem here is that synchronous replication is lik
On Wed, 2010-09-08 at 12:04 +0200, Boszormenyi Zoltan wrote:
> >>
> >> I know why you want that, but I don't think its right.
> >>
> >
> > Agreed. That's why I put the wait before ProcArrayEndTransaction()
> > is called.
> >
>
> Then there is no use to implement individual sync/async
> rep
On 09/08/2010 12:04 PM, Boszormenyi Zoltan wrote:
Then there is no use to implement individual sync/async
replicated transactions, period.
I disagree. Different transactions have different priorities for latency
vs. failure-resistance.
An async replicated transaction
that waits for a sync r
On Wed, Sep 8, 2010 at 8:43 PM, Robert Haas wrote:
> I still don't see why it matters whether you wait before or after
> releasing locks. As soon as the transaction is marked committed in
> CLOG, other transactions can potentially see its effects.
AFAIR, even if CLOG has been updated, until the
On Wed, Sep 8, 2010 at 6:52 AM, Boszormenyi Zoltan wrote:
> Fujii Masao írta:
>> On Wed, Sep 8, 2010 at 7:04 PM, Boszormenyi Zoltan wrote:
>>
>>> Then there is no use to implement individual sync/async
>>> replicated transactions, period. An async replicated transaction
>>> that waits for a sync
Fujii Masao írta:
> On Wed, Sep 8, 2010 at 7:04 PM, Boszormenyi Zoltan wrote:
>
>> Then there is no use to implement individual sync/async
>> replicated transactions, period. An async replicated transaction
>> that waits for a sync replicated transaction because of locks
>> will become implicit
On 9/8/10, Peter Eisentraut wrote:
> On ons, 2010-09-08 at 10:18 +0300, Marko Kreen wrote:
> > On 9/7/10, Peter Eisentraut wrote:
> > > On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > > > > We combine the surrogate pair components to a single code point and
> > > > > encode that in U
On Wed, Sep 8, 2010 at 7:04 PM, Boszormenyi Zoltan wrote:
> Then there is no use to implement individual sync/async
> replicated transactions, period. An async replicated transaction
> that waits for a sync replicated transaction because of locks
> will become implicitely sync. It just waits for a
On ons, 2010-09-08 at 10:18 +0300, Marko Kreen wrote:
> On 9/7/10, Peter Eisentraut wrote:
> > On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > > > We combine the surrogate pair components to a single code point and
> > > > encode that in UTF-8. We don't encode the components separately;
Fujii Masao írta:
> On Tue, Sep 7, 2010 at 6:02 AM, Simon Riggs wrote:
>
>> On Mon, 2010-09-06 at 22:32 +0200, Boszormenyi Zoltan wrote:
>>
>>> (in commit)
>>> write wal record
>>> release locks/etc >> wait for sync ack
>>>
>>> In the first case, the contention is obviously increased.
>>
Tom Lane wrote:
> Well, even if the goal is to faithfully represent the bogus history
> shown by CVS, cvs2git isn't doing a good job of it.
Them's fightin' words :-)
> In the case of
> src/bin/pg_dump/po/it.po, the CVS history claims that the version
> added to REL8_4_STABLE on 2010-05-13 is a ch
On 9/7/10, Peter Eisentraut wrote:
> On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > > We combine the surrogate pair components to a single code point and
> > > encode that in UTF-8. We don't encode the components separately;
> > that
> > > would be wrong.
> >
> > Oh, OK. Should the
70 matches
Mail list logo
