Re: [HACKERS] AIX and V8 beta 3
Have you tried using cc_r for that compile line? Does that help? Alas, that is not an option available. cc_r is specific to the AIX xlc compiler; we're using GCC, and xlc is not available to us. What is missing is a -lpthread . Andreas ---(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] shared memory release following failed lock acquirement.
Merlin Moncure The name max_locks_per_transaction indicates a limit of some kind. The documentation doesn't mention anything about whether that limit is enforced or not. I suggest the additional wording: This parameter is not a hard limit: No limit is enforced on the number of locks in each transaction. System-wide, the total number of locks is limited by the size of the lock table. I think it's worse than that. First of all, user locks persist outside of transactions, but they apply to this limit. I was really thinking of the standard locking case. Yes, user locks make it worse. A more appropriate name for the GUC variable would be 'estimated_lock_table_size_per_backend', or something like that. I've been putting some thought into reworking the userlock contrib module into something acceptable into the main project, a substantial part of that being documentation changes. I agree a renamed parameter would be more appropriate, though I suspect a more accurate name will be about 5 yards long. Documentation change would be worthwhile here... but I'll wait for your changes before doing anything there, Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Libpq problem on Windows.
Bruce, while we're pondering on how to solve this, can you put this up on the open items list so we don't miss it? It's a pretty major issue. //Magnus -Original Message- From: Dave Page [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 11:35 PM To: [EMAIL PROTECTED] Subject: [HACKERS] Libpq problem on Windows. I posted a message to pgsql-hackers-win32 regarding a problem with libpq exports on Win32 the other day, but have yet to receive any replies. Magnus I have discussed the problem over IM and we both believe it is important to fix, but neither of us are fluent enough in make-ese to do so. Basically the issue is that the symbols exported by the mingw build of libpq.dll do not match those exported by the VC++/Borland builds. What we seem to get is: - Mingw exports *all* symbols appropiate for the given build. - VC++/Borland builds appear to export only the published API, but not the SSL related symbols (even with SSL enabled in the build). I can probably sort the second problem by adding a second set of .def files for SSL builds, however it seems to me that the mingw build should not export all symbols. Whether or nt that is changed, the 2 build types certainly need to be brought into sync otherwise Windows users may end up seeing unexplained crashes. Any comments on what should be done (and whether I should hack the BCC/VC++ stuff)? Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian schrieb: Fabien COELHO wrote: Dear hackers, I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted out. ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is still an open issue in current CVS head... waiting for a proper implementation after the brain-storming on what seemed to be the consensus, that is to output a separate SET DEFAULT TABLESPACE somewhere; before object creations in the dump/restore command flow. I've noticed that the item does not seem to appear in Bruce's list, thus I'm afraid it might be lost for 8.0 where I think it belongs... hence this little reminder. It isn't on the open items list because it isn't a _must_ fix for 8.0, though it is still in my mailbox. As I remember it is to allow objects to be created when the schema doesn't exist, and for creating more portable pg_dump CREATE statements. If someone wants to fix that, they have to get it working and get agreement to put it in during beta. It is on the TODO list (the missing schemas part). But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist == -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
On Mon, 4 Oct 2004, Reini Urban wrote: But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist I cannot recreate on Linux. What platform, etc, are you on? Gavin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Gavin Sherry schrieb: On Mon, 4 Oct 2004, Reini Urban wrote: But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
On Mon, 4 Oct 2004, Reini Urban wrote: Gavin Sherry schrieb: On Mon, 4 Oct 2004, Reini Urban wrote: But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 Hmm.. sounds like we're trying to support tablespaces on a system which doesn't actually support symlinks (in the way we need them). Can any of the windows guys help? Gavin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 Hmm.. sounds like we're trying to support tablespaces on a system which doesn't actually support symlinks (in the way we need them). Can any of the windows guys help? There was special code added to handle symlinks on windows using NTFS junction points to pgport. Not sure if it's a) enabled, or b) working, under cygwin. Dunno if anyone has even tried it. I'd go looking around that area :-) //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Libpq problem on Windows.
OK, added: o fix MinGW libpq to export only required symbols o fix MSVC build to export SSL symbols --- Magnus Hagander wrote: Bruce, while we're pondering on how to solve this, can you put this up on the open items list so we don't miss it? It's a pretty major issue. //Magnus -Original Message- From: Dave Page [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 11:35 PM To: [EMAIL PROTECTED] Subject: [HACKERS] Libpq problem on Windows. I posted a message to pgsql-hackers-win32 regarding a problem with libpq exports on Win32 the other day, but have yet to receive any replies. Magnus I have discussed the problem over IM and we both believe it is important to fix, but neither of us are fluent enough in make-ese to do so. Basically the issue is that the symbols exported by the mingw build of libpq.dll do not match those exported by the VC++/Borland builds. What we seem to get is: - Mingw exports *all* symbols appropiate for the given build. - VC++/Borland builds appear to export only the published API, but not the SSL related symbols (even with SSL enabled in the build). I can probably sort the second problem by adding a second set of .def files for SSL builds, however it seems to me that the mingw build should not export all symbols. Whether or nt that is changed, the 2 build types certainly need to be brought into sync otherwise Windows users may end up seeing unexplained crashes. Any comments on what should be done (and whether I should hack the BCC/VC++ stuff)? Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Gavin Sherry schrieb: On Mon, 4 Oct 2004, Reini Urban wrote: I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 Hmm.. sounds like we're trying to support tablespaces on a system which doesn't actually support symlinks (in the way we need them). Can any of the windows guys help? Found the error: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -DBUILDING_DLL -c -o tablespace.o tablespace.c no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK. /usr/src/postgresql/postgresql-8.0.0cvs/src/backend/commands $ gcc -E -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -DBUILDING_DLL -c tablespace.c | grep HAVE_SYMLINK none -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] is it a known issue or just a bug?
Folks,
Last week one of my students confronted me with a nice little SQL
statement which made me call gdb ...
Consider the following scenario:
[EMAIL PROTECTED] bug]$ cat q1.sql
create temporary sequence seq_ab;
select * from (Select nextval('seq_ab') as nv,
* from( select
t_product.id,t_text.value,t_price.price
fromt_product,t_price,t_text
where t_product.id = t_price.product_id
and t_product.name = t_text.id
and t_text.lang='de'
and t_price.typ = 'default'
order by price desc ) as t ) as u
-- WHERE nv = 1
;
[EMAIL PROTECTED] bug]$ psql test q1.sql
CREATE SEQUENCE
nv | id | value | price
++-+---
1 | 3 | Banane |12
2 | 1 | T-Shirt |10
3 | 2 | Apfel | 7
(3 rows)
this query returns the right result.
however, when uncommenting the WHERE clause things look different:
[EMAIL PROTECTED] bug]$ cat q2.sql
create temporary sequence seq_ab;
select * from (Select nextval('seq_ab') as nv,
* from( select
t_product.id,t_text.value,t_price.price
fromt_product,t_price,t_text
where t_product.id = t_price.product_id
and t_product.name = t_text.id
and t_text.lang='de'
and t_price.typ = 'default'
order by price desc ) as t ) as u
WHERE nv = 1
;
[EMAIL PROTECTED] bug]$ psql test q2.sql
CREATE SEQUENCE
nv | id | value | price
++-+---
4 | 1 | T-Shirt |10
(1 row)
Obviously nv = 4 is wrong ...
Looking at the execution plan of the second query the problem seems
quite obvious:
QUERY PLAN
Subquery Scan t (cost=69.24..69.26 rows=1 width=68)
- Sort (cost=69.24..69.25 rows=1 width=68)
Sort Key: t_price.price
- Hash Join (cost=22.51..69.23 rows=1 width=68)
Hash Cond: (outer.name = inner.id)
Join Filter: (nextval('seq_ab'::text) = 1)
- Nested Loop (cost=0.00..46.68 rows=5 width=40)
- Seq Scan on t_price (cost=0.00..22.50 rows=5
width=36)
Filter: (typ = 'default'::text)
- Index Scan using t_product_pkey on t_product
(cost=0.00..4.82 rows=1 width=8)
Index Cond: (t_product.id = outer.product_id)
- Hash (cost=22.50..22.50 rows=5 width=36)
- Seq Scan on t_text (cost=0.00..22.50 rows=5
width=36)
Filter: (lang = 'de'::text)
(14 rows)
nextval() is called again when processing the WHERE clause.
this was fine if nextval() would return the same thing again and again
(which is not the job of nextval).
if the planner materialized the subquery things would materialize the
subquery in case of unstable functions things would work in this case.
I know I temp table would easily fix this query and it is certainly not
the best query I have ever seen but still it seems like a bug and I just
wanted to know whether it is a know issue or not.
Looking at the code I did not quite know whether this is something which
should / can be fixed or not.
here is the data:
--
CREATE TABLE t_text (
id int4,
langtext,
value text
);
CREATE TABLE t_group (
id int4,
nameint4, -- mehrsprachig in t_text
valid boolean
);
INSERT INTO t_group VALUES (1, 1, 't');
INSERT INTO t_text VALUES (1, 'de', 'Obst');
INSERT INTO t_text VALUES (1, 'en', 'Fruits');
INSERT INTO t_group VALUES (2, 2, 't');
INSERT INTO t_text VALUES (2, 'de', 'Kleidung');
INSERT INTO t_text VALUES (2, 'en', 'Clothes');
CREATE UNIQUE INDEX idx_group_id ON t_group (id);
CREATE TABLE t_product (
id int4,
nameint4, -- mehrsprachig in t_text
active boolean,
PRIMARY KEY (id)
);
INSERT INTO t_product VALUES (1, 3, 't');
INSERT INTO t_text VALUES (3, 'de', 'T-Shirt');
INSERT INTO t_text VALUES (3, 'en', 'T-Shirt');
INSERT INTO t_product VALUES (2, 4, 't');
INSERT INTO t_text VALUES (4, 'de', 'Apfel');
INSERT INTO t_text VALUES (4, 'en', 'Apple');
INSERT INTO t_product VALUES (3, 5, 't');
INSERT INTO t_text VALUES (5, 'de', 'Banane');
INSERT INTO t_text VALUES (5, 'en', 'Banana');
CREATE TABLE t_product_group (
product_id int4REFERENCES t_product(id)
ON UPDATE CASCADE
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Gavin Sherry [EMAIL PROTECTED] writes: I though this may have been the problem. configure.in defines HAVE_SYMLINK to 1 if we are win32. It seems that for Reini's case we are setting our template (and PORTNAME) to win32 when I suspect it should be cygwin. Anyone got any ideas? What are the prospects of making the junction code work under cygwin? 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])
[HACKERS] int64 configure test
I have found a problem with int64 detection on MinGW. MinGW defines int64_t but not int64, but configure only looks for int64: AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar], [AC_TRY_RUN( [typedef $1 int64; What is the proper test? int64 or int64_t? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] int64 configure test
Bruce Momjian wrote: I have found a problem with int64 detection on MinGW. MinGW defines int64_t but not int64, but configure only looks for int64: AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar], [AC_TRY_RUN( [typedef $1 int64; What is the proper test? int64 or int64_t? Sorry, wrong analysis. Something is still wrong with MinGW's detection but this is not it. Let me continue testing. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] FunctionCall2 performance
I was comparing the oprofile results of our OLTP workload between 7.5devel and 8.0beta3 test and noticed a new FunctionCall2 in the 8.0beta3 profile that's on the top of the list for PostgreSQL. I see about an 32% decrease in overall performance. Any suggestions for determining if FunctionCall2 is really having that kind of an impact on the test? Links to results are here: 7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/ 8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/ Unfortunitely, I lost the database parameters for 7.5devel. :( -- Mark Wong - - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503) 626-2455 x 32 (office) (503) 626-2436 (fax) http://developer.osdl.org/markw/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] is it a known issue or just a bug?
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Consider the following scenario:
select * from (Select nextval('seq_ab') as nv,
* from( select
t_product.id,t_text.value,t_price.price
fromt_product,t_price,t_text
where t_product.id = t_price.product_id
and t_product.name = t_text.id
and t_text.lang='de'
and t_price.typ = 'default'
order by price desc ) as t ) as u
WHERE nv = 1
;
I don't think there's any very clean way to fix this sort of problem in
general. We could make this particular example work if
(1) we prevented a subquery containing volatile functions in its
targetlist from being flattened into the parent query, and
(2) we prevented outer WHERE clauses from being pushed down into a
subquery when they reference subquery outputs containing volatile
functions.
There has been some recent discussion about doing (1) but I think we
forgot about the necessity to also do (2); otherwise you'd end up with
select * from (Select nextval('seq_ab') as nv,
...
WHERE nextval('seq_ab') = 1
) as u
;
which is hardly any better.
Now those things are both doable but where it really falls down is when
you join the subselect to some other table. Short of materializing the
subselect there'd be no way to guarantee single evaluation of any one
row in the subselect.
I'd be willing to do (1) and (2) but not to force materialization; the
performance hit for that just seems unacceptable.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-www] Contrib/earthdistance missing from cvsweb.
On Mon, 4 Oct 2004, Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 04 October 2004 17:17 To: Marc G. Fournier Cc: Dave Page; PostgreSQL WWW Mailing List Subject: Re: [pgsql-www] Contrib/earthdistance missing from cvsweb. Marc G. Fournier wrote: On Mon, 4 Oct 2004, Dave Page wrote: Hi Marc, I always seem to get problems checking out the earthdistance contrib module from CVS. Tom mentioned in the past that this was because you had experimented with it when trying to split the repository. I can get at it if I checkout pgsql vs. pgsql-server (or vice-versa, I forget which), but as this module is also missing from cvsweb, it would be good if you could fix it. Please :-) Unfortunately, to 'fix it', I'm not sure of the risks, since it causes some major headaches when i pulled it out in the first place :( If nothing else, should probably wait until *after* the release, not middle of beta ... This just a CVS checkout issue. It shouldn't affect the actual CVS files. I think it has been pushed off too long that we should just do it now. How many years must it be broken? Which reminds me of why I reported it in the first place - I already get errors about it being missing. I'm not sure things could get much worse! If I correctly remember the issue, if I merge earthdistance back into the main source tree (which is a simple mv operation and cvs update on the modules file), it will potentially break everyone's currently checked out CVS source, since the 'paths' will change in the CVS/Root file ... I'm willing to do it, since all the work I generally do, I do with a fresh check out ... Am CC'ng in -hackers, as they will potentially be *the most* affected by doing this ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [pgsql-www] Contrib/earthdistance missing from cvsweb.
Marc G. Fournier wrote: If I correctly remember the issue, if I merge earthdistance back into the main source tree (which is a simple mv operation and cvs update on the modules file), it will potentially break everyone's currently checked out CVS source, since the 'paths' will change in the CVS/Root file ... This whole thing has been a mess that has been dragging on for too long. I suggest that after the release we make a clean break and put things back the way they were before (that is, one single pgsql module). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] Contrib/earthdistance missing from cvsweb.
On Mon, 4 Oct 2004, Peter Eisentraut wrote: Marc G. Fournier wrote: If I correctly remember the issue, if I merge earthdistance back into the main source tree (which is a simple mv operation and cvs update on the modules file), it will potentially break everyone's currently checked out CVS source, since the 'paths' will change in the CVS/Root file ... This whole thing has been a mess that has been dragging on for too long. I suggest that after the release we make a clean break and put things back the way they were before (that is, one single pgsql module). Agreed, but Bruce is calling for this *during* beta, which I'm not comfortable with ... if anyone else wants to agree with Bruce, I'll do it, as I know it won't affect me ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] External Tabular Data Via SQL
David, Please find enclosed an example of what I hope to make into a generalized way of accessing external tabular data via SQL. This is very cool, and I look forward to playing with it. However,it seems to me that pgFoundry is the place for it and not /contrib. We're really trying not to add new projects to contrib unless they're likely to get merged with the man code in a couple of versions. Further, it's got a major external dependency. Besides, other perl hackers are more likely to play with it if it's somewhere more accessable. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-www] Contrib/earthdistance missing from cvsweb.
Marc G. Fournier wrote: On Mon, 4 Oct 2004, Peter Eisentraut wrote: Marc G. Fournier wrote: If I correctly remember the issue, if I merge earthdistance back into the main source tree (which is a simple mv operation and cvs update on the modules file), it will potentially break everyone's currently checked out CVS source, since the 'paths' will change in the CVS/Root file ... This whole thing has been a mess that has been dragging on for too long. I suggest that after the release we make a clean break and put things back the way they were before (that is, one single pgsql module). Agreed, but Bruce is calling for this *during* beta, which I'm not comfortable with ... if anyone else wants to agree with Bruce, I'll do it, as I know it won't affect me ... Seems we have 100% agreement so far. Beta is a better time to require a cvs fresh checkout than during development. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] External Tabular Data Via SQL
Josh Berkus wrote: David, Please find enclosed an example of what I hope to make into a generalized way of accessing external tabular data via SQL. This is very cool, and I look forward to playing with it. However,it seems to me that pgFoundry is the place for it and not /contrib. We're really trying not to add new projects to contrib unless they're likely to get merged with the man code in a couple of versions. Further, it's got a major external dependency. Besides, other perl hackers are more likely to play with it if it's somewhere more accessable. Of course, if we had a nice code snippets feature working on pgfoundry that might be an ideal place for it . (That's a *big* *hint* BTW) cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] is it a known issue or just a bug?
Tom, I don't think there's any very clean way to fix this sort of problem in general. We could make this particular example work if Frankly, I don't think there *is* any safe way to use volatile functions in subqueries -- I certainly avoid it, except now() and random() which as discussed are special cases.Perhaps a WARNING is in order? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-www] Contrib/earthdistance missing from cvsweb.
On Mon, 4 Oct 2004, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: as far as I know, the only thing that is 'broken' is cvsweb ... and since it looks directly *at* teh cvs repository, not sure how it breaks that ... The problem is that http://developer.postgresql.org/cvsweb.cgi/pgsql-server/ works, but http://developer.postgresql.org/cvsweb.cgi/pgsql/ pgsql is an 'alias' that merges pgsql-server and contrib modules ... cvsweb doesn't see it, as it only looks as the disk layout :( I'm all for merging earthdistance back in and renaming the module back to just pgsql. If it forces a fresh checkout, that's no big deal from my end, and I think it would get rid of a lot of confusion in the long run. You had better give -hackers some notice, of course. Baring anyone being against this, I'll make the changes tomorrow and post to the list once finished ... shouldn't take more then 5 minutes, but this gives ~24hrs notice for anyone working on something that they'd like to save :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [pgsql-www] Contrib/earthdistance missing from cvsweb.
I trust those of us using CVSup will see the right thing, if we pick up the new CVSROOT/modules file? cheers andrew Marc G. Fournier wrote: On Mon, 4 Oct 2004, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: as far as I know, the only thing that is 'broken' is cvsweb ... and since it looks directly *at* teh cvs repository, not sure how it breaks that ... The problem is that http://developer.postgresql.org/cvsweb.cgi/pgsql-server/ works, but http://developer.postgresql.org/cvsweb.cgi/pgsql/ pgsql is an 'alias' that merges pgsql-server and contrib modules ... cvsweb doesn't see it, as it only looks as the disk layout :( I'm all for merging earthdistance back in and renaming the module back to just pgsql. If it forces a fresh checkout, that's no big deal from my end, and I think it would get rid of a lot of confusion in the long run. You had better give -hackers some notice, of course. Baring anyone being against this, I'll make the changes tomorrow and post to the list once finished ... shouldn't take more then 5 minutes, but this gives ~24hrs notice for anyone working on something that they'd like to save :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(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] FunctionCall2 performance
Mark Wong [EMAIL PROTECTED] writes: Links to results are here: 7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/ 8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/ Are those cyclic spikes an artifact of the load of the tests? Or are they artifacts of the postgres checkpoint process? If they're an artifact of the test is it possible to randomize the number iterations and time each connection does before issuing the slower queries? Or somehow avoid generating these spikes? If they're an artifact of the checkpoint process I wonder if there are parameters that can be tweaked to smooth it out more. Some of those transactions/second drops are quite dramatic. It seems like you're averaging 200 txn/s normally but having it drop down to less than half that periodically. -- greg ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SQL-Invoked Procedures for 8.1
While we're discussing things that will possibly mean a different system than the current function language, I have another request: Can we have a means of defining procedures/functions that doesn't involve using quotes? Having to double-quote everything is extremely annoying and prone to errors. I realize that even if procedures/functions aren't defined using quotes there will still be cases where things need to be multi-quoted, but those cases are much rarer. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
I am confused. CVS has in port.h:
#if defined(WIN32) || defined(__CYGWIN__)
/*
* Win32 doesn't have reliable rename/unlink during concurrent access,
* and we need special code to do symlinks.
*/
extern int pgrename(const char *from, const char *to);
extern int pgunlink(const char *path);
extern int pgsymlink(const char *oldpath, const char *newpath);
...
#define rename(from, to)pgrename(from, to)
#define unlink(path)pgunlink(path)
#define symlink(oldpath, newpath) pgsymlink(oldpath, newpath)
so you should already be calling the junction code on Cygwin.
---
Reini Urban wrote:
Tom Lane schrieb:
Gavin Sherry [EMAIL PROTECTED] writes:
I though this may have been the problem. configure.in defines HAVE_SYMLINK
to 1 if we are win32. It seems that for Reini's case we are setting our
template (and PORTNAME) to win32 when I suspect it should be cygwin.
Anyone got any ideas?
What are the prospects of making the junction code work under cygwin?
Somethink like the attached patch is easier.
Just replace symlink() for dirs with link() #ifdef __CYGWIN__
just wait a sec until the tests run through...
(completely fresh build)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Index: tablespace.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/tablespace.c,v
retrieving revision 1.11
diff -u -b -r1.11 tablespace.c
--- tablespace.c 30 Aug 2004 02:54:38 - 1.11
+++ tablespace.c 4 Oct 2004 18:37:13 -
@@ -349,7 +349,11 @@
linkloc = (char *) palloc(strlen(DataDir) + 11 + 10 + 1);
sprintf(linkloc, %s/pg_tblspc/%u, DataDir, tablespaceoid);
+#ifdef __CYGWIN__
+ if (link(location, linkloc) 0)
+#else
if (symlink(location, linkloc) 0)
+#endif
ereport(ERROR,
(errcode_for_file_access(),
errmsg(could not create symbolic link \%s\: %m,
@@ -976,7 +980,11 @@
linkloc = (char *) palloc(strlen(DataDir) + 11 + 10 + 1);
sprintf(linkloc, %s/pg_tblspc/%u, DataDir, xlrec-ts_id);
+#ifdef __CYGWIN__
+ if (link(location, linkloc) 0)
+#else
if (symlink(location, linkloc) 0)
+#endif
{
if (errno != EEXIST)
ereport(ERROR,
---(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
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] SQL-Invoked Procedures for 8.1
Jim C. Nasby wrote: While we're discussing things that will possibly mean a different system than the current function language, I have another request: Can we have a means of defining procedures/functions that doesn't involve using quotes? Having to double-quote everything is extremely annoying and prone to errors. I realize that even if procedures/functions aren't defined using quotes there will still be cases where things need to be multi-quoted, but those cases are much rarer. Have you played with dollar quoting yet? That's in 8.0 for precisely this reason ... The problem with moving entirely from strings would be that we support many languages. If all we had was plpgsql it would be a no-brainer, ISTM. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Reini Urban schrieb: Tom Lane schrieb: Gavin Sherry [EMAIL PROTECTED] writes: I though this may have been the problem. configure.in defines HAVE_SYMLINK to 1 if we are win32. It seems that for Reini's case we are setting our template (and PORTNAME) to win32 when I suspect it should be cygwin. Anyone got any ideas? What are the prospects of making the junction code work under cygwin? Somethink like the attached patch is easier. Just replace symlink() for dirs with link() #ifdef __CYGWIN__ just wait a sec until the tests run through... (completely fresh build) Needed some time because contrib/earthdistance was missing, so I removed it from the Makefile. sorry, bad: test tablespace ... FAILED 1 of 96 tests failed. ---(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] is it a known issue or just a bug?
=?UTF-8?B?SGFucy1Kw7xyZ2VuIFNjaMO2bmln?= [EMAIL PROTECTED] writes: Josh Berkus wrote: Frankly, I don't think there *is* any safe way to use volatile functions in subqueries -- I certainly avoid it, except now() and random() which as discussed are special cases.Perhaps a WARNING is in order? Personally I like Josh's idea. A warning would be a nice thing. From the planner's perspective, it would have to warn about any volatile function, which would probably be overly chatty --- remember that the default marking for user-defined functions is volatile. This default may also be a good reason not to put in the anti-flattening defenses I suggested before, because it would mean that even slight sloppiness in the definition of a user function could cripple subquery optimization. I'm not sure that that's a strong argument, but it's something to think about. It'd be easy enough to put in the anti-flattening defenses (checks (1) and (2) in my prior message) but I've got mixed emotions about whether this is really a good thing to do. Any opinions out there? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian [EMAIL PROTECTED] writes: I am confused. CVS has in port.h: so you should already be calling the junction code on Cygwin. Yeah, I'm sure he is, but it looks from the regression results like it doesn't quite work on Cygwin. Is that fixable? If so, we'd have a choice of whether to rely on junctions or on Cygwin's own emulation of symlinks. I'd be inclined to think the former is a better idea, if only because it'd give you some chance of migrating a data directory between Cygwin and native ports. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] is it a known issue or just a bug?
Tom, It'd be easy enough to put in the anti-flattening defenses (checks (1) and (2) in my prior message) but I've got mixed emotions about whether this is really a good thing to do. Any opinions out there? If my opinion wasn't clear, I was suggesting adding a WARNING and not doing anything about flattening. I can't say that, in 5 years of developing applications in Postgres, that this has ever been a problem for me personally -- from my perspective the persons reporting the issue needs to re-code their query, it's not what sequences were meant for. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Idea about fixing the lockfile issues in postgresql.init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This seems very complicated. Why not simply delete the lock files as an earlier part of the boot process? Also, I've done a bunch of work on the init script we use here in production to run multiple backends. It supports the concept of having multiple versions of postgres installed as well as slony, and pg_autovacuum. I've found them helpful. Tf there's any interest, I could post them to the lists. Drew Tom Lane wrote: | I've been getting some more flak lately about fixing the RPM-supplied | init scripts to avoid the problem where the postmaster fails to start | because there's a stale lockfile in the data directory. See for | instance https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134090 | but it's hardly the first time the question has been brought up. | | I've always resisted the standard solution of having the init script | itself remove the lock file, because I think that is a great way to | shoot yourself in the foot. But I finally had an idea that would make | things better with no increased risk. | | The postmaster does not abort simply because the lockfile is there. | It checks whether the PID mentioned in the lockfile exists, and belongs | to a postgres-owned process (the latter by seeing if kill(pid, 0) | succeeds), and is not the postmaster itself. If any of these tests fail | then it knows the lockfile is stale. So the scenario in which | it gets fooled is where the reboot has used just one or two more | processes than were used in the last boot cycle, so that the PID that | belonged to the postmaster in the last cycle now belongs to either | pg_ctl or the postgres-owned shell launched by su. | | So what occurred to me is that we could eliminate this scenario if we | could get rid of those two processes. The init script is running as | root, and so if its PID is the one mentioned in the old lockfile, | the kill() test will fail and the postmaster will go on its merry way. | It's only the other processes launched by su that could fool the | kill() test. | | After some experimentation, I have found that what will actually work | requires two changes: | | 1. In the init script, do not use pg_ctl to launch the postmaster, but | instead invoke it directly, ie something like | su - postgres -c /usr/bin/postmaster ...args... | pg_ctl is not really buying us any functionality or notational advantage | here, so this seems like no loss. This brings us down to one extra | postgres-owned process, namely the shell that su launches which in | turn launches the postmaster. (Depending on timing, the shell might or | might not still be around when the postmaster probes.) | | 2. In the postmaster, reject as bogus matches not only our own PID, | but our parent's PID from getppid(). This is perfectly safe since | whatever launched the postmaster is certainly not a competing | postmaster. Now we cannot be fooled by the parent shell either. | | AFAICS this is a bulletproof solution for typical users who only launch | one postmaster during system boot. If you launch two or more postmasters | then it's still possible for the first-launched one to have the same PID | that belonged to the second one during the previous boot cycle. But the | odds of this seem pretty low, since it would imply a much greater change | in the usage of PIDs during the boot cycle. The known failure cases | involve a change of just one or two PIDs, whereas postmasters launched | by different init scripts will surely be separated by dozens if not | hundreds of PIDs. (Besides, if you are truly paranoid you'd be running | separate postmasters under separate user IDs, which'd eliminate the | problem again.) | | I'd also want to remove the existing code in the init scripts that zaps | the socket lockfile, since it would be unnecessary. I've forebore to | remove it so far because it doesn't introduce a serious risk of data | corruption the way zapping the datadir lockfile would, but it is | definitely risky especially in multi-postmaster scenarios. | | Anyone see any downsides to these changes? | | regards, tom lane | | ---(end of broadcast)--- | TIP 5: Have you checked our extensive FAQ? | |http://www.postgresql.org/docs/faqs/FAQ.html - -- Andrew Hammond416-673-4138[EMAIL PROTECTED] Database Administrator, Afilias Canada Corp. CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYbGhgfzn5SevSpoRArnhAJ95jRZrSHcp/HJM2f39akDgpOu1VwCbBPWQ IkvGJ6L0QdyAQbK0yTnOVzA= =tJQE -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Idea about fixing the lockfile issues in postgresql.init
Andrew Hammond [EMAIL PROTECTED] writes: This seems very complicated. Why not simply delete the lock files as an earlier part of the boot process? Primarily because it's not very reasonable to expect rc.sysinit to know all the places where Postgres data directories might be hiding. I'd push for that solution myself if we only intended to support one postmaster per machine, but in a multi-postmaster situation things get complicated. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] cygwin test package available
FYI: Soon an experimantal cygwin package will be available via the cywin setup.exe installer, based on a post-beta3 cvs snapshot from today. i.e. * tablespace issues - junctions - not yet solved. * without the missing earthdistance Just to gather more feedback from the cygwin folks. This time contrib is added to the cygwin package. It was not in 7.4.x. Name: postgresql-8.0.0cvs-1 (experimental) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] -HEAD build failure on OpenBSD 3.6-current/Sparc64 +patch
this one got caught by the testfarm as well - it looks like the openbsd-specific makefile is missing a -fPIC for the Sparc platform(I would assume that at least NetBSD/sparc is affected too but I don't have access to such a system to test on). And I also think that -shared is now prefered/recommended on OpenBSD/elf too - a small patch implementing those chances is attached and passes regress on my box. The actual compile failure is in contrib/tsearch2 (because it looks like the postgresql libs itself are small enough to avoid the 8k GOT limit). Stefan gmake[1]: Entering directory `/home/pgbuild/pgbuildfarm/HEAD/pgsql.8969/contrib/tsearch2' sed -e 's,MODULE_PATHNAME,$libdir/tsearch2,g' \ -e 's,DATA_PATH,/home/pgbuild/pgbuildfarm/HEAD/inst/share/postgresql/contrib,g' tsearch.sql.in tsearch2.sql cp untsearch.sql.in untsearch2.sql gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o dict_ex.o dict_ex.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o dict.o dict.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o snmap.o snmap.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o stopword.o stopword.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o common.o common.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o prs_dcfg.o prs_dcfg.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o dict_snowball.o dict_snowball.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o dict_ispell.o dict_ispell.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o dict_syn.o dict_syn.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o wparser.o wparser.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o wparser_def.o wparser_def.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o ts_cfg.o ts_cfg.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o tsvector.o tsvector.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o rewrite.o rewrite.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o crc32.o crc32.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o query.o query.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o gistidx.o gistidx.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o tsvector_op.o tsvector_op.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o rank.o rank.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./snowball -I./ispell -I./wordparser -I. -I../../src/include -c -o ts_stat.o ts_stat.c gmake -C snowball SUBSYS.o gmake[2]: Entering directory `/home/pgbuild/pgbuildfarm/HEAD/pgsql.8969/contrib/tsearch2/snowball' gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I./.. -I. -I../../../src/include -c -o english_stem.o english_stem.c gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Tom Lane schrieb: Bruce Momjian [EMAIL PROTECTED] writes: I am confused. CVS has in port.h: so you should already be calling the junction code on Cygwin. true. didn't thought of that. very strange. Yeah, I'm sure he is, but it looks from the regression results like it doesn't quite work on Cygwin. Is that fixable? I'll step that in the debugger. If so, we'd have a choice of whether to rely on junctions or on Cygwin's own emulation of symlinks. I'd be inclined to think the former is a better idea, if only because it'd give you some chance of migrating a data directory between Cygwin and native ports. Cygwin can do symlinks for directories via the magic .lnk file. But Cygwin can also do junctions via hardlinks in ln.exe. I thought link() calls the junction code. I'll investigate why the libc link() failed, and if ln.exe does some sifferent magic, similar to pgsymlink. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] cygwin test package available
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban Sent: 04 October 2004 22:17 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] cygwin test package available FYI: Soon an experimantal cygwin package will be available via the cywin setup.exe installer, based on a post-beta3 cvs snapshot from today. i.e. * tablespace issues - junctions - not yet solved. * without the missing earthdistance Earthdistance is there, just umm, hidden. Following a discussion on another list earlier today, it should be fixed sometime tomorrow. Regards, Dave. ---(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] cygwin test package available
Dave Page schrieb: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban Sent: 04 October 2004 22:17 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] cygwin test package available FYI: Soon an experimantal cygwin package will be available via the cywin setup.exe installer, based on a post-beta3 cvs snapshot from today. i.e. * tablespace issues - junctions - not yet solved. * without the missing earthdistance Earthdistance is there, just umm, hidden. Following a discussion on another list earlier today, it should be fixed sometime tomorrow. Yes, I saw it. I was in a hurry because of the tablespace test. And I actually had it in my previous build early this day. But then I accidently deleted my whole 8.x archive when I reproduced my package building step, so it got deleted. Anyway, it will be in the next update of course. As soon as the tablespace symlinks are fixed and possible other reports lead to more fixes. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ERROR: left link changed unexpectedly
Anyone interested ? Regards Gaetano Mendola Gaetano Mendola wrote: Hi all, in my development server running a 7.4.5 I can replicate continuously this error: ERROR: left link changed unexpectedly I obtain this with a vacuum full: test=# vacuum full verbose ua_user_data_exp; INFO: vacuuming public.ua_user_data_exp INFO: ua_user_data_exp: found 361471 removable, 20867 nonremovable row versions in 28373 pages DETAIL: 0 dead row versions cannot be removed yet. Nonremovable row versions range from 432 to 1060 bytes long. There were 0 unused item pointers. Total free space (including removable row versions) is 218782956 bytes. 26761 pages are or will become empty, including 0 at the end of the table. 27543 pages containing 218591140 free bytes are potential move destinations. CPU 1.73s/0.40u sec elapsed 17.66 sec. INFO: index exp_id_provider now contains 20867 row versions in 1077 pages DETAIL: 0 index row versions were removed. 1003 index pages have been deleted, 1003 are currently reusable. CPU 0.05s/0.06u sec elapsed 4.87 sec. INFO: index exp_ci_login now contains 20867 row versions in 1832 pages DETAIL: 0 index row versions were removed. 866 index pages have been deleted, 866 are currently reusable. CPU 0.18s/0.02u sec elapsed 12.96 sec. ^[INFO: index exp_country now contains 20867 row versions in 1341 pages DETAIL: 0 index row versions were removed. 1187 index pages have been deleted, 1187 are currently reusable. CPU 0.11s/0.05u sec elapsed 5.89 sec. INFO: index exp_os_type now contains 20867 row versions in 1333 pages DETAIL: 0 index row versions were removed. 1237 index pages have been deleted, 1237 are currently reusable. CPU 0.05s/0.03u sec elapsed 5.84 sec. INFO: index exp_card now contains 20867 row versions in 1417 pages DETAIL: 0 index row versions were removed. 1288 index pages have been deleted, 1288 are currently reusable. CPU 0.09s/0.02u sec elapsed 6.14 sec. ERROR: left link changed unexpectedly last lines in the logs ( with verbose on ): Oct 1 21:35:31 porto postgres[31356]: [1268-5] LOCATION: vacuum_index, vacuum.c:2728 Oct 1 21:35:38 porto postgres[31356]: [1269-1] ERROR: XX000: left link changed unexpectedly Oct 1 21:35:38 porto postgres[31356]: [1269-2] LOCATION: _bt_pagedel, nbtpage.c:888 I don't care to fix the problem immediatelly, so if you want dig on it let me know. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(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] ERROR: left link changed unexpectedly
On Tue, Oct 05, 2004 at 12:08:26AM +0200, Gaetano Mendola wrote: Anyone interested ? I saw the code involved, and I think the only way this can happen is if the index file itself was corrupted by previous operation. How could that happen elludes me; maybe a previous VACUUM changed a sibling's side pointer but not the page itself's. This is hard to believe however. Maybe a partial write of some kind; but WAL should save whole-page snapshots of the four pages involved, so I don't think the corruption would survive WAL replay (that part of the code I didn't read however). Not sure what to do about it. I assume that if you reindex, the problem disappears and you can't reproduce it again? In any case, please save a copy of the corrupted index file(s). Would you send it to me? Gaetano Mendola wrote: Hi all, in my development server running a 7.4.5 I can replicate continuously this error: ERROR: left link changed unexpectedly I obtain this with a vacuum full: test=# vacuum full verbose ua_user_data_exp; INFO: vacuuming public.ua_user_data_exp INFO: ua_user_data_exp: found 361471 removable, 20867 nonremovable row versions in 28373 pages DETAIL: 0 dead row versions cannot be removed yet. Nonremovable row versions range from 432 to 1060 bytes long. There were 0 unused item pointers. Total free space (including removable row versions) is 218782956 bytes. 26761 pages are or will become empty, including 0 at the end of the table. 27543 pages containing 218591140 free bytes are potential move destinations. CPU 1.73s/0.40u sec elapsed 17.66 sec. INFO: index exp_id_provider now contains 20867 row versions in 1077 pages DETAIL: 0 index row versions were removed. 1003 index pages have been deleted, 1003 are currently reusable. CPU 0.05s/0.06u sec elapsed 4.87 sec. INFO: index exp_ci_login now contains 20867 row versions in 1832 pages DETAIL: 0 index row versions were removed. 866 index pages have been deleted, 866 are currently reusable. CPU 0.18s/0.02u sec elapsed 12.96 sec. ^[INFO: index exp_country now contains 20867 row versions in 1341 pages DETAIL: 0 index row versions were removed. 1187 index pages have been deleted, 1187 are currently reusable. CPU 0.11s/0.05u sec elapsed 5.89 sec. INFO: index exp_os_type now contains 20867 row versions in 1333 pages DETAIL: 0 index row versions were removed. 1237 index pages have been deleted, 1237 are currently reusable. CPU 0.05s/0.03u sec elapsed 5.84 sec. INFO: index exp_card now contains 20867 row versions in 1417 pages DETAIL: 0 index row versions were removed. 1288 index pages have been deleted, 1288 are currently reusable. CPU 0.09s/0.02u sec elapsed 6.14 sec. ERROR: left link changed unexpectedly last lines in the logs ( with verbose on ): Oct 1 21:35:31 porto postgres[31356]: [1268-5] LOCATION: vacuum_index, vacuum.c:2728 Oct 1 21:35:38 porto postgres[31356]: [1269-1] ERROR: XX000: left link changed unexpectedly Oct 1 21:35:38 porto postgres[31356]: [1269-2] LOCATION: _bt_pagedel, nbtpage.c:888 I don't care to fix the problem immediatelly, so if you want dig on it let me know. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Crear es tan difícil como ser libre (Elsa Triolet) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] -HEAD build failure on OpenBSD 3.6-current/Sparc64 +patch
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: this one got caught by the testfarm as well - it looks like the openbsd-specific makefile is missing a -fPIC for the Sparc platform(I would assume that at least NetBSD/sparc is affected too but I don't have access to such a system to test on). Why did you remove -DPIC ? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ERROR: left link changed unexpectedly
Alvaro Herrera wrote: On Tue, Oct 05, 2004 at 12:08:26AM +0200, Gaetano Mendola wrote: Anyone interested ? I saw the code involved, and I think the only way this can happen is if the index file itself was corrupted by previous operation. How could that happen elludes me; maybe a previous VACUUM changed a sibling's side pointer but not the page itself's. This is hard to believe however. Maybe a partial write of some kind; but WAL should save whole-page snapshots of the four pages involved, so I don't think the corruption would survive WAL replay (that part of the code I didn't read however). Not sure what to do about it. I assume that if you reindex, the problem disappears and you can't reproduce it again? In any case, please save a copy of the corrupted index file(s). Would you send it to me? If you need the file for the index exp_card then I'm going to send you the file. Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pg_dump and blobs
Why doesn't pg_dump include blob by default? I understand that older pg_dump didn't deal with blobs, and blobs are now kind of obsolete in favor of BYTEA/TEXT, but blobs are every bit a part of a database. Perhaps only exclude blobs when -t is specified? Then -b is required to include blob. Otherwise, -b is implied. Also, it would be really nice if there were a way that pg_dumpall could include blobs. This is my biggest Postgres annoyance nowadays, as I've recently been bitten by this. I though we are already able to escape all octet range from '\\000' to '\\377'? -- dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
