"Bramandia Ramadhana" <[EMAIL PROTECTED]> writes:
> Hm the backtrace() method does not give the line numbers of the methods in
> the stack trace, it only gives the hexadecimal offset. Is there anyway to
> retrieve the line numbers?
Did you build with --enable-debug?
regard
Hm the backtrace() method does not give the line numbers of the methods in
the stack trace, it only gives the hexadecimal offset. Is there anyway to
retrieve the line numbers?
I have tried to Google it but to no avail.
Regards,
Bramandia R.
On Tue, Nov 4, 2008 at 12:26 PM, Emmanuel Cecchet <[EM
2008/11/15 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>> > david=# explain select date,lag(date,1) over (order by date) from
>> > meter_Readings order by date;
>> > QUERY PLAN
>> > ---
Hi,
On Mon, 2008-11-17 at 00:41 +0200, Devrim GÜNDÜZ wrote:
> On Sun, 2008-11-16 at 12:12 -0500, Andrew Dunstan wrote:
> > But maybe someone would like to upgrade their buildfarm member
> > regardless of that.
>
> I installed 2.4 to Orca, and the next builds are at:
I forced a manual build:
ht
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So about the only real answer is going to be preloading. It seems worth
>> considering that on machines where can_run_two is true, we should just
>> go ahead and initialize both interps at _PG_init time, so as to allow
>> the "require
Tom Lane wrote:
So about the only real answer is going to be preloading. It seems worth
considering that on machines where can_run_two is true, we should just
go ahead and initialize both interps at _PG_init time, so as to allow
the "require Safe" overhead to be bought back by preloading.
> On the whole, I think we'd be better off to just add more arguments
> to the DefineCustomXXXVariable functions, as in the original patch
> (and while we're at it, fix the problem of where the boot_val comes
> from, as suggested in the above-referenced message). At least that will
> result in obv
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Perhaps more to the point, guc_tables.h is a file that we don't even
>> want the majority of the backend including. Why would we think it's
>> a good idea to make that part of the public API to external modules?
Tom Lane <[EMAIL PROTECTED]> wrote:
> Perhaps more to the point, guc_tables.h is a file that we don't even
> want the majority of the backend including. Why would we think it's
> a good idea to make that part of the public API to external modules?
Hmmm... do we need to move config_group enumera
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> What happens
>> when we add some field or other to those structs?
> There are problems when we modify the middle fields in those
> structs, but it means modification of existing arguments in
> DefineCustomXXXVari
Tom Lane <[EMAIL PROTECTED]> wrote:
> void DefineCustomVariable(enum config_type type, const void *variable);
> What happens
> when we add some field or other to those structs?
I considered the case and chose the new interface because it behaves
*well* in the case. We can freely add new fields
On Sun, 2008-11-16 at 12:12 -0500, Andrew Dunstan wrote:
> But maybe someone would like to upgrade their buildfarm member
> regardless of that.
I installed 2.4 to Orca, and the next builds are at:
0 3 * * * cd /home/pgbuildfarm/build-farm && ./run_build.pl
0 4 * * * cd /home/pgbuildfarm/build-f
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Mon, 2008-11-10 at 18:02 +0900, ITAGAKI Takahiro wrote:
>> That's because explain.log_analyze requires executor instruments,
>> and it's not free. I think we'd better to have an option to avoid
>> the overheads... Oops, I found my bug when force_instrumen
The auto-explain patch needs a way to set the GUC "flags" for a custom
GUC variable; a capability that was unaccountably left out of the
original DefineCustomXXXVariable APIs. The original version of the patch
dealt with this by changing those APIs, which I complained about here:
http://archives.p
Wee need to use shared memory for passing one BIGINT value(is session
throwout triggers), can you advice the method to get/set it with best
performance ?
2008/11/16 Tom Lane <[EMAIL PROTECTED]>:
> "Oleg Serov" <[EMAIL PROTECTED]> writes:
>> So, how i must optimize it?
>
> The short-term answer see
"Oleg Serov" <[EMAIL PROTECTED]> writes:
> So, how i must optimize it?
The short-term answer seems to be "preload and use plperlu".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... which leads to the conclusion that those random little startup things
>> plperl does are just unbelievably expensive.
> I suspect much of this time is taken in loading perl modules, (strict,
> Safe, utf8, SPI among others), not i
So, how i must optimize it?
2008/11/16 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Tom Lane wrote:
>>
>> I wrote:
>>
>>>
>>> On my Fedora 9 machine, the overhead to start plperl seems to be about
>>> 40 msec. This compares unfavorably to the time to start perl from the
>>> command line, which is un
On Sun, Nov 16, 2008 at 9:52 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> If there is a ^M in that file then your cvs program probably put it there.
> It is not present in my copy on mingw. Which cvs program are you using?
>
> (EOL in text files on Windows is ^M^J in fact, not ^M alone.)
>
ok
Tom Lane wrote:
I wrote:
On my Fedora 9 machine, the overhead to start plperl seems to be about
40 msec. This compares unfavorably to the time to start perl from the
command line, which is under 4 msec. I see that /usr/bin/perl pulls in
libperl.so, so it's paying the same shlib overhead a
Tom Lane wrote:
Michael Meskes <[EMAIL PROTECTED]> writes:
On Sat, Nov 15, 2008 at 05:39:49PM -0500, Tom Lane wrote:
I wonder how many other projects' code will break?
Me too. The ecpg.trailer code was just copied from the old preproc.y so I guess
this bug has been in bef
On Sun, Nov 16, 2008 at 11:33:06AM -0500, Tom Lane wrote:
> > Me too. The ecpg.trailer code was just copied from the old preproc.y so I
> > guess
> > this bug has been in before we moved to the new automatic build.
>
> If so then we would need to back-patch, but if I'm correctly identifying
> the
I wrote:
> On my Fedora 9 machine, the overhead to start plperl seems to be about
> 40 msec. This compares unfavorably to the time to start perl from the
> command line, which is under 4 msec. I see that /usr/bin/perl pulls in
> libperl.so, so it's paying the same shlib overhead as we do. How is
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is a one-off cost per connection of 100ms so bothersome?
I think the complaint is that there's no obvious reason for it to be so
high.
On my Fedora 9 machine, the overhead to start plperl seems to be about
40 msec. This compares unfavorably to the tim
On Sun, Nov 16, 2008 at 09:15:28AM -0500, Andrew Dunstan wrote:
> Oleg Serov wrote:
> >Hey, you are wrong, compile time is 1 ms, but not 100 ms, it hapens on
> >first plperl function call, it is perl init problem. not function
> >compilation.
> >
>
> Please do NOT top-answer - it makes threads t
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Sat, Nov 15, 2008 at 05:39:49PM -0500, Tom Lane wrote:
>> I wonder how many other projects' code will break?
> Me too. The ecpg.trailer code was just copied from the old preproc.y so I
> guess
> this bug has been in before we moved to the new automa
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> IIRC, ^M is the EOL character on windows. latest cvs failed to compile
> in my mingw env because src/backend/utils/Gen_dummy_probes.sed had
> that character, i had to manually remove it to continue.
There's no such character in my copy.
> Besides, ht
Oleg Serov wrote:
Hey, you are wrong, compile time is 1 ms, but not 100 ms, it hapens on
first plperl function call, it is perl init problem. not function
compilation.
Please do NOT top-answer - it makes threads totally unreadable.
Is a one-off cost per connection of 100ms so bothersome?
Jaime Casanova wrote:
Hi,
IIRC, ^M is the EOL character on windows. latest cvs failed to compile
in my mingw env because src/backend/utils/Gen_dummy_probes.sed had
that character, i had to manually remove it to continue.
Besides, http://archives.postgresql.org/pgsql-committers/2008-11/msg0017
Hi.
All suggestion is appropriate and has been checked.
CVS-HEAD was examined by MinGW.
$ make check NO_LOCALE=true
...
===
All 118 tests passed.
===
Then, It continues and a review is desired.
Thanks!
Regatrds,
Hiroshi Saito
- Original Messag
On Fri, Nov 14, 2008 at 10:51:57AM -0500, Tom Lane wrote:
> In fact, if the patch were to break torn-page handling, it would be
> 100% likely to be a net *decrease* in system reliability. It would add
> detection of a situation that is not supposed to happen (ie, storage
> system fails to return t
Hey, you are wrong, compile time is 1 ms, but not 100 ms, it hapens on
first plperl function call, it is perl init problem. not function
compilation.
2008/11/16 Oleg Serov <[EMAIL PROTECTED]>:
> Why pl/pgsql doesn't have this effect ?
>
> 2008/11/16 Andrew Dunstan <[EMAIL PROTECTED]>:
>>
>>
>> Ole
On Sat, Nov 15, 2008 at 2:00 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Fujii Masao wrote:
>>
>> Attached is the latest version of Synch Rep patch.
>
> Why do we need a separate XLogsndRqst variable in shared memory? Don't we
> always want to send the WAL up to the same point as we flush i
Why pl/pgsql doesn't have this effect ?
2008/11/16 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Oleg Serov wrote:
>>
>> When perl function executes first time, it is too slowly, but if
>> execute perl function(not function which executed first time) again it
>> runs in 1000 times faster. Why ? how ca
34 matches
Mail list logo
