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
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
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
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
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
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
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
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
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
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
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))
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
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
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
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
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
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
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
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
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
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
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
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
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
$
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
57 matches
Mail list logo