Michael Paquier michael.paqu...@gmail.com wrote:
Please find attached the latest version of the patch,
with the threading bug corrected and the documentation updated as well.
Please don't describe your-specific usage of shell command in the documentation
Why do you use BUFFER_SIZE-1 for
On Thu, Dec 10, 2009 at 3:00 AM, Robert Haas robertmh...@gmail.com wrote:
Done. Yeah, my first commit!
Great! Also, thanks for getting this in 8.4.2. Otherwise I would have
to compile this on Windows myself, which is no fun.
About the tabs vs spaces problem - I`ve decided that copying the
Tom Lane t...@sss.pgh.pa.us writes:
It's not impossible that we'll have to tweak pg_dump a bit; it's
never had to deal with languages that shouldn't be dumped ...
Ah, the best would be to have extensions maybe. Then you could do this
in initdb, filling in template0:
CREATE EXTENSION plpgsql
I think I know why we need tuple lock.
Though we have tuple's infomask shows whether the tuple is being updated,
before we set the tuple's infomask, there may be two transaction coming and
updating the tuple. They both think the tuple is ok to be updated, and then
it's wrong.
In PostgreSQL, we
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
-1
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
-1
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
If the
W dniu 7 grudnia 2009 17:43 użytkownik Greg Smith g...@2ndquadrant.comnapisał:
Filip Rembiałkowski wrote:
Dec 7 07:24:45 nsXX kernel: postgres[22481]: segfault at 7fda5e1d5000
ip 7fda604553c3 sp 7fffe41faf28 error 4 in libc-2.9.so
[7fda603d1000+168000]
Dec 7 07:24:45 nsXX
Roger Leigh wrote:
On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
-1
EXPLAIN is a special case. IMHO it should be dealt
Robert Haas escreveu:
I'm not sure whether this is a good idea or not. Let me read the
patch. I'm not sure an EXPLAIN option is really an adequate
substitute for log_statement_stats - the latter will let you get stats
for all of your queries automatically, I believe, and might still be
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Robert Haas escreveu:
I'm not sure whether this is a good idea or not. Let me read the
patch. I'm not sure an EXPLAIN option is really an adequate
substitute for log_statement_stats - the latter will let you
On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote:
Oh, dear. I think that line continuation syntax was recently added -
subsequent to the machine-readable EXPLAIN patch. The reason why it's
coded to emit everything as a single row is because that will be most
Robert Haas wrote:
I don't believe that machine-readable EXPLAIN output is the only
multi-line output value that anyone would ever wish to cut and paste
into an editor without picking up a lot of stray garbage, so I don't
think this is a solution.
Well, yes, another example that has
--On 8. Dezember 2009 11:10:44 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
If you think that it is better I could split patch into two separate
patches and both can be reviewed separately.
I split up this patch into two separate patches: one for SLRU and one for
the executor probes.
Takahiro Itagaki escribió:
=# EXPLAIN (BUFFERS, ANALYZE) SELECT *
FROM pgbench_accounts a, pgbench_branches b
WHERE a.bid = b.bid AND abalance 0 ORDER BY abalance;
QUERY PLAN
Alvaro Herrera alvhe...@commandprompt.com writes:
Takahiro Itagaki escribió:
Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0)
(temp read=0 written=0)
Maybe I missed part of this discussion, but it seems a bit weird to have
an option named buffers turn on a line
Dne 10.12.09 15:51, Bernd Helmle napsal(a):
--On 8. Dezember 2009 11:10:44 +0100 Zdenek Kotala
zdenek.kot...@sun.com wrote:
If you think that it is better I could split patch into two separate
patches and both can be reviewed separately.
I split up this patch into two separate patches:
On Thu, Dec 10, 2009 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Takahiro Itagaki escribió:
Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0)
(temp read=0 written=0)
Maybe I missed part of this discussion, but it
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Why? If you want this information for all of your queries, you can always set
auto_explain.log_min_duration to 0. But if you're suggesting that we should
maintain
Robert Haas wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both places.
I don't know how blocks got into here in the first place--this concept
is buffers just
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both places.
I don't know how
On Thu, Dec 10, 2009 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Why? If you want this information for all of your queries, you can always
set
Robert Haas escreveu:
The only reason anyone is even thinking that they need parentheses
here is because they're trying to put three separate groups of
buffer-related statistics - a total of 8 values - on the same output
line. If this were split up over three output lines, no one would
even
--On 9. Dezember 2009 19:08:07 -0500 Theo Schlossnagle je...@omniti.com
wrote:
Now, there was some indication that there was a better place to probe
that would be more comprehensive -- that should be addressed.
For now there exists no consensus where they should go in. Tom pointed out
Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
Is it?
Wouldn't it affect anyone who stuck XML in a txt
Andres Freund and...@anarazel.de wrote:
I think you see no real benefit, because your strings are rather
short - the documents I scanned when noticing the issue where
rather long.
The document I used in the test which showed the regression was
672,585 characters, containing 10,000 URLs.
Ron Mayer wrote:
Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
Is it?
Wouldn't it
On Thu, Dec 10, 2009 at 11:44 AM, Ron Mayer
rm...@cheapcomplexdevices.com wrote:
Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
EXPLAIN is a special case. IMHO it should be dealt
Robert Haas robertmh...@gmail.com wrote:
Andrew Dunstan and...@dunslane.net wrote:
A simple if ugly hack would make psql use old-ascii print style
(which doesn't use these contionuation chars) if the first
attribute in the resultset was named 'QUERY PLAN'
I don't believe that
Andrew Dunstan and...@dunslane.net writes:
Yeah, I'm thinking we should probably suppress output of format.nl_right
(no matter what the format) where there is only one column. (This is
even uglier with unicode linestyle, btw). That's a sane rule and it's
not an ugly hack.
Yes it is. The
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Yeah, I'm thinking we should probably suppress output of format.nl_right
(no matter what the format) where there is only one column. (This is
even uglier with unicode linestyle, btw). That's a sane rule and it's
not an ugly hack.
Andrew Dunstan and...@dunslane.net writes:
I don't see much virtue of having these characters when there is only
one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
And clearly I'm
On Thu, Dec 10, 2009 at 12:43 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Yeah, I'm thinking we should probably suppress output of format.nl_right
(no matter what the format) where there is only one column. (This is even
uglier
Hackers,
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
(The Mac Openjade toolchain is unalterably broken, AFAICT) Without
editing the makefiles, it wasn't possible to build PostgreSQL on my OSX
10.4 laptop.
Josh Berkus j...@agliodbs.com writes:
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
How so? The make process does not try to build the docs unless you
specifically tell it to.
Given that, we should have
I wrote:
Thanks for the sample which shows the difference.
Ah, once I got on the right track, there is no problem seeing
dramatic improvements with the patch. It changes some nasty O(N^2)
cases to O(N). In particular, the fixes affect parsing of large
strings encoded with multi-byte
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I don't see much virtue of having these characters when there is only
one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
If that's really what we want then I think we're doing a terrible job of
it. Have
On 12/10/09 10:03 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
How so? The make process does not try to build the docs unless you
Tom Lane wrote:
Why don't you
just do \pset format unaligned (or \a if you're lazy)?
That's fair. Now that I see it, I guess I should have been
doing that for copypaste work anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Josh Berkus j...@agliodbs.com writes:
On 12/10/09 10:03 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
How so? The make process does not try to
Hm, maybe the alpha2 tarball had docs in it already? And they weren't
up to date? You might be hitting the same thing I've complained of:
since make distclean no longer removes built docs, you can find
yourself running an update cycle when you didn't want to. Peter
rejected my opinion
--On 10. Dezember 2009 09:59:44 -0800 Josh Berkus j...@agliodbs.com wrote:
(The Mac Openjade toolchain is unalterably broken, AFAICT) Without
editing the makefiles, it wasn't possible to build PostgreSQL on my OSX
10.4 laptop.
You might get an idea how i fixed that here:
I wrote:
I did find one significant (although easily solved) problem. In
the patch, the recursive setup of usewide, pgwstr, and wstr are
not conditioned by #ifdef USE_WIDE_UPPER_LOWER in the non-patched
version. Unless there's a good reason for that, the #ifdef should
be added.
That
On Thursday 10 December 2009 19:10:24 Kevin Grittner wrote:
I wrote:
Thanks for the sample which shows the difference.
Ah, once I got on the right track, there is no problem seeing
dramatic improvements with the patch. It changes some nasty O(N^2)
cases to O(N). In particular, the fixes
Ron Mayer rm...@cheapcomplexdevices.com wrote:
Tom Lane wrote:
Why don't you
just do \pset format unaligned (or \a if you're lazy)?
That's fair. Now that I see it, I guess I should have been
doing that for copypaste work anyway.
That'll cover my use cases.
-Kevin
--
Sent via
Tom Lane wrote:
regression=# select
E'xxx\nxx\n'
as a, 1 as b;
a | b
--+---
xxx
Andres Freund and...@anarazel.de wrote:
[concerns addressed in new patch version]
Looks good to me. I'm marking this Ready for Committer.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 12/10/09 10:03 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
How so? The make
Zdenek Kotala zdenek.kot...@sun.com writes:
[...]
+ header = (StandardChunkHeader *)
+ ((char *) ret - STANDARDCHUNKHEADERSIZE);
+
+// TRACE_POSTGRESQL_MCXT_ALLOC(context-name, context, size, header-size,
true);
+
[...]
If the dormant overhead of these probes is
Andrew Dunstan and...@dunslane.net writes:
If we really want to make linefeeds visible, I think we should place the
indicators immediately after the character preceding the line feed, not
next to the column separator.
Then it's hard to tell it apart from an instance of that character in
the
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
If we really want to make linefeeds visible, I think we should place the
indicators immediately after the character preceding the line feed, not
next to the column separator.
Then it's hard to tell it apart from an instance
Frank Ch. Eigler píše v čt 10. 12. 2009 v 14:11 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
[...]
+ header = (StandardChunkHeader *)
+ ((char *) ret - STANDARDCHUNKHEADERSIZE);
+
+// TRACE_POSTGRESQL_MCXT_ALLOC(context-name, context, size, header-size,
true);
+
On tis, 2009-12-01 at 20:53 -0700, Joshua Tolley wrote:
This patch doesn't include any documentation; my reading of the PL/Python docs
suggests that's probably acceptable, as the existing docs don't talk about its
array handling. That said, it might be useful to include an example, to show
for
On Wed, Dec 9, 2009 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
so I'd like some independent confirmation that it does.
what kind of tests could show that? or simply running pgbench several
times for 15 minutes each run could show any benefit?
--
Atentamente,
Jaime Casanova
Soporte y
On tor, 2009-12-10 at 09:59 -0800, Josh Berkus wrote:
Given that, we should have a --without-docs build switch which allows us
to disable the doc build.
Btw., if you really, really, really want to avoid the issue (if there
were any), go into the src directory and build there.
--
Sent via
Jaime Casanova escribió:
On Wed, Dec 9, 2009 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
so I'd like some independent confirmation that it does.
what kind of tests could show that? or simply running pgbench several
times for 15 minutes each run could show any benefit?
Isn't the
re:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00754.php
Alvaro Herrera alvhe...@commandprompt.com wrote:
Kevin Grittner wrote:
(Note: I personally would much rather see the performance
penalty addressed this way, and a TODO added for the more
invasive work, than to leave this
On Wed, Dec 9, 2009 at 10:43 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
If you want to avoid all good reasons for this features and are looking
for reasons why this patch is a bad idea, I am sure you can
Hi -
On Thu, Dec 10, 2009 at 09:33:28PM +0100, Zdenek Kotala wrote:
[...]
If the dormant overhead of these probes is measured or suspected to be
excessive, consider using the dtrace-generated per-probe foo_ENABLED()
conditional, or a postgres configuration global thusly:
[...]
Robert Haas robertmh...@gmail.com writes:
Unlike Tom (I think), I do believe that there is demand (possibly only
from a limited number of people, but demand all the same) for this
feature.
Please note that I do not think there is *zero* demand for the feature.
There is obviously some. What I
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The other day I returned idly to thinking about some work I did a few
years ago on creating a totally unprivileged user, i.e. one with not
even public permissions.
And the point would be what exactly?
On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Unlike Tom (I think), I do believe that there is demand (possibly only
from a limited number of people, but demand all the same) for this
feature.
Please note that I do not think there is *zero*
Hi,
On Thursday 10 December 2009 23:08:17 Tom Lane wrote:
My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port. If SEPostgres could
bring us even 10% as
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all
My two cents - if it's desired -
I invariably disable selinux from all of my production machines. Once
upon a time I tried to work with it time and time again - but it was
such a head ache to administer for what I considered to be marginal
gains, that I eventually gave up. Every time I add a
We have a couple of lingering re-reviews that are still ongoing (myself
on pgbench setshell and the two DTrace ones), and the ECPG patches are
still hanging around, but we're basically finished with reviews for all
submitted patches at this point. So far 12 patches have been commited
since
On tis, 2009-12-01 at 18:03 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2009/12/1 Bruce Momjian br...@momjian.us:
What are we going to do for build farm members who don't support
threading? Is someone going to manually update their configure
On ons, 2009-12-09 at 14:02 -0500, Jaime Casanova wrote:
Hi,
I compiled current HEAD and trying to use pgbench, i initialized a
test database this way:
bin/pgbench -i -F80 -s100 test
and then run with this options:
bin/pgbench -c 50 -j 5 -l -t 20 test
and get this crash:
starting
age...@themactionfaction.com (A.M.) writes:
[Much of interest elided... Cool to see that clang clearly *can*
compile PostgreSQL...]
You are probably running configure with gcc, no?
I was *attempting* to run configure using clang:
CC=/usr/bin/clang ./configure
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I'm inclined that it would be no more work to replace the current
recursively called state engine with something easier to read and
understand than to try to fix the current oddities. Perhaps
something along the lines of this?:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch simply ignores
On tor, 2009-12-10 at 17:20 -0500, Andrew Dunstan wrote:
Some time later it came up again, this time when someone wanted to use a
readonly database (hence no pg_dump required) with an application and
wanted to keep the database layout and the source code of stored
functions hidden as they
On ons, 2009-12-09 at 16:23 -0500, Chris Browne wrote:
This is a C front end for the LLVM compiler... I noticed that it
entered Debian/Unstable today:
http://packages.debian.org/sid/main/clang
I thought it would be interesting to see if PostgreSQL compiles with
this, as an alternative
Hi Guys
I have some files that were part of a database, I mean they were under
/*data/base/DB_OID/table_oid* postgres structure
As I understand *table_oid *which is a numbered file corresponds to one
table in the original database.
Here is my question: Is there a tool/method to view the
Peter Eisentraut wrote:
On tor, 2009-12-10 at 17:20 -0500, Andrew Dunstan wrote:
Some time later it came up again, this time when someone wanted to use a
readonly database (hence no pg_dump required) with an application and
wanted to keep the database layout and the source code of stored
Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
It's not impossible that we'll have to tweak pg_dump a bit; it's
never had to deal with languages that shouldn't be dumped ...
Ah, the best would be to have extensions maybe. Then you could do this
in initdb, filling in
Peter Eisentraut wrote:
starting vacuum...end.
TRAP: FailedAssertion(!((data - start) == data_size), File:
heaptuple.c, Line: 255)
Client 0 aborted in state 8. Probably the backend died while processing.
LOG: server process (PID 30713) was terminated by signal 6: Aborted
TRAP:
Heiner Vega Thames escribió:
Hi Guys
I have some files that were part of a database, I mean they were
under /*data/base/DB_OID/table_oid* postgres structure
As I understand *table_oid *which is a numbered file corresponds to
one table in the original database.
Here is my question: Is
Andrew Dunstan wrote:
Tom Lane wrote:
regression=# select
E'xxx\nxx\n'
as a, 1 as b;
a | b
Bruce Momjian wrote:
Peter Eisentraut wrote:
if i remove the -j option then it runs without a problem
Possibly related to the incomplete removal of the enable-thread-safety
option that I just posted about.
I thought about that but I can't figure out how that would affect
KaiGai Kohei kai...@ak.jp.nec.com wrote:
we still allow SELECT * FROM pg_largeobject ...right?
It can be solved with revoking any privileges from anybody in the initdb
phase. So, we should inject the following statement for setup_privileges().
REVOKE ALL ON pg_largeobject FROM PUBLIC;
Tom Lane wrote:
My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port.
Wow, if I thought that was the case I'd be as negative about the whole
thing as you
Greg Smith wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
if i remove the -j option then it runs without a problem
Possibly related to the incomplete removal of the enable-thread-safety
option that I just posted about.
I thought about that but I can't figure
Tom Lane wrote:
Greg Smith g...@2ndquadrant.com writes:
To be clear about which version we're talking about:
http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp
is the candidate for commit that includes the cleanup you've already done.
I suppose
On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If I thought that Bruce could go off in a corner and make this happen
and it would create no demands on anybody but him and KaiGai-san, I
would say fine, if that's where you want to spend your time, go for
it. But even to
Peter Eisentraut wrote:
On tis, 2009-12-01 at 18:03 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2009/12/1 Bruce Momjian br...@momjian.us:
What are we going to do for build farm members who don't support
threading? Is someone going to
Bruce Momjian wrote:
Greg Smith wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
if i remove the -j option then it runs without a problem
Possibly related to the incomplete removal of the enable-thread-safety
option that I just posted about.
I
Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith g...@2ndquadrant.com wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. ?I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both
On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan and...@dunslane.net wrote:
OK, I've committed the YAML stuff, so who is working on the auto-explain
bug? Robert? I'd like that fixed before I add in the query text to
auto-explain output.
I'm going to propose fixing this in what seems to me to be
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
David P. Quigley wrote:
On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Unlike Tom (I think), I do believe that there is demand (possibly only
from a limited number of people, but demand all the same) for this
feature.
Please note that I do not
Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan and...@dunslane.net wrote:
OK, I've committed the YAML stuff, so who is working on the auto-explain
bug? Robert?
I'm going to propose fixing this in what seems to me to be the
simplest possible way,
On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian br...@momjian.us wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
regression=# select
E'xxx\nxx\n'
as a, 1 as b;
a
Takahiro Itagaki wrote:
KaiGai Kohei kai...@ak.jp.nec.com wrote:
we still allow SELECT * FROM pg_largeobject ...right?
It can be solved with revoking any privileges from anybody in the initdb
phase. So, we should inject the following statement for setup_privileges().
REVOKE ALL ON
Robert Haas robertmh...@gmail.com writes:
Hilariously enough, that's exactly what we used to do. I am leaning
toward the view that we should revert all the ASCII output format
changes vs. 8.4 and let people use the new unicode mode if they want
all the spiffy bells and whistles.
There are
* Greg Smith (g...@2ndquadrant.com) wrote:
I personally feel that Steven
Frost's recent comments here about how the PostgreSQL code makes this
harder than it should be really cuts to the core of a next step here.
The problem facing us isn't is SEPostgreSQL the right solution for
KaiGai Kohei kai...@ak.jp.nec.com wrote:
What's your opinion about:
long desc: When turned on, privilege checks on large objects perform with
backward compatibility as 8.4.x or earlier releases.
I updated the description as your suggest.
Applied with minor editorialization,
Stephen Frost wrote:
* Greg Smith (g...@2ndquadrant.com) wrote:
I have to be honest and say that I'm not optimistic that this is
possible or even a good idea to accomplish in the time remaining during
this release.
While I agree with you, I wish you hadn't brought it up. :)
Greg Smith g...@2ndquadrant.com writes:
The -j option is the recent addition to pgbench that causes it to
launch multiple client threads when enabled, each handling a subset of
the transactions. There's blocks of codes in pgbench.c now that depend
on having sane values for thread safety in
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
OK, I'll add the following description in the documentation of pg_largeobject.
structnamepg_largeobject/structname should not be readable by the
public, since the catalog contains data in large objects of all users.
This is going
1 - 100 of 117 matches
Mail list logo
