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

On Tue, Dec 13, 2011 at 11:45:28AM +0100, Magnus Hagander wrote: > On Tue, Dec 13, 2011 at 11:15, Lionel Elie Mamane 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 requested to

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

On Wed, Dec 14, 2011 at 10:05:26AM -0500, Tom Lane wrote: > Pavel Golub 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 do what t

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

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"

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

On Fri, Dec 16, 2011 at 09:13, Greg Smith 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 those testcases any

Re: [HACKERS] Moving more work outside WALInsertLock

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 f

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

On Wed, Nov 30, 2011 at 4:42 AM, Robert Haas 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 rather than one.  Yo

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

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 m

Re: [HACKERS] Moving more work outside WALInsertLock

On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas 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 it irrelevant from a > performanc

Re: [HACKERS] Moving more work outside WALInsertLock

On 16.12.2011 14:37, Simon Riggs wrote: On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas 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 m

Re: [HACKERS] Moving more work outside WALInsertLock

On Fri, Dec 16, 2011 at 12:50 PM, Heikki Linnakangas wrote: > On 16.12.2011 14:37, Simon Riggs wrote: >> >> On Fri, Dec 16, 2011 at 12:07 PM, Heikki Linnakangas >>  wrote: >> >>> Anyway, I'm looking at ways to make the memcpy() of the payload happen >>> without the lock, in parallel, and once you

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

On Thu, Dec 15, 2011 at 11:35 PM, Robert Haas 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)) >                    continue; > > T

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

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

On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs 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 that didn't meet w

Re: [HACKERS] Moving more work outside WALInsertLock

On 16.12.2011 15:03, Simon Riggs wrote: On Fri, Dec 16, 2011 at 12:50 PM, Heikki Linnakangas 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 missed that. Got a link? From ne

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

On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith 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 backend > PID, then we s

Re: [HACKERS] review: CHECK FUNCTION statement

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

On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan 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 idea, because then

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

On Fri, Dec 16, 2011 at 1:38 PM, Robert Haas wrote: > On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs 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

Re: [HACKERS] JSON for PG 9.2

On Fri, Dec 16, 2011 at 1:52 PM, Robert Haas wrote: > On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan 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

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

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 and

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

On Friday, December 16, 2011, Robert Haas wrote: > On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith > > > 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

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

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.

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

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 h

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

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

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 g

Re: [HACKERS] RangeVarGetRelid()

On Thu, Dec 15, 2011 at 07:04:20PM -0500, Robert Haas wrote: > On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch 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 > > equally

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

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 going

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

Robert Haas 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 previous statement has a

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

On Fri, Dec 16, 2011 at 18:08, Greg Smith 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 feedback. > perhaps

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

Hi, Kohei KaiGai 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, but means I'm n

Re: [HACKERS] JSON for PG 9.2

On Fri, Dec 16, 2011 at 8:52 AM, Robert Haas 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 Unicode code point 0x

Re: [HACKERS] CommitFest 2011-11 Update

On 15 December 2011 19:07, Robert Haas 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. I'll work on it tomorr

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

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 l

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

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 too

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

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 (becaus

Re: [HACKERS] review: CHECK FUNCTION statement

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 c

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

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 cou

Re: [HACKERS] patch for type privileges

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.

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 interes

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

On Fri, Dec 16, 2011 at 11:08 AM, Greg Smith 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 patch and saw some r

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

On 12/13/2011 04:04 PM, Alexander Korotkov wrote: On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis > 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 original, is it poss

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

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 ha

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

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 just

Re: [HACKERS] Inlining comparators as a performance optimisation

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

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 tha

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

On Nov 30, 2011, at 2:38 PM, Robert Haas wrote: > 2011/9/13 PostgreSQL - Hans-Jürgen Schönig : >> 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 working and

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

On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera 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 seem to be off by one loo

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

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 > 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 adjuste

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

On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera 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 >> wrote: >> >> > Yeah.  Nikhil, Alex, this is the merged patch.  Have a look that it >> > still works for you (par

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

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 : >>> hello everybody, >>> >>> here is the next version of the cross column patch. >>> in the meantime zoli and i managed to make the cross column sampl

Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 13, 2011 at 1:13 PM, Merlin Moncure wrote: > On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut 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 well-suited to every task.  Of co

Re: [HACKERS] JSON for PG 9.2

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 no

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

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

Re: [HACKERS] JSON for PG 9.2

On Fri, Dec 16, 2011 at 12:13 PM, Joey Adams 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 interpret them.

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

On Fri, Dec 16, 2011 at 8: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

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

On Fri, Dec 16, 2011 at 8:54 AM, Simon Riggs wrote: > On Fri, Dec 16, 2011 at 1:38 PM, Robert Haas wrote: >> On Fri, Dec 16, 2011 at 7:07 AM, Simon Riggs 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 app

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

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 wo