Re: [HACKERS] LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

2011-12-16 Thread Lionel Elie Mamane
On Tue, Dec 13, 2011 at 11:45:28AM +0100, Magnus Hagander wrote: On Tue, Dec 13, 2011 at 11:15, Lionel Elie Mamane lio...@mamane.lu wrote: LibreOffice can be configured at build-time to use Mozilla LDAP or OpenLDAP. We patched postgresql's configure.in to build libpq with Mozilla LDAP when

Re: [HACKERS] LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

2011-12-16 Thread Lionel Elie Mamane
On Wed, Dec 14, 2011 at 10:05:26AM -0500, Tom Lane wrote: Pavel Golub pa...@microolap.com writes: You wrote: TL about OSX though. (You're aware that Apple ships a perfectly fine TL libpq.so in Lion, no?) I've not made an attempt to use it directly myself, but it sure looks like it should

Re: [HACKERS] LibreOffice driver 2: MIT Kerberos vs Microsoft Kerberos

2011-12-16 Thread Lionel Elie Mamane
On Tue, Dec 13, 2011 at 05:09:01PM -0500, Stephen Frost wrote: * Greg Smith (g...@2ndquadrant.com) wrote: Given that pgAdmin III has given up on MIT KRB5, would you feel doing the same is appropriate for LibreOffice too? Yes, I'd encourage LibreOffice to drop MIT Kerberos for Windows from

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

2011-12-16 Thread Marti Raudsepp
On Fri, Dec 16, 2011 at 09:13, Greg Smith g...@2ndquadrant.com wrote: I think what would be helpful here next is a self-contained benchmarking script. Alright, a simple script is attached. One of the first questions I have is whether the performance changed between there and your v5. Not

Re: [HACKERS] Moving more work outside WALInsertLock

2011-12-16 Thread Heikki Linnakangas
On 16.12.2011 05:27, Tom Lane wrote: * We write a WAL record that starts 8 bytes before a sector boundary, so that the prev_link is in one sector and the rest of the record in the next one(s). prev-link is not the first field in the header. The CRC is. * Time passes, and we recycle that WAL

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

2011-12-16 Thread Simon Riggs
On Wed, Nov 30, 2011 at 4:42 AM, Robert Haas robertmh...@gmail.com wrote: It strikes me that there are really two separate problems here. 1. If you are scanning a system catalog using SnapshotNow, and a commit happens at just the right moment, you might see two versions of the row or zero

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Greg Smith
On 12/14/2011 05:24 AM, Magnus Hagander wrote: How about passing a parameter to pg_signal_backend? Making pg_signal_backend(int pid, int sig, bool allow_samerole)? That works, got rid of the parts I didn't like and allowed some useful minor restructuring. I also made the HINT better and

Re: [HACKERS] Moving more work outside WALInsertLock

2011-12-16 Thread Simon Riggs
On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Anyway, I'm looking at ways to make the memcpy() of the payload happen without the lock, in parallel, and once you do that the record header CRC calculation can be done in parallel, too. That makes

Re: [HACKERS] Moving more work outside WALInsertLock

2011-12-16 Thread Heikki Linnakangas
On 16.12.2011 14:37, Simon Riggs wrote: On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Anyway, I'm looking at ways to make the memcpy() of the payload happen without the lock, in parallel, and once you do that the record header CRC calculation

Re: [HACKERS] Moving more work outside WALInsertLock

2011-12-16 Thread Simon Riggs
On Fri, Dec 16, 2011 at 12:50 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 16.12.2011 14:37, Simon Riggs wrote: On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com  wrote: Anyway, I'm looking at ways to make the memcpy() of the

Re: [HACKERS] Storing hot members of PGPROC out of the band

2011-12-16 Thread Robert Haas
On Thu, Dec 15, 2011 at 11:35 PM, Robert Haas robertmh...@gmail.com wrote: One small detail I'm noticing on further review is that I've slightly changed the semantics here:            if (!TransactionIdIsNormal(xid)                || NormalTransactionIdPrecedes(xmax, xid))                    

Re: [HACKERS] foreign key locks, 2nd attempt

2011-12-16 Thread Greg Smith
Sounds like there's still a few things left to research out on Alvaro's side, and I'm thinking there's a performance/reliability under load testing side of this that will take some work to validate too. Since I can't see all that happening fast enough to commit for a bit, I'm going to mark it

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

2011-12-16 Thread Robert Haas
On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs si...@2ndquadrant.com wrote: That is a bug and one we should fix. I supplied a patch for that, written to Tom's idea for how to solve it. I will apply that, unless there are objections. I remember several attempts at that, but I don't remember any

Re: [HACKERS] Moving more work outside WALInsertLock

2011-12-16 Thread Heikki Linnakangas
On 16.12.2011 15:03, Simon Riggs wrote: On Fri, Dec 16, 2011 at 12:50 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 16.12.2011 14:37, Simon Riggs wrote: I already proposed a design for that using page-level share locks any reason not to go with that? Sorry, I must've

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Robert Haas
On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith g...@2ndquadrant.com wrote: This is a problem with the existing code though, and the proposed changes don't materially alter that; there's just another quick check in one path through.  Right now we check if someone is superuser, then if it's a

Re: [HACKERS] review: CHECK FUNCTION statement

2011-12-16 Thread Albe Laurenz
Pavel Stehule wrote: one small update - better emulation of environment for security definer functions Patch applies and compiles fine, core functionality works fine. I found a little bug: In backend/commands/functioncmds.c, function CheckFunction(CheckFunctionStmt *stmt), while you perform

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Robert Haas
On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan and...@dunslane.net wrote: Make JSON datatypes only selectable if client encoding is UTF-8. Yuck. Do we have this sort of restriction for any other data type? No, and I don't think it's necessary to do it here, either. Nor would it be a good

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

2011-12-16 Thread Simon Riggs
On Fri, Dec 16, 2011 at 1:38 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs si...@2ndquadrant.com wrote: That is a bug and one we should fix. I supplied a patch for that, written to Tom's idea for how to solve it. I will apply that, unless there are

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Simon Riggs
On Fri, Dec 16, 2011 at 1:52 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan and...@dunslane.net wrote: Make JSON datatypes only selectable if client encoding is UTF-8. Yuck. Do we have this sort of restriction for any other data type? No, and I

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Greg Smith
On 12/16/2011 08:42 AM, Robert Haas wrote: the proposed patch would potentially result - in the extremely unlikely event of a super-fast PID wraparound - in someone cancelling a query they otherwise wouldn't have been able to cancel. So how might this get exploited? -Attach a debugger

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Magnus Hagander
On Friday, December 16, 2011, Robert Haas wrote: On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith g...@2ndquadrant.comjavascript:; wrote: This is a problem with the existing code though, and the proposed changes don't materially alter that; there's just another quick check in one path

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Magnus Hagander
On Friday, December 16, 2011, Greg Smith wrote: On 12/16/2011 08:42 AM, Robert Haas wrote: the proposed patch would potentially result - in the extremely unlikely event of a super-fast PID wraparound - in someone cancelling a query they otherwise wouldn't have been able to cancel. So

Re: [HACKERS] Patch to allow users to kill their own queries

2011-12-16 Thread Alvaro Herrera
Excerpts from Greg Smith's message of vie dic 16 11:19:52 -0300 2011: On 12/16/2011 08:42 AM, Robert Haas wrote: the proposed patch would potentially result - in the extremely unlikely event of a super-fast PID wraparound - in someone cancelling a query they otherwise wouldn't have been

[HACKERS] Escaping : in .pgpass - code or docs bug?

2011-12-16 Thread Richard Huxton
According to the docs [1], you should escape embedded colons in .pgpass (fair enough). Below is PG 9.1.1 user = te:st, db = te:st, password = te:st $ cat ~/.pgpass *:*:te:st:te:st:te:st $ psql91 -U te:st -d te:st te:st= $ cat ~/.pgpass *:*:te\:st:te\:st:te:st $

[HACKERS] archive_keepalive_command

2011-12-16 Thread Simon Riggs
archive_command and restore_command describe how to ship WAL files to/from an archive. When there is nothing to ship, we delay sending WAL files. When no WAL files, the standby has no information at all. To provide some form of keepalive on quiet systems the archive_keepalive_command provides a

Re: [HACKERS] RangeVarGetRelid()

2011-12-16 Thread Noah Misch
On Thu, Dec 15, 2011 at 07:04:20PM -0500, Robert Haas wrote: On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch n...@leadboat.com wrote: It also seems my last explanation didn't convey the point. ?Yes, nearly every command has a different set of permissions checks. ?However, we don't benefit

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

2011-12-16 Thread Greg Smith
That looks easy enough to try out now, thanks for the script. Jaime was interested in trying this out, and I hope he still finds time to do that soon. Now that things have settled down and it's obvious how to start testing, that should be a project he can take on. I don't think this is

Re: [HACKERS] why do we need two snapshots per query?

2011-12-16 Thread Dimitri Fontaine
Robert Haas robertmh...@gmail.com writes: I thought about adjusting it, but I didn't see what it made sense to adjust it to. It still is the parameter used for parameter I/O and parsing/planning, so the existing text isn't wrong. It will possibly also get reused for execution, but the

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

2011-12-16 Thread Marti Raudsepp
On Fri, Dec 16, 2011 at 18:08, Greg Smith g...@2ndquadrant.com wrote: I don't think this is going to reach ready to commit in the next few days though, so I'm going to mark it as returned for this CommitFest. Fair enough, I just hope this doesn't get dragged into the next commitfest without

Re: [HACKERS] Prep object creation hooks, and related sepgsql updates

2011-12-16 Thread Dimitri Fontaine
Hi, Kohei KaiGai kai...@kaigai.gr.jp writes: The attached patches are revised ones. I added explanations of DDL permissions on creation time added by these patches, and added a few regression test cases. The whole patches are now against contrib/sepgsql, which seems to me to be a good news,

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Joey Adams
On Fri, Dec 16, 2011 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote: But I think the important point is that this is an obscure corner case. Let me say that one more time: obscure corner case! +1 The only reason JSON needs to care about this at all is that it allows \u1234 to mean

Re: [HACKERS] CommitFest 2011-11 Update

2011-12-16 Thread Peter Geoghegan
On 15 December 2011 19:07, Robert Haas robertmh...@gmail.com wrote: I think that the tuplesort comparison overhead reduction is in Peter G's hands to rebase at the moment; I will look at that again when it reemerges. Yes, sorry about that - I was a little bit sidetracked by something else.

Re: [HACKERS] WIP: SP-GiST, Space-Partitioned GiST

2011-12-16 Thread Greg Smith
Since this was marked WIP and Tom has now kicked off two side discussions, what I've done is tagged references to each of them as comments to the main patch, then marked this as returned with feedback. Surely what I do in the CF app isn't going to influence what Tom wants to work on, so I'll

Re: [HACKERS] Prep object creation hooks, and related sepgsql updates

2011-12-16 Thread Greg Smith
On 12/16/2011 11:58 AM, Dimitri Fontaine wrote: The whole patches are now against contrib/sepgsql, which seems to me to be a good news, but means I'm not skilled to help review further. I'm unsure about marking that as “ready for commiter” but I'm definitely done myself. Robert already

Re: [HACKERS] Review: Non-inheritable check constraints

2011-12-16 Thread Greg Smith
On 12/04/2011 02:22 AM, Nikhil Sontakke wrote: Is it okay to modify an existing constraint to mark it as only, even if it was originally inheritable? This is not clear to me. Maybe the safest course of action is to raise an error. Or maybe I'm misreading what it does (because

Re: [HACKERS] review: CHECK FUNCTION statement

2011-12-16 Thread Greg Smith
I just poked at this a bit myself to see how the patch looked. There's just over 4000 lines in the diff. Even though 1/4 of that is tests, which is itself encouraging, that's still a good sized feature. The rate at which code here has still been changing regularly here has me nervous about

Re: [HACKERS] Review: Non-inheritable check constraints

2011-12-16 Thread Alvaro Herrera
Excerpts from Greg Smith's message of vie dic 16 15:02:20 -0300 2011: On 12/04/2011 02:22 AM, Nikhil Sontakke wrote: Is it okay to modify an existing constraint to mark it as only, even if it was originally inheritable? This is not clear to me. Maybe the safest course of

Re: [HACKERS] patch for type privileges

2011-12-16 Thread Greg Smith
On 12/13/2011 01:13 PM, Yeb Havinga wrote: On 2011-12-12 20:53, Peter Eisentraut wrote: postgres= create table a (a int2[]); ERROR: permission denied for type smallint[] OK, that error message should be improved. Fixing this is easy, but I'd like to look into refactoring this a bit. Let's

Re: [HACKERS] Allow substitute allocators for PGresult.

2011-12-16 Thread Greg Smith
On 12/01/2011 05:48 AM, Kyotaro HORIGUCHI wrote: xfer time Peak RSS Original: 6.02s 850MB libpq patch + Original dblink : 6.11s 850MB full patch : 4.44s 643MB These look like

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

2011-12-16 Thread Jaime Casanova
On Fri, Dec 16, 2011 at 11:08 AM, Greg Smith g...@2ndquadrant.com wrote: That looks easy enough to try out now, thanks for the script. Jaime was interested in trying this out, and I hope he still finds time to do that soon. Actually i tried some benchmarks with the original version of the

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-12-16 Thread Greg Smith
On 12/13/2011 04:04 PM, Alexander Korotkov wrote: On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis pg...@j-davis.com mailto:pg...@j-davis.com wrote: * There's a lot of code for range_gist_penalty. Rather than having special cases for all combinations of properties in the new an

Re: [HACKERS] pg_restore --no-post-data and --post-data-only

2011-12-16 Thread Greg Smith
On 12/12/2011 04:35 PM, Andrew Dunstan wrote: Should all be fixed. Revised patch attached. There were two successful test results here and only minor things noted to fix, which are all cleaned up now. This seems ready for a committer now; I'm just now sure if you want to do it yourself or

Re: [HACKERS] pg_restore --no-post-data and --post-data-only

2011-12-16 Thread Andrew Dunstan
On 12/16/2011 02:43 PM, Greg Smith wrote: On 12/12/2011 04:35 PM, Andrew Dunstan wrote: Should all be fixed. Revised patch attached. There were two successful test results here and only minor things noted to fix, which are all cleaned up now. This seems ready for a committer now; I'm

Re: [HACKERS] Inlining comparators as a performance optimisation

2011-12-16 Thread Greg Smith
I think we can call a new sorting infrastructure popping out and what looks to be over 90 messages on this topic as successful progress on this front. Peter's going to rev a new patch, but with more performance results to review and followup discussion I can't see this one as wrapping for the

Re: [HACKERS] CommitFest 2011-11 Update

2011-12-16 Thread Greg Smith
It's time for another one of these again. We're now just past the nominal 1 month goal of each CommitFest, and as you can obviously see from my list traffic I'm trying to close things up. One of the CF goals is to give everyone who submits something a fair review. There are a few patches

Re: [HACKERS] WIP: cross column stats revisited ...

2011-12-16 Thread Jim Nasby
On Nov 30, 2011, at 2:38 PM, Robert Haas wrote: 2011/9/13 PostgreSQL - Hans-Jürgen Schönig postg...@cybertec.at: hello everybody, here is the next version of the cross column patch. in the meantime zoli and i managed to make the cross column sampling work. some prototype syntax is already

Re: [HACKERS] Review: Non-inheritable check constraints

2011-12-16 Thread Alex Hunsaker
On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah.  Nikhil, Alex, this is the merged patch.  Have a look that it still works for you (particularly the pg_dump bits) and I'll commit it. I adjusted the regression test a bit too. Other than the version checks

Re: [HACKERS] Review: Non-inheritable check constraints

2011-12-16 Thread Alvaro Herrera
Excerpts from Alex Hunsaker's message of vie dic 16 17:50:12 -0300 2011: On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah.  Nikhil, Alex, this is the merged patch.  Have a look that it still works for you (particularly the pg_dump bits) and I'll

Re: [HACKERS] Review: Non-inheritable check constraints

2011-12-16 Thread Alex Hunsaker
On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Alex Hunsaker's message of vie dic 16 17:50:12 -0300 2011: On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah.  Nikhil, Alex, this is the merged patch.  Have a

Re: [HACKERS] WIP: cross column stats revisited ...

2011-12-16 Thread Boszormenyi Zoltan
Hi, 2011-12-16 21:42 keltezéssel, Jim Nasby írta: On Nov 30, 2011, at 2:38 PM, Robert Haas wrote: 2011/9/13 PostgreSQL - Hans-Jürgen Schönig postg...@cybertec.at: hello everybody, here is the next version of the cross column patch. in the meantime zoli and i managed to make the cross column

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Daniel Farina
On Tue, Dec 13, 2011 at 1:13 PM, Merlin Moncure mmonc...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut pete...@gmx.net wrote: On tis, 2011-12-13 at 08:44 -0500, Robert Haas wrote: Just because all our languages are Turing-complete doesn't mean they are all equally

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Andrew Dunstan
On 12/16/2011 05:39 PM, Daniel Farina wrote: To the best of my knowledge: libv8 is also exception-free, and compiled with exceptions off. plv8 does make use of exceptions, though, something that gave me pause when reading it. At first I thought it was to integrate with libv8, but that did

Re: [HACKERS] Storing hot members of PGPROC out of the band

2011-12-16 Thread Bruce Momjian
Robert Haas wrote: On that theory, I'm inclined to think that's not really a problem. We'll go nuts if we refuse to commit anything until it shows a meaningful win on every imaginable workload, and it seems like this can't really be worse than the status quo; any case where it is must be some

Re: [HACKERS] JSON for PG 9.2

2011-12-16 Thread Robert Haas
On Fri, Dec 16, 2011 at 12:13 PM, Joey Adams joeyadams3.14...@gmail.com wrote: So, if the server encoding is not UTF-8, should we ban Unicode escapes:    \u00FCber or non-ASCII characters?    über The former. Refusing the escapes makes sense, because it's totally unclear how we ought to

Re: [HACKERS] Storing hot members of PGPROC out of the band

2011-12-16 Thread Robert Haas
On Fri, Dec 16, 2011 at 8:25 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On that theory, I'm inclined to think that's not really a problem. We'll go nuts if we refuse to commit anything until it shows a meaningful win on every imaginable workload, and it seems like this can't

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

2011-12-16 Thread Robert Haas
On Fri, Dec 16, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote: On Fri, Dec 16, 2011 at 1:38 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs si...@2ndquadrant.com wrote: That is a bug and one we should fix. I supplied a patch for that,

Re: [HACKERS] Storing hot members of PGPROC out of the band

2011-12-16 Thread Jim Nasby
On Dec 16, 2011, at 7:25 PM, Bruce Momjian wrote: Robert Haas wrote: On that theory, I'm inclined to think that's not really a problem. We'll go nuts if we refuse to commit anything until it shows a meaningful win on every imaginable workload, and it seems like this can't really be worse than