Re: [HACKERS] Roadmap for a Win32 port
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED]] > Sent: 08 June 2002 22:48 > To: Peter Eisentraut > Cc: PostgreSQL-development > Subject: Re: Roadmap for a Win32 port > > > > > > > Also, it seems Win32 doesn't need these scripts, except initdb. > > > > The utility of these programs is independent of the > platform. If we > > think pg_dumpall is not useful, then let's remove it. > > I think the first two targets for C-ification would be > pg_dumpall and initdb. The others have SQL equivalents. > Maybe pg_ctl too. I looked at this issue some time ago & came to the conclusion that the only scripts that Win32 really needed were pg_dumpall, initdb & initlocation. The others have SQL equivalents as you say, apart from pg_ctl which under Windows should probably (and generally is) be replaced by the SCM (Service Control Manager). The only thing that comes to mind that the SCM can't do is a reload. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] revised sample SRF C function; proposed SRF API
Joe Conway <[EMAIL PROTECTED]> writes: > Returning GUC variable "SHOW ALL" results as a query result has been > discussed before, and I thought there was agreement that it was a > desirable backend feature. So it is, but I had expected it to be implemented by changing the behavior of SHOW, same as we did for EXPLAIN. > Is the approach in my patch still too ugly to allow a builtin SRF (set > the function return type to 0 in pg_proc.h, create a view and fix the > pg_proc entry during initdb)? Too ugly for my taste anyway ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Project scheduling issues (was Re: Per tuple overhead,
On Sun, 9 Jun 2002, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > I *really* wish ppl would stop harping on the length of the last beta > > cycle ... I will always rather delay a release due to an *known* > > outstanding bug, especially one that just needs a little bit more time to > > work out, then to release software "on time" ala Microsoft ... > > I don't think that's at issue here. No one was suggesting that we'd > force an *end* to beta cycle because of schedule issues. We ship when > we're satisfied and not before. I'm saying that I want to try to > *start* the beta test period on-time, rather than letting the > almost-beta state drag on for months --- which we did in each of the > last two cycles. Development time is productive, and beta-test time > is productive, but we're-trying-to-start-beta time is not very > productive ... Agreed on all accounts ... which is why this time, I want to do a proper branch when beta starts ... hell, from what I've seen suggested here so far, we have no choice ... At least then we can 'rip out' something from the beta tree without having to remove and re-add it to the development one later, hoping that they're changes haven't been affected by someone else's ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp/Interval proposals: Part 2
"Josh Berkus" <[EMAIL PROTECTED]> writes: > Yeah. I'd love to have somebody explain this to me. I noticed when > zinc was mentioned, but I don't know *what* it is. Care to send me a > link? I think http://www.twinsun.com/tz/tz-link.htm is the underlying timezone database that Thomas is referring to. I can't find anything named zinc that seems relevant. I'm not as excited about sticking the info into Postgres tables as Thomas seems to be. I think that's (a) unnecessary and (b) likely to create severe startup problems, since the postmaster needs access to timezone info to interpret the TZ environment variable, but it can't read the database. It seems to me that a precalculated timezone table is plenty good enough. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Agreed on all accounts ... which is why this time, I want to do a proper > branch when beta starts ... hell, from what I've seen suggested here so > far, we have no choice ... At least then we can 'rip out' something from > the beta tree without having to remove and re-add it to the development > one later, hoping that they're changes haven't been affected by someone > else's ... Well, let's give that a try and see how it goes. I'm a bit worried about the amount of double-patching we'll have to do, but other projects seem to manage to cope with multiple active branches... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] tuplesort: unexpected end of data
NunoACHenriques <[EMAIL PROTECTED]> writes: > Jun 2 06:29:37 srv31 postgres[2986]: [57279] ERROR: tuplesort: unexpected end of >data Hmm. This is an internal consistency check in the sort code. Perhaps you've found a bug, but there's not enough info here to do much. Can you provide the EXPLAIN plan for the query that's triggering the error? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tuplesort: unexpected end of data
Hi! I should say that this error is a non-deterministic one. It happened once/twenty... ---explain info- spid=> explain insert into warehouse_tmp (uri, expression, n, relevance, spid_measure, size, title, sample) spid->select d.uri, dn.expression, n.n, dn.relevance, d.spid_measure, d.size, d.title, dn.sample spid->from document as d spid-> inner join (document_n_gram as dn spid(> inner join n_gram as n spid(> on (dn.expression = n.expression)) spid-> on (d.uri = dn.uri) spid->order by dn.expression asc, n.n asc ; NOTICE: QUERY PLAN: Subquery Scan *SELECT* (cost=3895109.07..3895109.07 rows=1009271 width=886) -> Sort (cost=3895109.07..3895109.07 rows=1009271 width=886) -> Hash Join (cost=1155071.81..2115045.12 rows=1009271 width=886) -> Merge Join (cost=1154294.92..1170599.85 rows=1009271 width=588) -> Sort (cost=1001390.67..1001390.67 rows=1009271 width=439) -> Seq Scan on document_n_gram dn (cost=0.00..49251.71 rows=1009271 width=439) -> Sort (cost=152904.25..152904.25 rows=466345 width=149) -> Seq Scan on n_gram n (cost=0.00..12795.45 rows=466345 width=149) -> Hash (cost=767.71..767.71 rows=3671 width=298) -> Seq Scan on document d (cost=0.00..767.71 rows=3671 width=298) EXPLAIN spid=> If you need more info, just ask. I'll be glad to contribute to a so interesting project! :-) -- o__Bem haja, _.>/ _ NunoACHenriques (_) \(_) ~~~ http://students.fct.unl.pt/users/nuno/ On Sun, 9 Jun 2002, Tom Lane wrote: >NunoACHenriques <[EMAIL PROTECTED]> writes: >> Jun 2 06:29:37 srv31 postgres[2986]: [57279] ERROR: tuplesort: unexpected end of >data > >Hmm. This is an internal consistency check in the sort code. Perhaps >you've found a bug, but there's not enough info here to do much. Can >you provide the EXPLAIN plan for the query that's triggering the error? > > regards, tom lane > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tuplesort: unexpected end of data
NunoACHenriques <[EMAIL PROTECTED]> writes: > I should say that this error is a non-deterministic one. It happened > once/twenty... Is the data in the tables changing constantly? If you can repeat the same query on the same data and get varying results, then we're dealing with something odder than I suspected. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tuplesort: unexpected end of data
Hi! On Sun, 9 Jun 2002, Tom Lane wrote: >Is the data in the tables changing constantly? If you can repeat the >same query on the same data and get varying results, then we're >dealing with something odder than I suspected. > > regards, tom lane > Not constantly, once a day. I cannot repeat the same query on the same data, but the app does the same query over similar data (most static Web docs with little variation of about 50 docs in 7000) but diferent to PG because of the drop/create tables before the new fill... -- o__Bem haja, _.>/ _ NunoACHenriques (_) \(_) ~~~ http://students.fct.unl.pt/users/nuno/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tuplesort: unexpected end of data
NunoACHenriques <[EMAIL PROTECTED]> writes: > On Sun, 9 Jun 2002, Tom Lane wrote: >> Is the data in the tables changing constantly? > Not constantly, once a day. Can't you set up a situation where the failure is reproducible, then? On a day where you get the failure, dump the database and see if you can load the data into a fresh database and reproduce the problem. I spent some time looking at the tuplesort code and could not see any reason for this failure. All that code has been fairly stable since it was written for 7.0, and AFAIR no one else has reported this error message. So either you've got a quite-unusual corner case that's tickling a previously unseen bug, or you've got flaky hardware that for some reason is manifesting in this way. I don't necessarily believe the flaky-hardware theory, but I can't make much progress on the bug theory without a test case to look at. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Perl build fix attempted
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> On HPUX 10.20, using perl 5.6.1, plperl builds without complaint but
>> SIGSEGV's upon use. AFAIR this worked last time I tried it; any idea
>> what you might have changed?
> I have written it so that the commands that are executed during the build
> should be the same. Can you send me the build output from current and
> from before the change (7.2 should work), and the generated Makefile from
> before the change?
Attached. However, I have just found that in fact the 7.2 build does
not work either :-( ... which is peculiar, because it worked fine in
January. (I think. It could be that I tested the changes I made in
January on a different machine --- can't recall for sure. I am pretty
sure that I tested plperl on this machine last June.)
I am suspicious of the -D symbols that were used before and are not
being supplied now. (A less appetizing prospect is that gcc code just
plain won't interoperate with cc-generated code.) The perl installation
is vanilla 5.6.1 configuration except for requesting that a shared
libperl be built.
regards, tom lane
Current sources "make" log:
make[3]: Entering directory `/home/postgres/pgsql/src/pl/plperl'
gcc -O1 -g -fPIC -I. -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE -I../../../src/include
-c -o plperl.o plperl.c
gcc -O1 -g -fPIC -I. -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE -I../../../src/include
-c -o eloglvl.o eloglvl.c
/opt/perl5.6.1/bin/perl /opt/perl5.6.1/lib/5.6.1/ExtUtils/xsubpp -typemap
/opt/perl5.6.1/lib/5.6.1/ExtUtils/typemap SPI.xs >SPI.c
gcc -O1 -g -fPIC -I. -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE -I../../../src/include
-c -o SPI.o SPI.c
ar crs libplperl.a `lorder plperl.o eloglvl.o SPI.o | tsort`
ranlib libplperl.a
/usr/ccs/bin/ld -b +b /home/postgres/testversion/lib plperl.o eloglvl.o SPI.o
-L/usr/local/lib /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/auto/DynaLoader/DynaLoader.a
-L/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE -lperl -lnsl_s -ldld -lm -lc -lndir -lcrypt
-lsec -o libplperl.sl
/usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file
(/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/auto/DynaLoader/DynaLoader.a(DynaLoader.o)) was
detected. The linked output may not run on a PA 1.x system.
rm -f libplperl.sl.0
ln -s libplperl.sl libplperl.sl.0
make[3]: Leaving directory `/home/postgres/pgsql/src/pl/plperl'
REL7_2 "make" log:
make[3]: Entering directory `/home/postgres/REL7_2/pgsql/src/pl/plperl'
plperl_installdir='$(DESTDIR)/home/postgres/version72/lib' \
/opt/perl5.6.1/bin/perl Makefile.PL INC='-I. -I../../../src/include'
Writing Makefile for plperl
make -f Makefile all VPATH=
make[4]: Entering directory `/home/postgres/REL7_2/pgsql/src/pl/plperl'
cc -c -I. -I../../../src/include -D_HPUX_SOURCE -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae -O -DVERSION=\"0.10\"
-DXS_VERSION=\"0.10\" +z -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE plperl.c
cpp: "perl.h", line 2155: warning 2001: Redefinition of macro DEBUG.
cc: "plperl.c", line 244: warning 558: Empty declaration.
cc -c -I. -I../../../src/include -D_HPUX_SOURCE -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae -O -DVERSION=\"0.10\"
-DXS_VERSION=\"0.10\" +z -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE eloglvl.c
/opt/perl5.6.1/bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0
-I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/xsubpp -typemap
/opt/perl5.6.1/lib/5.6.1/ExtUtils/typemap SPI.xs > SPI.c
cc -c -I. -I../../../src/include -D_HPUX_SOURCE -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae -O -DVERSION=\"0.10\"
-DXS_VERSION=\"0.10\" +z -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE SPI.c
cpp: "perl.h", line 2155: warning 2001: Redefinition of macro DEBUG.
Running Mkbootstrap for plperl ()
chmod 644 plperl.bs
rm -f blib/arch/auto/plperl/plperl.sl
LD_RUN_PATH="" ld -b +vnocompatwarnings -L/usr/local/lib plperl.o eloglvl.o SPI.o
-L/usr/local/lib /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/auto/DynaLoader/DynaLoader.a
-L/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE -lperl -lnsl_s -ldld -lm -lc -lndir -lcrypt
-lsec -o blib/arch/auto/plperl/plperl.sl
chmod 755 blib/arch/auto/plperl/plperl.sl
cp plperl.bs blib/arch/auto/plperl/plperl.bs
chmod 644 blib/arch/auto/plperl/plperl.bs
make[4]: Leaving directory `/home/postgres/REL7_2/pgsql/src/pl/plperl'
make[3]: Leaving directory `/home/postgres/REL7_2/pgsql/src/pl/plperl'
REL7_2 generated Makefile:
# This Makefile is for the plperl extension to perl.
#
# It was generated automatically by MakeMaker version
# 5.45 (Revision: 1.222) from the contents of
# Makefile.PL. Don't edit this file, edit Makefile.PL instead.
#
# ANY CHANGES MADE HERE WILL BE LOST!
#
# MakeMaker ARGV: (q[INC=-I. -I../../../src/include])
#
# MakeMaker Parameters:
# NAME => q[plperl]
# OBJECT => q[plperl.o eloglvl.o SPI.o]
# XS => { SPI.xs=>q[SPI.c] }
# dynamic_lib => { OTHERLDFL
Re: [HACKERS] Perl build fix attempted
Further digging: the backtrace from the SIGSEGV looks like #0 0xc00a02fc in ?? () from /usr/lib/libc.1 malloc + 1132 #1 0xc267cbb4 in ?? () Perl_sv_grow + 244 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #2 0xc26815b0 in ?? () Perl_sv_setpv + 312 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #3 0xc26152c0 in ?? () S_incpush + 288 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #4 0xc2615110 in ?? () S_init_perllib + 136 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #5 0xc261092c in ?? () S_parse_body + 2396 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #6 0xc260fc88 in ?? () perl_parse + 272 from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #7 0xc09ec5d0 in plperl_init_interp () at plperl.c:207 #8 0xc09ec4a4 in plperl_init_all () at plperl.c:175 #9 0xc09ec684 in plperl_call_handler (fcinfo=0x7b011418) at plperl.c:240 #10 0x132808 in ExecMakeFunctionResult (fcache=0x402cf108, arguments=0xf000, econtext=0x1, isNull=0x3a , isDone=0x7b03ba30) at execQual.c:825 Since gdb doesn't really know anything about code generated by HP's cc, it's difficult to get any more info than this. However, the fact that the crash is inside malloc() suggests a memory clobber very strongly. My best theory at this point is that there's some conflict of ideas about the size of data structures, perhaps triggered by those missing -D symbols ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] revised sample SRF C function; proposed SRF API
> Tom Lane wrote: > > Well, we're not doing that; and I see no good reason to make the thing > > be a builtin function at all. Since it's just an example, it can very > > well be a contrib item with a creation script. Probably *should* be, > > in fact, because dynamically created functions are what other people are > > going to be building; an example of how to do it as a builtin function > > isn't as helpful. > > True enough, although I could always create another example for contrib. > Returning GUC variable "SHOW ALL" results as a query result has been > discussed before, and I thought there was agreement that it was a > desirable backend feature. Sure would be. Means we can show config variables nicely in phpPgAdmin like phpMyAdmin does... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
