Hello.
> > Renaming ret to quoted and str to ret as the patch attached might
> > make it easily readable.
>
> I think I'm going to refrain from this because it will be more painful
> to backpatch.
I've felt hesitation to do so, too.
The new patch is indeed avoid leaks although which does not la
On Thu, 2012-06-14 at 02:56 +0400, Alexander Korotkov wrote:
> Hackers,
>
>
> attached patch implements quad-tree on ranges. Some performance
> results in comparison with current GiST indexing.
> Index creation is slightly slower. Probably, it need some
> investigation. Search queries on SP-GiST
On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
> On 20 June 2012 14:38, Andres Freund wrote:
> > It incurs a rather high performance overhead due to added memory
> > allocations and added pointer indirections. Thats fine for most of the
> > current users of the List interface, but cer
On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > All of the less popular compilers we support we support precisely
> > because they pretend to be GCC, with the sole exception, as always, of
> > the Microsoft product, in this case MSVC.
>
> This is nonsense. Ther
Based on the discussion and suggestions in this mail chain, following features
can be implemented:
1. To compute the value of max LSN in data pages based on user input whether he
wants it for an individual file,
a particular directory or whole database.
2a. To search the available WAL files
Hi,
On Friday, June 22, 2012 08:48:41 AM Simon Riggs wrote:
> On 21 June 2012 12:41, Andres Freund wrote:
> > 2.)
> > Keep the decoding site up2date by replicating the catalog via normal HS
> > recovery
> > mechanisms.
> >
> > Advantages:
> > * most of the technology is already there
> > * minim
On Jun22, 2012, at 06:32 , D'Arcy Cain wrote:
> So I have my type working now but I had to create a new C function
> that take the opposite argument order. Seems redundant but I could
> not see a better way.
There isn't. Postgres itself contains a huge number of such functions,
e.g. for every *lt
Leon Smith writes:
> It's not clear to me that this is even a solvable problem without modifying
> the schema to include both a "taken" and a "finished processing" state,
> and then letting elements be re-delievered after a period of time.
You maybe should have a look at PGQ from Skytools before
On Wed, Jun 20, 2012 at 9:23 AM, Ryan Kelly wrote:
> I had trouble finding what operators arrays supported or which ones
> had index support or even determining that arrays could be indexed from
> the documentation from the array data type. So, patch.
Yeah, I agree that the && method should be me
On Thu, Jun 21, 2012 at 3:44 AM, Tatsuo Ishii wrote:
>> On Wed, Jun 20, 2012 at 4:04 AM, Tatsuo Ishii wrote:
>>> Currently pgbench -i prints following message every 10k tuples created.
>>>
>>> fprintf(stderr, "%d tuples done.\n", j);
>>>
>>> I think it's long time ago when
On Thu, Jun 21, 2012 at 10:25 AM, Simon Riggs wrote:
> On 21 June 2012 15:00, Tom Lane wrote:
>> Simon Riggs writes:
>>> On 21 June 2012 08:30, Peter Eisentraut wrote:
Nonetheless, it would be a good idea to prune the TODO list regularly,
such as after a release. We used to do that a
On Thursday, June 21, 2012 05:40:08 PM Andres Freund wrote:
> On Thursday, June 21, 2012 03:56:54 PM Florian Pflug wrote:
> > On Jun21, 2012, at 13:41 , Andres Freund wrote:
> > > 3b)
> > > Ensure that enough information in the catalog remains by fudging the
> > > xmin horizon. Then reassemble an a
On 22 June 2012 14:15, Robert Haas wrote:
> Rather, we all like to believe
> that our own ideas are awesome. This is frequently true, but not so
> frequently as we like to believe.
Hmm, for me, awesome has nothing to do with it. I strive to produce
useful features that address real problems in
On Wed, Jun 20, 2012 at 12:24 PM, John Lumby wrote:
> An INSERT which has a RETURNING clause and which is to be rewritten based
> on
> a rule will be accepted if the rule is an "unconditional DO INSTEAD".
> In general I believe "unconditional" means "no WHERE clause", but in
> practi
On Sat, Feb 4, 2012 at 8:18 PM, Noah Misch wrote:
> On Sat, Feb 04, 2012 at 03:41:27PM -0800, Jeff Davis wrote:
>> On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
>> > Yeah. Personally I would be sad if initdb got noticeably slower, and
>> > I've never seen or heard of a failure that this woul
>> I am not convinced that it's a good idea to wake up every walsender
>> every time we do XLogInsert(). XLogInsert() is a super-hot code path,
>> and adding more overhead there doesn't seem warranted. We need to
>> replicate commit, commit prepared, etc. quickly, by why do we need to
>> worry ab
On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
wrote:
>> I'm confused by this remark, because surely the query planner does it this
>> way only if there's no LIMIT. When there is a LIMIT, we choose based on
>> the startup cost plus the estimated fraction of the total cost we expect
>> to pay base
Andres Freund writes:
> On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
>> Why are you using the stdlib's ? Why have you used the
>> NDEBUG macro rather than USE_ASSERT_CHECKING? This might make sense if
>> the header was intended to live in port, but it isn't, right?
> That should pr
On Friday, June 22, 2012 04:09:59 PM Robert Haas wrote:
> >> I am not convinced that it's a good idea to wake up every walsender
> >> every time we do XLogInsert(). XLogInsert() is a super-hot code path,
> >> and adding more overhead there doesn't seem warranted. We need to
> >> replicate commit,
On Friday, June 22, 2012 04:18:35 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
> >> Why are you using the stdlib's ? Why have you used the
> >> NDEBUG macro rather than USE_ASSERT_CHECKING? This might make sense if
> >> the header was i
On Fri, Jun 22, 2012 at 10:19 AM, Andres Freund wrote:
> On Friday, June 22, 2012 04:09:59 PM Robert Haas wrote:
>> >> I am not convinced that it's a good idea to wake up every walsender
>> >> every time we do XLogInsert(). XLogInsert() is a super-hot code path,
>> >> and adding more overhead the
Andres Freund writes:
> Oh, I and Peter weren't talking about the pg_list.h stuff, it was about my
> 'embedded list' implementation which started this subthread. The
> pg_list.h/list.c stuff isn't problematic as far as I have seen in profiles;
> its checks are pretty simple so I do not find tha
On Friday, June 22, 2012 04:34:33 PM Robert Haas wrote:
> On Fri, Jun 22, 2012 at 10:19 AM, Andres Freund
wrote:
> > On Friday, June 22, 2012 04:09:59 PM Robert Haas wrote:
> >> >> I am not convinced that it's a good idea to wake up every walsender
> >> >> every time we do XLogInsert(). XLogInse
On Friday, June 22, 2012 04:41:20 PM Tom Lane wrote:
> Andres Freund writes:
> > Oh, I and Peter weren't talking about the pg_list.h stuff, it was about
> > my 'embedded list' implementation which started this subthread. The
> > pg_list.h/list.c stuff isn't problematic as far as I have seen in
> >
Kyotaro HORIGUCHI writes:
>>> +REGRESS_LC0 = $(subst .sql,,$(shell cd sql; ls plperl_lc_$(shell echo
>> Hrm, that's quite cute. I dunno if there is a more cannon way of doing
>> the above-- but it seems to work. I'm not sure this regression test is
>> worth it. I'm thinking maybe we should just r
Andres Freund writes:
> On Friday, June 22, 2012 04:41:20 PM Tom Lane wrote:
>> Well, so does list.c, so I'd expect the performance risks to be similar.
> I don't think list.c does so:
Huh, OK. I seem to remember that the original version actually chased
down the whole list and verified that th
On Fri, Jun 22, 2012 at 10:45 AM, Andres Freund wrote:
>> > the likelihood of that as you know.
>> Hmm, well, I guess. I'm still not sure I really understand what
>> benefit we're getting out of this. If we lose a few WAL records for
>> an uncommitted transaction, who cares? That transaction is
On 12-06-22 07:11 AM, Florian Pflug wrote:
On Jun22, 2012, at 06:32 , D'Arcy Cain wrote:
So I have my type working now but I had to create a new C function
that take the opposite argument order. Seems redundant but I could
not see a better way.
There isn't. Postgres itself contains a huge num
On Fri, Jun 22, 2012 at 5:25 AM, Amit Kapila wrote:
> Based on the discussion and suggestions in this mail chain, following
> features can be implemented:
>
> 1. To compute the value of max LSN in data pages based on user input whether
> he wants it for an individual file,
> a particular direc
"D'Arcy Cain" writes:
> ... The issue here is that the operator is SC but
> the args are different types.
Well, that's a weird way of defining self-commutating, but ...
> It would be nice if there was a way
> to automatically generate code that reverses arguments. Maybe such
> a thing belongs i
On 06/22/2012 09:45 AM, Simon Riggs wrote:
On 22 June 2012 14:15, Robert Haas wrote:
Rather, we all like to believe
that our own ideas are awesome. This is frequently true, but not so
frequently as we like to believe.
Hmm, for me, awesome has nothing to do with it. I strive to produce
usef
On Wed, Jun 20, 2012 at 4:36 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> 1. I still think we ought to get rid of the notion of BEFORE or AFTER
>> (i.e. pg_event_trigger.evttype) and just make that detail part of the
>> event name (e.g. pg_event_trigger.evtevent). Many easily forseeable
On 12-06-22 11:36 AM, Tom Lane wrote:
"D'Arcy Cain" writes:
The thing is that either of those approaches is hugely more expensive
than just providing a second C function. It costs probably thousands
of cycles to inline that SQL function, each time it's used in a query.
I assumed itwould be mo
On Friday, June 22, 2012 04:59:45 PM Robert Haas wrote:
> On Fri, Jun 22, 2012 at 10:45 AM, Andres Freund
wrote:
> >> > the likelihood of that as you know.
> >>
> >> Hmm, well, I guess. I'm still not sure I really understand what
> >> benefit we're getting out of this. If we lose a few WAL rec
On 20-06-2012 17:40, Marko Kreen wrote:
> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug wrote:
>> I'm starting to think that relying on SSL/TLS for compression of
>> unencrypted connections might not be such a good idea after all. We'd
>> be using the protocol in a way it quite clearly never was
It has now happened at least twice that builds on spponbill started to
fail after it failed during ECPGcheck:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2012-06-19%2023%3A00%3A04
the first failure was:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2012-05-24%
Stefan Kaltenbrunner writes:
> It has now happened at least twice that builds on spponbill started to
> fail after it failed during ECPGcheck:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2012-06-19%2023%3A00%3A04
> the first failure was:
> http://www.pgbuildfarm.org/cgi-bin/sh
On 06/22/2012 02:34 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
It has now happened at least twice that builds on spponbill started to
fail after it failed during ECPGcheck:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2012-06-19%2023%3A00%3A04
the first failure was:
ht
On Fri, Jun 22, 2012 at 2:16 PM, Stefan Kaltenbrunner
wrote:
> sending a manual kill -15 to either of them does not seem to make them
> exit either...
>
> I did some further investiagations with robert on IM but I don't think
> he has any further ideas other than that I have a weird OS :)
> It see
On Friday, June 22, 2012 08:51:55 PM Robert Haas wrote:
> On Fri, Jun 22, 2012 at 2:16 PM, Stefan Kaltenbrunner
>
> wrote:
> > sending a manual kill -15 to either of them does not seem to make them
> > exit either...
> >
> > I did some further investiagations with robert on IM but I don't think
On 06/22/2012 08:34 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> It has now happened at least twice that builds on spponbill started to
>> fail after it failed during ECPGcheck:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2012-06-19%2023%3A00%3A04
>> the first failur
On Friday, June 22, 2012 03:22:03 PM Andres Freund wrote:
> On Thursday, June 21, 2012 05:40:08 PM Andres Freund wrote:
> > On Thursday, June 21, 2012 03:56:54 PM Florian Pflug wrote:
> > > On Jun21, 2012, at 13:41 , Andres Freund wrote:
> > > > 3b)
> > > > Ensure that enough information in the cat
Stefan Kaltenbrunner writes:
> On 06/22/2012 08:34 PM, Tom Lane wrote:
>> Still, panther is NetBSD so there may be some general BSD flavor to
>> whatever's going on here.
> yeah the threading reference was mostly because all backtraces contain
> references to threading libs and because the thread
Andres Freund writes:
> On Friday, June 22, 2012 08:51:55 PM Robert Haas wrote:
>> I remarked to Stefan that the symptoms seem consistent with the idea
>> that the children have signals blocked. But I don't know how that
>> could happen.
> You cannot block sigkill.
sigterm is at issue, not sigk
Robert Haas writes:
>> It's not before/after anymore, but rather addon/replace if you will. I
>> kept the INSTEAD OF keyword for the replace semantics, that you've been
>> asking me to keep IIRC, with security policy plugins as a use case.
>>
>> Now we can of course keep those semantics and embed
Robert Haas writes:
> 73%? I think it's got about 15% overlap.
83.7% of stats are wrong. This one included.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On 06/22/2012 09:39 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Friday, June 22, 2012 08:51:55 PM Robert Haas wrote:
>>> I remarked to Stefan that the symptoms seem consistent with the idea
>>> that the children have signals blocked. But I don't know how that
>>> could happen.
>
>> You can
I wrote:
> I believe the right fix for both of these issues is to add knowledge of
> the section concept to the topological sort logic, so that an ordering
> that puts POST_DATA before DATA or PRE_DATA after DATA is considered to
> be a dependency-ordering violation. One way to do that is to add d
Stefan Kaltenbrunner writes:
> On 06/22/2012 09:39 PM, Tom Lane wrote:
>> (Hey Stefan, is there a way on BSD to check a process's signals-blocked
>> state from outside? If so, next time this happens you should try to
>> determine the children's signal state.)
> with help from RhodiumToad on IRC:
On 06/22/2012 11:02 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> On 06/22/2012 09:39 PM, Tom Lane wrote:
>>> (Hey Stefan, is there a way on BSD to check a process's signals-blocked
>>> state from outside? If so, next time this happens you should try to
>>> determine the children's signal
Stefan Kaltenbrunner writes:
>>> PID PENDING CAUGHT IGNORED BLOCKED COMMAND
>>> 12480 20004004 34084005 c942b002 fffefeff postgres: writer process
>>> 9841 20004004 34084007 c942b000 fffefeff postgres: wal writer process
> this seems to be SIGUSR1,SIGTERM and SIGQUIT
OK, I looked up OpenBSD
oh, and just for comparison's sake, what do the postmaster's signal
masks look like?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 22, 2012 at 2:57 PM, Andres Freund wrote:
> On Friday, June 22, 2012 08:51:55 PM Robert Haas wrote:
>> On Fri, Jun 22, 2012 at 2:16 PM, Stefan Kaltenbrunner
>>
>> wrote:
>> > sending a manual kill -15 to either of them does not seem to make them
>> > exit either...
>> >
>> > I did som
On Fri, Jun 22, 2012 at 12:28 PM, D'Arcy Cain wrote:
>> I doubt that an "auto reverse the arguments" facility would be very
>> much cheaper. You could maybe argue that the aggregated maintenance
>> and space costs of all the commutator-pair functions are enough to
>> justify having some such solu
> The biggest problem with pgfincore from my point of view is that it
> only works under Linux, whereas I use a MacOS X machine for my
> development, and there is also Windows to think about. Even if that
> were fixed, though, I feel we ought to have something in the core
> distribution. This pa
http://pgolub.wordpress.com/2012/06/22/backward-compatibility-never-heard-of-it
If we had stable system views for all database objects (stable as in we
just append to them), then refactoring our system tables wouldn't break
things for our users. Just sayin'.
(and don't tell me about information_
On Fri, Jun 22, 2012 at 10:04:23AM -0400, Robert Haas wrote:
> On Sat, Feb 4, 2012 at 8:18 PM, Noah Misch wrote:
> > If we add fsync calls to the initdb process, they should cover the entire
> > data
> > directory tree. ?This patch syncs files that initdb.c writes, but we ought
> > to
> > also s
On Fri, Jun 22, 2012 at 9:30 PM, Josh Berkus wrote:
> http://pgolub.wordpress.com/2012/06/22/backward-compatibility-never-heard-of-it
>
> If we had stable system views for all database objects (stable as in we
> just append to them), then refactoring our system tables wouldn't break
> things for o
On 12-06-22 07:09 PM, Robert Haas wrote:
I think DirectionFunctionCall2 is what you want.
Can you elaborate? I could not find a single hit in Google or the
documentation search on the PG site and it does not appear anywhere
in the source distribution.
--
D'Arcy J.M. Cain | Democracy
"D'Arcy Cain" writes:
> On 12-06-22 07:09 PM, Robert Haas wrote:
>> I think DirectionFunctionCall2 is what you want.
> Can you elaborate? I could not find a single hit in Google or the
> documentation search on the PG site and it does not appear anywhere
> in the source distribution.
He meant D
On Fri, Jun 22, 2012 at 9:05 PM, Robert Haas wrote:
> On Fri, Jun 22, 2012 at 9:30 PM, Josh Berkus wrote:
>> http://pgolub.wordpress.com/2012/06/22/backward-compatibility-never-heard-of-it
>>
>> If we had stable system views for all database objects (stable as in we
>> just append to them), then
On 12-06-23 12:17 AM, Tom Lane wrote:
"D'Arcy Cain" writes:
On 12-06-22 07:09 PM, Robert Haas wrote:
I think DirectionFunctionCall2 is what you want.
Can you elaborate? I could not find a single hit in Google or the
documentation search on the PG site and it does not appear anywhere
in the
On 06/22/2012 11:53 PM, Tom Lane wrote:
> oh, and just for comparison's sake, what do the postmaster's signal
> masks look like?
# ps -o pid,sig,sigcatch,sigignore,sigmask,command -p 18020
PID PENDING CAUGHT IGNORED BLOCKED COMMAND
180200 74084007 8972b0000
/home/pgbuild/
On 06/22/2012 11:47 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
PID PENDING CAUGHT IGNORED BLOCKED COMMAND
12480 20004004 34084005 c942b002 fffefeff postgres: writer process
9841 20004004 34084007 c942b000 fffefeff postgres: wal writer process
>
>> this seems to be SIGU
64 matches
Mail list logo
