Re: [HACKERS] FYI: Fujitsu
On Sep 8, 2004, at 2:58 PM, Neil Conway wrote: I've accepted an offer from Fujitsu Australia Software Technologies to work on PostgreSQL full-time for them for the next twelve months in Sydney, Australia. I'll be working with Gavin Sherry and two other full-time developers from FAST. I'm grateful to Fujitsu for giving me the opportunity to do this, and I look forward to doing what I can to improve PostgreSQL over the next year. Congratulations, Neil! Fantastic :) Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Indexed views?
Tom Lane [EMAIL PROTECTED] writes: Doug McNaught [EMAIL PROTECTED] writes: Short answer: MVCC tuple visibility status isn't (and can't be) stored in the index. Well, in principle it *could* be, but there are strong arguments why it shouldn't be: the costs of updating N index entries instead of just one tuple entry, the potential reliability hit (what happens when the index entries disagree with the master?), and the increase in index size (adding an extra dozen bytes to an index entry is a very nontrivial I/O hit). Hm. Just thinking aloud here. But what if there was an option to store the visibility information separately from the heap entirely. There would still only be one copy of the visibility information and it wouldn't increase storage or i/o requirements. I'm assuming this would only make sense if the visibility information could be stored on a separate spindle. Or at least if the application never uses sequential scans, especially if the indexes cover the needed columns. But if the table has particularly wide records, then it might be useful to avoid having to read in the many blocks of records. Even if the index doesn't cover the columns needed if there are many dead tuples (or not-yet-alive tuples) reading the very densely packed visibility information might be faster than reading the wide records. Even for narrow tables, if the index covers the columns it would be faster to read the even narrower visibility information alone. If the user opted to *only ever* access the data via the index he could drop the actual heap information and end up with a 90% solution for index organized tables. The visibility information would still be in a heap but not all the column data. I'm not sure the benefits would really outweigh the costs, but it would probably be simpler than storing duplicate visibility information in an index. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FYI: Fujitsu
Neil Conway wrote: I've accepted an offer from Fujitsu Australia Software Technologies to work on PostgreSQL full-time for them for the next twelve months in Sydney, Australia. I'll be working with Gavin Sherry and two other full-time developers from FAST. I'm grateful to Fujitsu for giving me the opportunity to do this, and I look forward to doing what I can to improve PostgreSQL over the next year. -Neil Congratulation. Regards Gaetano Mendola ---(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] FYI: Fujitsu
I've accepted an offer from Fujitsu Australia Software Technologies to work on PostgreSQL full-time for them for the next twelve months in Sydney, Australia. I'll be working with Gavin Sherry and two other full-time developers from FAST. I'm grateful to Fujitsu for giving me the opportunity to do this, and I look forward to doing what I can to improve PostgreSQL over the next year. Cool! I hope you have fun while you're over here! Out of interest, do you have free reign to code whatever you want, or do you have a specific set of things to do for Fujitsu? Also, will you be working on the open source server, or Fujitsu proprietary extensions? Cheers, Chris ---(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] APR 1.0 released
OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. --- Reini Urban wrote: Bruce Momjian schrieb: I looked at the APR code to get some ideas for the Win32 port. Some of the ideas were good, but in other places like rename they didn't do very well we were better off doing it ourselves and getting it right. I remember looking at their code to fix the rename/unlink while the file is open problem, and they didn't seem to have a fix for that so we developed our own method that works like Unix. sorry, but your rename doesn't work on cygwin. maybe it works with mingw. cygwin has it's own and working way of doing rename's. maybe you should have looked at the cygwin sources instead. (src/winsup/cygwin/syscalls.cc) first doing a WinAPI MoveFileEx and then after a failure trying the cygwin version, which will also try its own MoveFile loop, will not work. they are conflicting. same with unlink, but at least the mingw and cygwin unlink versions don't conflict here. here you don't stack two conflicting loops together. nevertheless cygwin's unlink is much better than pgunlink in case of locking problems. it does its own sort of delayed removal then. IMHO port/dirmod.c is a dirty and half-baked hack, which works for mingw only. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FYI: Fujitsu
Neil Conway wrote: I've accepted an offer from Fujitsu Australia Software Technologies to work on PostgreSQL full-time for them for the next twelve months in Sydney, Australia. I'll be working with Gavin Sherry and two other full-time developers from FAST. I'm grateful to Fujitsu for giving me the opportunity to do this, and I look forward to doing what I can to improve PostgreSQL over the next year. Congratulations. It's nice to hear that Fujitsu keeps supporting Postgres. Hopefully other companies can follow suit :-) It seems commercial companies are more keen to support BSD-ish free software (Apache, Postgres, Perl, Ruby, etc.)? With the exception of Linux of course. -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. Ok, I'll do an analysis and patch which will have a chance to be accepted. Keeping pgrename in CYGWIN is probably a good idea. At least for consistent error reporting (which helped me in finding the problem) Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. --- Reini Urban wrote: Bruce Momjian schrieb: I looked at the APR code to get some ideas for the Win32 port. Some of the ideas were good, but in other places like rename they didn't do very well we were better off doing it ourselves and getting it right. I remember looking at their code to fix the rename/unlink while the file is open problem, and they didn't seem to have a fix for that so we developed our own method that works like Unix. sorry, but your rename doesn't work on cygwin. maybe it works with mingw. cygwin has it's own and working way of doing rename's. maybe you should have looked at the cygwin sources instead. (src/winsup/cygwin/syscalls.cc) first doing a WinAPI MoveFileEx and then after a failure trying the cygwin version, which will also try its own MoveFile loop, will not work. they are conflicting. same with unlink, but at least the mingw and cygwin unlink versions don't conflict here. here you don't stack two conflicting loops together. nevertheless cygwin's unlink is much better than pgunlink in case of locking problems. it does its own sort of delayed removal then. IMHO port/dirmod.c is a dirty and half-baked hack, which works for mingw only. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: Right, but if we search the entire trigger queue from the beginning looking for all triggers now immediate and fire them in the EndQuery of the set constraints statement contained in D, we'd potentially get an ordering like: Trigger A start Trigger D start Trigger B start Trigger B end Trigger C start Trigger C end Trigger D end Trigger A end rather than: Trigger A start Trigger D start Trigger C start Trigger C end Trigger D end Trigger A end Trigger B start Trigger B end where I'd gather the latter is the intended ordering. I think it'd be very debatable which order is intended. I don't feel a strong need to promise one of these orders over the other. It does occur to me though that there's another hazard here: refiring trigger A which is already-in-progress. We'll need to add another flag indicating that to the trigger queue entries ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] FYI: Fujitsu
On Wed, Sep 08, 2004 at 03:58:28PM +1000, Neil Conway wrote: I've accepted an offer from Fujitsu Australia Software Technologies to work on PostgreSQL full-time for them for the next twelve months in Sydney, Australia. I'll be working with Gavin Sherry and two other full-time developers from FAST. I'm grateful to Fujitsu for giving me the opportunity to do this, and I look forward to doing what I can to improve PostgreSQL over the next year. Congratulations! Have fun in Sydney :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Indexed views?
Greg Stark [EMAIL PROTECTED] writes: Hm. Just thinking aloud here. But what if there was an option to store the visibility information separately from the heap entirely. There would still only be one copy of the visibility information and it wouldn't increase storage or i/o requirements. How do you figure that it wouldn't increase I/O? In most scenarios that would be still another block to read in to find out whether a tuple is valid. (And that's assuming that you don't need any fancy indexing scheme to associate tuples with visibility records.) But if the table has particularly wide records, then it might be useful to avoid having to read in the many blocks of records. I think the TOAST scheme already gets much of the low-hanging fruit here. It might be interesting to expose more TOAST control knobs, though --- for instance make the thresholds settable per-table. 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] Making AFTER triggers act properly in PL functions
On Wed, 8 Sep 2004, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: Right, but if we search the entire trigger queue from the beginning looking for all triggers now immediate and fire them in the EndQuery of the set constraints statement contained in D, we'd potentially get an ordering like: Trigger A start Trigger D start Trigger B start Trigger B end Trigger C start Trigger C end Trigger D end Trigger A end rather than: Trigger A start Trigger D start Trigger C start Trigger C end Trigger D end Trigger A end Trigger B start Trigger B end where I'd gather the latter is the intended ordering. I think it'd be very debatable which order is intended. I don't feel a strong need to promise one of these orders over the other. Okay. The former seems odd to me, especially for exception handling since Trigger D is making Trigger C immediate, but it could receive exceptions for Trigger B, so it couldn't assume it knows the source of the exception (C or something done due to C's execution) if it did something like: BEGIN SET CONSTRAINTS C IMMEDIATE; EXCEPTION WHEN ... THEN ... END; But it may not be a big deal. It does occur to me though that there's another hazard here: refiring trigger A which is already-in-progress. We'll need to add another flag indicating that to the trigger queue entries ... Yeah, I thought of that after sending, but figured it was easily dealt with. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: Okay. The former seems odd to me, especially for exception handling since Trigger D is making Trigger C immediate, but it could receive exceptions for Trigger B, so it couldn't assume it knows the source of the exception (C or something done due to C's execution) if it did something like: BEGIN SET CONSTRAINTS C IMMEDIATE; EXCEPTION WHEN ... THEN ... END; But it may not be a big deal. It does occur to me though that there's another hazard here: refiring trigger A which is already-in-progress. We'll need to add another flag indicating that to the trigger queue entries ... Yeah, I thought of that after sending, but figured it was easily dealt with. Hmm. Here's a slightly off the wall idea: following SET CONSTRAINTS, scan the pending-triggers list twice. The first time, you determine which triggers you need to fire, and mark them in progress by your transaction. The second time through, you actually fire the ones you marked, and change their marking to done. The in progress ones wouldn't be touched by the hypothetical inner SET CONSTRAINTS. It wouldn't quite work to use just transaction ID as the marker, since the inner SET CONSTRAINTS is very possibly done without using a subtransaction. But command ID or query nesting level or some such would work. I think the main concern here would be the space cost of adding still another field to the trigger records ... is it worth it? 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] [pgsql-hackers-win32] timezone vs _timezone on Windows
I just applied a patch to use _timezone on Cygwin consistenly. --- Tom Lane wrote: I think I see the real issue behind the recent argument about the datatype of the timezone variable. I don't think the datatype matters, but the name certainly does. In pgtz.c we have #if defined(HAVE_STRUCT_TM_TM_ZONE) return tm-tm_gmtoff; #elif defined(HAVE_INT_TIMEZONE) #ifdef HAVE_UNDERSCORE_TIMEZONE return -_timezone; #else return -timezone; #endif #else #error No way to determine TZ? Can this happen? #endif but the symbol HAVE_UNDERSCORE_TIMEZONE appears nowhere else --- certainly it's not set by configure, and never has been. So the _timezone case is dead code at the moment. In 7.4, pg_config_manual.h contained /* * Define this if your operating system has _timezone rather than timezone */ #if defined(__CYGWIN__) || defined(WIN32) #define HAVE_INT_TIMEZONE /* has int _timezone */ #define HAVE_UNDERSCORE_TIMEZONE 1 #endif but this passage has disappeared from CVS tip. So given a platform that has _timezone but not timezone, CVS tip is broken. I am wondering how changing this would affect the existing, allegedly working Windows port. Should we put back the pg_config_manual.h entry? Should we restrict it to __CYGWIN__ only? regards, tom lane ---(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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
Kind people, Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. Here is regression.diffs. *** ./expected/geometry.out Fri Oct 31 19:07:07 2003 --- ./results/geometry.out Wed Sep 8 12:22:46 2004 *** *** 117,123 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 117,123 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) == Any clues? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
David Fetter wrote: Kind people, Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. We have seen a number of reports recently of things broken some time in the past. As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I started creating a script to do this, but got sidetracked onto more important things (like Windows stuff, CSV, dollar quoting), but I am prepared to restart the effort if enough people are interested. Essentially, this would involve installation of a perl script to be run from cron (or Windows equivalent - automating the build for Windows might be challenging ...), which would check out code from CVS, run configure; make check and then send the results to a central URL. Centrally, we would store the results and have a summary page, with access to full logs if necessary in case of errors. How we classify the results is also an open question. So far my thoughts are to classify by Architecture,OS+Version,Compiler+Version. Thoughts? cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
On Wed, Sep 08, 2004 at 04:20:11PM -0400, Andrew Dunstan wrote: David Fetter wrote: Kind people, Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. We have seen a number of reports recently of things broken some time in the past. Sorry not to have provided better timing info. :/ As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I started creating a script to do this, but got sidetracked onto more important things (like Windows stuff, CSV, dollar quoting), but I am prepared to restart the effort if enough people are interested. Essentially, this would involve installation of a perl script to be run from cron (or Windows equivalent - automating the build for Windows might be challenging ...), which would check out code from CVS, run configure; make check and then send the results to a central URL. Centrally, we would store the results and have a summary page, with access to full logs if necessary in case of errors. How we classify the results is also an open question. So far my thoughts are to classify by Architecture,OS+Version,Compiler+Version. Thoughts? That'd be great! I seem to recall that bison/(f)lex versions can cause issues, too. Could these just be tested for beforehand? reported in any compile report? Should names versions of other tools or libraries come along? If so, how? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Making AFTER triggers act properly in PL functions
On Wed, 8 Sep 2004, Tom Lane wrote: Hmm. Here's a slightly off the wall idea: following SET CONSTRAINTS, scan the pending-triggers list twice. The first time, you determine which triggers you need to fire, and mark them in progress by your transaction. The second time through, you actually fire the ones you marked, and change their marking to done. The in progress ones wouldn't be touched by the hypothetical inner SET CONSTRAINTS. It wouldn't quite work to use just transaction ID as the marker, since the inner SET CONSTRAINTS is very possibly done without using a subtransaction. But command ID or query nesting level or some such would work. I think the main concern here would be the space cost of adding still another field to the trigger records ... is it worth it? Would it be possible to basically alias the space for dte_done_xid to hold either the xid if it's done or the whatever if it's in progress? That's ugly, but it would presumably not increase the size of the record. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
David Fetter wrote: As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I started creating a script to do this, but got sidetracked onto more important things (like Windows stuff, CSV, dollar quoting), but I am prepared to restart the effort if enough people are interested. Essentially, this would involve installation of a perl script to be run from cron (or Windows equivalent - automating the build for Windows might be challenging ...), which would check out code from CVS, run configure; make check and then send the results to a central URL. Centrally, we would store the results and have a summary page, with access to full logs if necessary in case of errors. How we classify the results is also an open question. So far my thoughts are to classify by Architecture,OS+Version,Compiler+Version. Thoughts? That'd be great! I seem to recall that bison/(f)lex versions can cause issues, too. Could these just be tested for beforehand? reported in any compile report? Should names versions of other tools or libraries come along? If so, how? Should not be necessary, at least for bison/flex - configure already checks that you have acceptable versions of these. If there is a failure due to them it should show up clearly in the logs. Perhaps version info for other 3rd party things, like perl, python, tcl, kerberos, openssl would be useful. I'm wary of collecting too much info, though. Most compile failures seem to be traceable to OS/Arch/Compiler issues. cheers andrew ---(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] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 8 Sep 2004, Tom Lane wrote: I think the main concern here would be the space cost of adding still another field to the trigger records ... is it worth it? Would it be possible to basically alias the space for dte_done_xid to hold either the xid if it's done or the whatever if it's in progress? That's ugly, but it would presumably not increase the size of the record. Yeah, I was wondering the same, but hadn't quite worked out the details. The difficulty is that if trigger execution is abandoned due to an error, you'd have to be able to recognize which entries weren't really in progress anymore. If the values aren't XIDs, I'm not sure how to do that. One thing I was looking at was that we aren't using nearly all the bits of dti_state. It'd be possible to narrow that to int16 and then shoehorn a 16-bit query nesting depth counter into the freed space. Not sure if this is enough though. Actually, I'd really like to get it back down to the 7.4 size, which was already too big :-(. That might be a vain hope though. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
David Fetter [EMAIL PROTECTED] writes: Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. Here is regression.diffs. OS X has been doing that since 10.3.something. I've been thinking of installing a variant geometry file but it's a bit annoying to do so for just one platform, especially since I have no idea when Apple might revert back to more standard behavior ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
Andrew Dunstan [EMAIL PROTECTED] writes: We have seen a number of reports recently of things broken some time in the past. As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I think everyone thought that was a fine idea ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: We have seen a number of reports recently of things broken some time in the past. As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I think everyone thought that was a fine idea ... OK, will work on it. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
AFAIR there was a thread about SELECT FOR UPDATE NOWAIT availability in
{7.5,8.0}, 7-8 months ago.
Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
SELECT ... NOWAIT one. Today I got a request for this; and it was
reported that this feature will be used in a huge project.
If there is an unapplied patch that I've missed (even though I didn't see
one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
know it -- taking all the risks, surely.
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.orgdevrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFBP44ttl86P3SPfQ4RAqC2AJoCeQrLeEdD6dE1S4mQO+gGRzsZxQCg2OM4
dAWpHfXywbDS+dADccfGqCY=
=1+Yy
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 8 Sep 2004, Tom Lane wrote: As long as we're talking about hack-slash-and-burn on this data structure ... Where the OtherInformation could be shared within the statement (for identical events)? I think it'd be problematic to try sharing between statements. Yeah, I had come to the same conclusion after more thought. But we could certainly aggregate all the similar events generated by a single query into a common status structure. But, I'm sort of assuming the following are true: Once a group of items is marked to be run, all items will run even if set constraints ... deferred happens while the run occurs. That's a good question. If the first trigger firing tries to set the event deferred, what happens to the remaining triggers? The SQL spec doesn't even touch this question, so I think we are at liberty to do what we like. I don't see that it's unreasonable to continue to fire events that were marked as firable when we reached the end of the current statement. If an error occurs, either the entire set of event objects for the statement are going away because they're new, or if it was something run from set constraints we're going to want to rerun the entire set anyway. Right, that was what I was thinking. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
DB2 8.2 now supports NOWAIT also... Best Regards, Simon Riggs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Devrim GUNDUZ
Sent: 08 September 2004 23:57
To: [EMAIL PROTECTED]
Subject: [HACKERS] SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
AFAIR there was a thread about SELECT FOR UPDATE NOWAIT availability in
{7.5,8.0}, 7-8 months ago.
Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
SELECT ... NOWAIT one. Today I got a request for this; and it was
reported that this feature will be used in a huge project.
If there is an unapplied patch that I've missed (even though I didn't see
one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
know it -- taking all the risks, surely.
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFBP44ttl86P3SPfQ4RAqC2AJoCeQrLeEdD6dE1S4mQO+gGRzsZxQCg2OM4
dAWpHfXywbDS+dADccfGqCY=
=1+Yy
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] FYI: Fujitsu
Christopher Kings-Lynne wrote: Out of interest, do you have free reign to code whatever you want, or do you have a specific set of things to do for Fujitsu? Also, will you be working on the open source server, or Fujitsu proprietary extensions? I'll be working on a bit of everything; my initial focus will be on new feature development for 8.1 -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
Andrew Dunstan wrote: David Fetter wrote: Kind people, Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. We have seen a number of reports recently of things broken some time in the past. As I am currently thinking about what I want to do in the next dev cycle, this might be an opportune time for me to raise again my previous suggestion of a distributed build farm, so we get timely and automated warnings of breakage. I started creating a script to do this, but got sidetracked onto more important things (like Windows stuff, CSV, dollar quoting), but I am prepared to restart the effort if enough people are interested. Essentially, this would involve installation of a perl script to be run from cron (or Windows equivalent - automating the build for Windows might be challenging ...), which would check out code from CVS, run configure; make check and then send the results to a central URL. Centrally, we would store the results and have a summary page, with access to full logs if necessary in case of errors. How we classify the results is also an open question. So far my thoughts are to classify by Architecture,OS+Version,Compiler+Version. Thoughts? This can be a good model to follow: http://boost.sourceforge.net/regression-logs/ Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Geometry regression test failure, CVS HEAD, Mac OS/X
On Sep 9, 2004, at 6:27 AM, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: Lately (past 3 days or so, but I don't know exactly how far back this goes), I've been getting some regression test failures for geometry with CVS HEAD on OS/X. Here is regression.diffs. OS X has been doing that since 10.3.something. I've been thinking of installing a variant geometry file but it's a bit annoying to do so for just one platform, especially since I have no idea when Apple might revert back to more standard behavior ... Is this documented somewhere? If it's not, could it be? I was one of those who reported this same failure a while back (May 30 for 10.3.4, Aug 10 for 10.3.5). I didn't get a response to either post and was wondering if I had screwed up my system somehow :) Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. Done, and patch attached and applied. Hopefully at least Cygwin will compile dirmod.c now. (Most of the patch is consistency reorganization.) We still need a review of that file. -- 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 Index: src/backend/libpq/be-secure.c === RCS file: /cvsroot/pgsql-server/src/backend/libpq/be-secure.c,v retrieving revision 1.48 diff -c -c -r1.48 be-secure.c *** src/backend/libpq/be-secure.c 29 Aug 2004 05:06:43 - 1.48 --- src/backend/libpq/be-secure.c 9 Sep 2004 00:49:26 - *** *** 659,665 * think of a reasonable check to apply on Windows. (See also the * data directory permission check in postmaster.c) */ ! #if !defined(__CYGWIN__) !defined(WIN32) if (!S_ISREG(buf.st_mode) || (buf.st_mode (S_IRWXG | S_IRWXO)) || buf.st_uid != getuid()) ereport(FATAL, --- 659,665 * think of a reasonable check to apply on Windows. (See also the * data directory permission check in postmaster.c) */ ! #if !defined(WIN32) !defined(__CYGWIN__) if (!S_ISREG(buf.st_mode) || (buf.st_mode (S_IRWXG | S_IRWXO)) || buf.st_uid != getuid()) ereport(FATAL, Index: src/backend/postmaster/postmaster.c === RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.424 diff -c -c -r1.424 postmaster.c *** src/backend/postmaster/postmaster.c 29 Aug 2004 05:06:46 - 1.424 --- src/backend/postmaster/postmaster.c 9 Sep 2004 00:49:34 - *** *** 976,982 * be proper support for Unix-y file permissions. Need to think of a * reasonable check to apply on Windows. */ ! #if !defined(__CYGWIN__) !defined(WIN32) if (stat_buf.st_mode (S_IRWXG | S_IRWXO)) ereport(FATAL, (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), --- 976,982 * be proper support for Unix-y file permissions. Need to think of a * reasonable check to apply on Windows. */ ! #if !defined(WIN32) !defined(__CYGWIN__) if (stat_buf.st_mode (S_IRWXG | S_IRWXO)) ereport(FATAL, (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), Index: src/include/c.h === RCS file: /cvsroot/pgsql-server/src/include/c.h,v retrieving revision 1.168 diff -c -c -r1.168 c.h *** src/include/c.h 29 Aug 2004 05:06:55 - 1.168 --- src/include/c.h 9 Sep 2004 00:49:38 - *** *** 68,74 #include sys/types.h #include errno.h ! #if defined(__CYGWIN__) || defined(WIN32) #include fcntl.h/* ensure O_BINARY is available */ #endif #ifdef HAVE_SUPPORTDEFS_H --- 68,74 #include sys/types.h #include errno.h ! #if defined(WIN32) || defined(__CYGWIN__) #include fcntl.h/* ensure O_BINARY is available */ #endif #ifdef HAVE_SUPPORTDEFS_H *** *** 680,686 *literal control-Z. The other affect is that we see CRLF, but *that is OK because we can already handle those cleanly. */ ! #if defined(__CYGWIN__) || defined(WIN32) #define PG_BINARY O_BINARY #define PG_BINARY_R rb #define PG_BINARY_W wb --- 680,686 *literal control-Z. The other affect is that we see CRLF, but *that is OK because we can already handle those cleanly. */ ! #if defined(WIN32) || defined(__CYGWIN__) #define PG_BINARY O_BINARY #define PG_BINARY_R rb #define PG_BINARY_W wb Index: src/include/port.h === RCS file: /cvsroot/pgsql-server/src/include/port.h,v retrieving revision 1.59 diff -c -c -r1.59 port.h *** src/include/port.h 9 Sep 2004 00:24:10 - 1.59 --- src/include/port.h 9 Sep 2004 00:49:38 - *** *** 181,187 #endif /* Global variable holding time zone information. */ ! #if !defined(__CYGWIN__) #define TIMEZONE_GLOBAL
[HACKERS] TRIGGER_DEFERRED_HAS_BEFORE ?
Anyone know why we are maintaining a TRIGGER_DEFERRED_HAS_BEFORE flag bit in the deferred-trigger event list? It's unused and quite pointless AFAICS. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Bruce Momjian said: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. Done, and patch attached and applied. Hopefully at least Cygwin will compile dirmod.c now. (Most of the patch is consistency reorganization.) We still need a review of that file. I don't understand most of this patch. What difference does changing the preprocessor test order make? 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] Making AFTER triggers act properly in PL functions
On Wed, 8 Sep 2004, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 8 Sep 2004, Tom Lane wrote: As long as we're talking about hack-slash-and-burn on this data structure ... Where the OtherInformation could be shared within the statement (for identical events)? I think it'd be problematic to try sharing between statements. Yeah, I had come to the same conclusion after more thought. But we could certainly aggregate all the similar events generated by a single query into a common status structure. Definately. The ~20 byte/row gain for large updates/insert/delete is worth it. I think it'd actually increase the size for the single row case since we'd have the pointer to deal with (we could use a flag that tells us whether this item actually has a pointer to a shared status structure or just contains the status structure but that seems kinda ugly). But, I'm sort of assuming the following are true: Once a group of items is marked to be run, all items will run even if set constraints ... deferred happens while the run occurs. That's a good question. If the first trigger firing tries to set the event deferred, what happens to the remaining triggers? The SQL spec doesn't even touch this question, so I think we are at liberty to do what we like. I don't see that it's unreasonable to continue to fire events that were marked as firable when we reached the end of the current statement. That's what I figured, especially if a function called in an update that does a set constraints doesn't act upon the triggers being queued effectively until the end of statement. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] APR 1.0 released
Andrew Dunstan [EMAIL PROTECTED] writes: I don't understand most of this patch. What difference does changing the preprocessor test order make? I think Bruce was mostly trying to make all the similar tests look alike. Also I agree that if a !b is clearer than if !b a; the latter requires a bit more thought to parse the extent of the ! operator... However, per Michael's report there's some oversight in this patch. I'm not presently ready to update to CVS tip; who can find the problem? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: Definately. The ~20 byte/row gain for large updates/insert/delete is worth it. I think it'd actually increase the size for the single row case since we'd have the pointer to deal with (we could use a flag that tells us whether this item actually has a pointer to a shared status structure or just contains the status structure but that seems kinda ugly). Yeah. I can't see that anyone will care about another few bytes in single-row cases --- the other per-query overheads will swamp this one. The only cases we've ever heard complaints about are this-query-updated- umpteen-zillion rows cases, and they were always umpteen zillion cases of the same trigger. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I don't understand most of this patch. What difference does changing the preprocessor test order make? I think Bruce was mostly trying to make all the similar tests look alike. Also I agree that if a !b is clearer than if !b a; the latter requires a bit more thought to parse the extent of the ! operator... Right, just consistency. However, per Michael's report there's some oversight in this patch. I'm not presently ready to update to CVS tip; who can find the problem? I have not seen the report yet. I had no plan to change the behavior except for Cygwin. -- 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
