Re: [HACKERS] Incorrect behaviour when using a GiST index on points

2012-04-09 Thread Alexander Korotkov
On Mon, Mar 12, 2012 at 3:50 PM, Alexander Korotkov aekorot...@gmail.comwrote: I believe that attached version of patch can be backpatched. It fixes this problem without altering of index building procedure. It just makes checks in internal pages softener enough to compensate effect of

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

2012-04-09 Thread Thom Brown
2012/4/9 Shigeru HANADA shigeru.han...@gmail.com:    1) connect to the server at the beginning of the local query    2) execute EXPLAIN for foreign table foo    3) execute EXPLAIN for foreign table bar    4) execute actual query for foreign table foo    5) execute actual query for foreign

[HACKERS] Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer

2012-04-09 Thread Ashutosh Bapat
Hi, COPY_POINTER_FIELD is defined as - 61 #define COPY_POINTER_FIELD(fldname, sz) \ 62 do { \ 63 Size_size = (sz); \ 64 newnode-fldname = palloc(_size); \ 65 memcpy(newnode-fldname, from-fldname, _size); \ 66 } while (0) Since we allocate _size

[HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Clover White
Hi, I'm debugging initdb using gdb. I found that I could not step in the function getopt_long in line 2572 in initdb.c. I also found that the value of VAR optind never be changed. VAR optind is always equal to 1 but how could optind be larger than the value of argc(the value of argc is 6) in

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Andrew Dunstan
On 04/09/2012 07:38 AM, Clover White wrote: Hi, I'm debugging initdb using gdb. I found that I could not step in the function getopt_long in line 2572 in initdb.c. I also found that the value of VAR optind never be changed. VAR optind is always equal to 1 but how could optind be larger

Re: [HACKERS] [patch] for psql : Allow processing of multiple -f (file) options

2012-04-09 Thread Euler Taveira
On 09-04-2012 02:43, Vikash3 S wrote: Please find the patch regarding trivial changes against To Do item list for psql : Allow processing of multiple -f (file) options . Looking for valuable feedback. Aren't you forget to cover the single transaction (-1) mode? How would you handle ON_ERROR_*

Re: [HACKERS] Last gasp

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch n...@leadboat.com wrote: http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch Returned with Feedback after five consecutive days of Waiting on Author.  That was a great tool for keeping things moving, and I think we should

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 7:38 AM, Clover White mywhiteclo...@gmail.com wrote: Hi,   I'm debugging initdb using gdb.   I found that I could not step in the function getopt_long in line 2572 in initdb.c.   I also found that the value of VAR optind never be changed. VAR optind is always equal to

[HACKERS] Deprecating non-select rules (was Re: Last gasp)

2012-04-09 Thread Andres Freund
On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- SELECT rules are a land mine for the unwary at best. Which we could start deprecating now btw. since INSTEAD triggers landed in 9.1. There were quite some use-cases

Re: [HACKERS] About the behavior of array_length() for empty array

2012-04-09 Thread Robert Haas
On Thu, Apr 5, 2012 at 8:35 PM, iihero iih...@qq.com wrote: From this point of view, seems N dimensions of empty array all are equivalent. Yes. It's effectively viewed as a 0-dimensional array. Is there standard definition of this behavior? No. Multi-dimensional arrays are a PostgreSQL

Re: [HACKERS] Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer

2012-04-09 Thread Tom Lane
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes: After such a copy tests like if (pointer) will start failing. There are few callers of COPY_POINTER_FIELD which do not call the macro if the size can be 0. But there are some who do not do so. This looks fishy, in case we have if (pointer)

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

2012-04-09 Thread Tom Lane
Peter Geoghegan pe...@2ndquadrant.com writes: Having taken another look at the code, I wonder if we wouldn't have been better off just fastpathing out of pgss_store in the first call (in a pair of calls made by a backend as part an execution of some non-prepared query) iff there is already an

Re: [HACKERS] pg_prewarm

2012-04-09 Thread Robert Haas
On Sun, Mar 18, 2012 at 7:25 AM, Cédric Villemain ced...@2ndquadrant.com wrote: Would be nice to sort out the features of the two Postgres extentions pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what do they have in common, what is complementary? pg_prewarm use postgresql

Re: [HACKERS] Deprecating non-select rules (was Re: Last gasp)

2012-04-09 Thread Noah Misch
On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote: On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- SELECT rules are a land mine for the unwary at best. Which we could start deprecating now btw.

[HACKERS] Regarding GSoc proposal

2012-04-09 Thread Atri Sharma
Hi all, I submitted a proposal for GSoc 2012.Please review it and let me know your comments. The link is: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/atrisharma/1001 Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Merlin Moncure
On Sun, Apr 8, 2012 at 8:56 AM, Dave Cramer p...@fastcrypt.com wrote: Hi Atri, Is there some JDBC API that supports this in newer versions of the API ? Didn't parse that question. My understanding is that the only JDBC features needed are what's already there, to make connections to databases

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Dave Cramer
How will the user access this? Will it be a normal query through the existing API ? Will it be a private postgresql API ? How will they set it up ? It appears complicated as you have to setup PL/Java as well Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Mon, Apr 9,

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Merlin Moncure
On Mon, Apr 9, 2012 at 10:47 AM, Dave Cramer p...@fastcrypt.com wrote: How will the user access this? Will it be a normal query through the existing API ? Will it be a private postgresql API ? How will they set it up ? It appears complicated as you have to setup PL/Java as well Yeah -- it

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Dave Cramer
On Mon, Apr 9, 2012 at 11:55 AM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Apr 9, 2012 at 10:47 AM, Dave Cramer p...@fastcrypt.com wrote: How will the user access this? Will it be a normal query through the existing API ? Will it be a private postgresql API ? How will they set it up ?

Re: [HACKERS] Deprecating non-select rules (was Re: Last gasp)

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 11:32 AM, Noah Misch n...@leadboat.com wrote: On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote: On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- SELECT rules are a land mine

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Clover White
2012/4/9 Andrew Dunstan and...@dunslane.net On 04/09/2012 07:38 AM, Clover White wrote: Hi, I'm debugging initdb using gdb. I found that I could not step in the function getopt_long in line 2572 in initdb.c. I also found that the value of VAR optind never be changed. VAR optind is

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Merlin Moncure
On Mon, Apr 9, 2012 at 11:14 AM, Dave Cramer p...@fastcrypt.com wrote: So I'm confused, once they link a file to an FDW can't you just read it with an normal select ? What additional functionality will this provide ? Dave The basic objective is to expose the JDBC to postgres for grabbing

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Clover White
2012/4/9 Robert Haas robertmh...@gmail.com On Mon, Apr 9, 2012 at 7:38 AM, Clover White mywhiteclo...@gmail.com wrote: Hi, I'm debugging initdb using gdb. I found that I could not step in the function getopt_long in line 2572 in initdb.c. I also found that the value of VAR

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Andrew Dunstan
On 04/09/2012 12:14 PM, Dave Cramer wrote: So I'm confused, once they link a file to an FDW can't you just read it with an normal select ? What additional functionality will this provide ? I'm confused about what you're confused about. Surely this won't be linking files to an FDW, but

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Dave Cramer
On Mon, Apr 9, 2012 at 12:45 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/09/2012 12:14 PM, Dave Cramer wrote: So I'm confused, once they link a file to an FDW can't you just read it with an normal select ? What additional functionality will this provide ? I'm confused about

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Kevin Grittner
Dave Cramer p...@fastcrypt.com wrote: Andrew Dunstan and...@dunslane.net wrote: All you'll need on the postgres side is the relevant JDBC driver, so you'd have instant access via standard select queries to anything you can get a JDBC driver to talk to. That seems to me something worth

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Andrew Dunstan
On 04/09/2012 12:36 PM, Clover White wrote: 2012/4/9 Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net On 04/09/2012 07:38 AM, Clover White wrote: Hi, I'm debugging initdb using gdb. I found that I could not step in the function getopt_long in

[HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Tom Lane
A long time ago, we had this bug report: http://archives.postgresql.org/pgsql-bugs/2003-02/msg00069.php in consequence of which, I changed timestamp_part() so that it would rotate a timestamp-without-timezone from the local timezone to GMT before extracting the epoch offset (commit

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Robert Haas
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haas robertmh...@gmail.com wrote: Robert, the Assert triggering with the above procedure is in your fast path locking code with current GIT. Yes, that sure looks like a bug.  It seems that if the top-level transaction is aborting, then LockReleaseAll()

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Atri Sharma
On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/09/2012 12:14 PM, Dave Cramer wrote: So I'm confused, once they link a file to an FDW can't you just read it with an normal select ? What additional functionality will this provide ? I'm confused about

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: i.e. we'd forbid: initdb -D foo bar which the OP's error more or less devolves to. Makes sense. Don't we have a similar issue with psql, pg_dump, etc? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: A long time ago, we had this bug report: http://archives.postgresql.org/pgsql-bugs/2003-02/msg00069.php in consequence of which, I changed timestamp_part() so that it would rotate a timestamp-without-timezone from the local

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 so that we could mark it immutable. On the other hand, it's not entirely apparent why people would need to create indexes on the epoch value rather than just indexing the timestamp itself Well, it makes for smaller indexes if you don't

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: I looked at this more. The above analysis is basically correct, but the problem goes a bit beyond an error in LockWaitCancel(). We could also crap out with an error before getting as far as LockWaitCancel() and have the same problem. I think that a

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php The above-linked discussion also brings up a different point, which is that extracting the epoch from a timestamptz is

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Merlin Moncure
On Mon, Apr 9, 2012 at 12:25 PM, Atri Sharma atri.j...@gmail.com wrote: On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/09/2012 12:14 PM, Dave Cramer wrote: So I'm confused, once they link a file to an FDW can't you just read it with an normal select ? What

Re: [HACKERS] [JDBC] Regarding GSoc Application

2012-04-09 Thread Atri Sharma
On Mon, Apr 9, 2012 at 11:40 PM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Apr 9, 2012 at 12:25 PM, Atri Sharma atri.j...@gmail.com wrote: On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/09/2012 12:14 PM, Dave Cramer wrote: So I'm confused, once they

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Tom Lane
Greg Sabino Mullane g...@turnstep.com writes: so that we could mark it immutable. On the other hand, it's not entirely apparent why people would need to create indexes on the epoch value rather than just indexing the timestamp itself Well, it makes for smaller indexes if you don't really

Re: [HACKERS] Regarding column reordering project for GSoc 2012

2012-04-09 Thread Bruce Momjian
On Tue, Mar 20, 2012 at 01:25:15PM +0100, Claes Jakobsson wrote: On 20 mar 2012, at 13.08, Heikki Linnakangas wrote: On 20.03.2012 11:10, Claes Jakobsson wrote: Personally I'd love a type 2 JDBC driver for PostgreSQL. Why? listen/notify over SSL for example unless that's been

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Alvaro Herrera
Excerpts from Tom Lane's message of lun abr 09 15:04:10 -0300 2012: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php The above-linked discussion also brings up a

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I looked at this more.  The above analysis is basically correct, but the problem goes a bit beyond an error in LockWaitCancel().  We could also crap out with an error before getting as

Re: [HACKERS] why was the VAR 'optind' never changed in initdb?

2012-04-09 Thread Andrew Dunstan
On 04/09/2012 01:38 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: i.e. we'd forbid: initdb -D foo bar which the OP's error more or less devolves to. Makes sense. Don't we have a similar issue with psql, pg_dump, etc? From a quick survey: psql won't override a

Re: [HACKERS] Regarding column reordering project for GSoc 2012

2012-04-09 Thread Merlin Moncure
On Mon, Apr 9, 2012 at 1:14 PM, Bruce Momjian br...@momjian.us wrote: Well, I assume they reimplemented libpq so that java would not rely on a platform-specific library like libpq. yes, that is correct. jdbc for postgres is a complete implementation of the client side protocol. this has some

Re: [HACKERS] Regarding column reordering project for GSoc 2012

2012-04-09 Thread Andrew Dunstan
On 04/09/2012 02:14 PM, Bruce Momjian wrote: On Tue, Mar 20, 2012 at 01:25:15PM +0100, Claes Jakobsson wrote: On 20 mar 2012, at 13.08, Heikki Linnakangas wrote: On 20.03.2012 11:10, Claes Jakobsson wrote: Personally I'd love a type 2 JDBC driver for PostgreSQL. Why? listen/notify over

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Robert Haas robertmh...@gmail.com writes: If somebody needs it I'd probably be in favor of doing it. I'm not sure I'd do it on spec. It would be useful to have a simple function to use with timestamp in constraint exclusion without having to

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Haven't looked at the code, but maybe it'd be better to not bump the strong lock count in the first place until the final step of updating the lock tables? Well, unfortunately, that

Re: [HACKERS] Regarding column reordering project for GSoc 2012

2012-04-09 Thread Bruce Momjian
On Mon, Apr 09, 2012 at 01:29:46PM -0500, Merlin Moncure wrote: but generally speaking jdbc is displacing odbc as the 'go to' library for connection between different kinds of database systems, especially on non-windows environments. jdbc is to java as fdw is to postgres basically. so a fdw

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Alvaro Herrera
Excerpts from Tom Lane's message of lun abr 09 15:38:21 -0300 2012: Alvaro Herrera alvhe...@commandprompt.com writes: Robert Haas robertmh...@gmail.com writes: If somebody needs it I'd probably be in favor of doing it. I'm not sure I'd do it on spec. It would be useful to have a

Re: [HACKERS] HOT updates REDIRECT line pointers

2012-04-09 Thread Bruce Momjian
On Wed, Mar 21, 2012 at 09:28:22PM -0400, Robert Haas wrote: On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: It strikes me that it likely wouldn't be any worse than, oh, say, flipping the default value of standard_conforming_strings, Really?  It's taking away

Re: [HACKERS] Another review of URI for libpq, v7 submission

2012-04-09 Thread Alvaro Herrera
Excerpts from Peter Eisentraut's message of vie abr 06 03:09:10 -0300 2012: On fre, 2012-04-06 at 00:25 -0300, Alvaro Herrera wrote: Some moments of radical thinking later, I became unhappy with the fact that the conninfo stuff and parameter keywords are all crammed in the PQconnectdbParams

[HACKERS] should encoding names be quoted in error messages?

2012-04-09 Thread Peter Eisentraut
Encoding names are currently sometimes quoted (encoding \%s\), sometimes not (encoding %s). Which one should we settle on? In favor of quoting is that we do this for everything else. But since the possible encoding names are known in advance, we know we don't have to do the quoting to avoid

Re: [HACKERS] Revisiting extract(epoch from timestamp)

2012-04-09 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of lun abr 09 15:38:21 -0300 2012: What exactly would you do with it there that you couldn't do more easily and clearly with plain timestamp comparisons? I'm willing to be convinced, but I want to see a case

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Haven't looked at the code, but maybe it'd be better to not bump the strong lock count in the first place until the

Re: [HACKERS] Last gasp

2012-04-09 Thread Peter Eisentraut
On lör, 2012-04-07 at 16:51 -0400, Robert Haas wrote: Even before this CommitFest, it's felt to me like this hasn't been a great cycle for reviewing. I think we have generally had fewer people doing reviews than we did during the 9.0 and 9.1 cycles. I think we had a lot of momentum with the

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Jeff Davis
On Mon, 2012-04-09 at 16:11 -0400, Robert Haas wrote: I wonder though whether you actually need a *count*. What if it were just a flag saying do not take any fast path locks on this object, and once set it didn't get unset until there were no locks left at all on that object? I think

Re: [HACKERS] Last gasp

2012-04-09 Thread Noah Misch
On Mon, Apr 09, 2012 at 09:25:36AM -0400, Robert Haas wrote: On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch n...@leadboat.com wrote: http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch Returned with Feedback after five consecutive days of Waiting on Author. ?That

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Jim Nasby
On 4/9/12 12:32 PM, Robert Haas wrote: I looked at this more. The above analysis is basically correct, but the problem goes a bit beyond an error in LockWaitCancel(). We could also crap out with an error before getting as far as LockWaitCancel() and have the same problem. I think that a

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Jeff Davis
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote: Dumb question... should operations in the various StrongLock functions take place in a critical section? Or is that already ensure outside of these functions? Do you mean CRITICAL_SECTION() in the postgres sense (that is, avoid error paths by

Re: [HACKERS] Last gasp

2012-04-09 Thread Robert Haas
On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch n...@leadboat.com wrote: But objective rules do not require a just judge, and they have a different advantage: predictability.  If I know that a clock starts ticking the moment I get my first review, I'll shape my personal plan accordingly. That works

Re: [HACKERS] Last gasp

2012-04-09 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: At any rate, I think your comments are driving at a good point, which is that CommitFests are a time for patches that are done or very nearly done to get committed, and a time for other patches to get reviewed if they haven't been already. If we make

[HACKERS] To Do wiki

2012-04-09 Thread Jeff Janes
The To Do wiki says not to add things to the page with discussing here. So here are some things to discuss. Assuming the discussion is a brief yup or nope, it seems to make sense to lump them into one email: Vacuuming a table with a large GIN index is painfully slow, because the index is

[HACKERS] plpython triggers are broken for composite-type columns

2012-04-09 Thread Tom Lane
Don't know if anybody noticed bug #6559 http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php I've confirmed that the given test case works in 9.0 but fails in 9.1 and HEAD. It's not terribly sensitive to the details of the SQL: any non-null value for the composite column fails, for

Re: [HACKERS] Last gasp

2012-04-09 Thread Christopher Browne
On Mon, Apr 9, 2012 at 7:38 PM, Robert Haas robertmh...@gmail.com wrote: On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch n...@leadboat.com wrote: But objective rules do not require a just judge, and they have a different advantage: predictability.  If I know that a clock starts ticking the moment I

Re: [HACKERS] plpython triggers are broken for composite-type columns

2012-04-09 Thread Jan Urbański
On 10/04/12 04:20, Tom Lane wrote: Don't know if anybody noticed bug #6559 http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php I've confirmed that the given test case works in 9.0 but fails in 9.1 and HEAD. I find this code pretty unreadable, though, and know nothing to speak of

Re: [HACKERS] bug in fast-path locking

2012-04-09 Thread Jeff Davis
On Mon, 2012-04-09 at 13:32 -0400, Robert Haas wrote: I looked at this more. The above analysis is basically correct, but the problem goes a bit beyond an error in LockWaitCancel(). We could also crap out with an error before getting as far as LockWaitCancel() and have the same problem. I