On Fri, 2008-08-29 at 01:29 -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Fri, 29 Aug 2008, Tom Lane wrote:
> >> You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
> >> It outputs something that might pass for ReST, but only so long as there
> >> are no
Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 29 Aug 2008, Tom Lane wrote:
>> You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
>> It outputs something that might pass for ReST, but only so long as there
>> are no special characters in the data.
> I'd hate to see a focus o
On Fri, 29 Aug 2008, Tom Lane wrote:
You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
It outputs something that might pass for ReST, but only so long as there
are no special characters in the data.
I agree that it's a bad idea to say explicitly that it's "ReST mode"
out
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sat, 23 Aug 2008, Andrew Dunstan wrote:
>> I think we should probably confine ourselves to output formats that are in
>> very wide use or we'll be supporting a vast multitude. CSV and XML both
>> qualify here - not sure that ReST does.
> ReST is accept
On Sat, 23 Aug 2008, Andrew Dunstan wrote:
I think we should probably confine ourselves to output formats that are in
very wide use or we'll be supporting a vast multitude. CSV and XML both
qualify here - not sure that ReST does.
ReST is accepted by Trac, one of the more popular SCM+Project M
Hello,
Sorry for the new thread on this topic, I did not have a copy in my inbox I
could replay to :(
I am not sure of the status of the patch, but I did read through the thread
at:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00054.php
I just wanted to throw out another possible
Dean Rasheed <[EMAIL PROTECTED]> wrote:
> Is it only available to superusers?
Presently, yes.
> Do we have a general policy on
> this? Most logging options are superuser-only, but the recent changes
> to LOG debug_print_* output have left them PGC_USERSET.
I set it PGC_SUSET because other log_
Greg Smith wrote:
> This looks quite handy. Needs to have an update to the view-pg-settings
> section of the docs before it gets applied though.
>
> I'd also like to get the default boot_val for each parameter exposed,
> similarly to how the min and max are available. That should be easy to
> do
This looks quite handy. Needs to have an update to the view-pg-settings
section of the docs before it gets applied though.
I'd also like to get the default boot_val for each parameter exposed,
similarly to how the min and max are available. That should be easy to do
using your changes as a g
> Here is a contrib version of auto-explain.
OK, I hadn't considered doing it as a module before.
Is it only available to superusers? Do we have a general policy on
this? Most logging options are superuser-only, but the recent changes
to LOG debug_print_* output have left them PGC_USERSET.
Rega
Hi,
Here's a patch to add source file and line numbers to GUC variables.
Basically this makes pg_settings look like this:
alvherre=# select name, setting, sourcefile, sourceline from pg_settings where
name like '%work%';
name | setting | sourcefile
Peter,
Well, my original implementation of GUC had an empty default configuration
file, which was later craptaculated to its current form based on seemingly
popular demand. I am very happy to work back toward the empty state, and
there appears to be growing support for that.
I'd prefer a
Kevin,
# maintenance_work_mem = 256MB #webserver with 2GB RAM
Well, that was before multiple autovacuum workers. Now, you'd want it
lower. But ... it's better for vacuum to finish quickly than to drag
on. Vacuum uses more I/O than it does RAM.
But I'm amazed by this, too:
# max_conne
I've been working away at the project I mentioned here:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01131.php
Attached is a patch that's not quite ready to commit, but getting
close. Basically it implements the infrastructure of adding a location
field to nearly all Node types that can
On Thu, Aug 28, 2008 at 3:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alternatively, suggest that the email message submitting the patch
> mentions that "this resolves TODO item so-and-so". Then the committer
> would know to go fix the TODO item.
>
Yes, I've noticed that some submitters are alre
Hi Alvaro,
Alvaro Herrera wrote:
Grant Finnemore wrote:
Well, pg_stat_activity isn't really the problem here, because as you
point out, it's just a view, and I could certainly redefine the view.
The limiting factor is that the backend doesn't push the role name
changes to the stats subsystem f
Grant Finnemore wrote:
> Well, pg_stat_activity isn't really the problem here, because as you
> point out, it's just a view, and I could certainly redefine the view.
> The limiting factor is that the backend doesn't push the role name
> changes to the stats subsystem for either SET ROLE or SET SES
Tom Lane <[EMAIL PROTECTED]> writes:
> Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
>> At 2008-08-28 20:09:21 +0900, [EMAIL PROTECTED] wrote:
>>> For the git hosted projects, should we send in the latest patch file
>>> to this list?
>
>> Yes, please do that.
>
> Yes. You should *not* assume tha
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Yes. You should *not* assume that reviewers are going to look at the
>> git repository.
> However when a committer is actually looking to commit the code he'll want to
> be sure he has the most recent snapshot inc
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We're pretty much assuming bison anyway, no? It's been years since
>> I heard of anyone successfully building the backend grammar with plain
>> yacc.
> In my recollection, you were the last holdout on that with the
> occasional HP
Tom Lane wrote:
We're pretty much assuming bison anyway, no? It's been years since
I heard of anyone successfully building the backend grammar with plain
yacc.
In my recollection, you were the last holdout on that with the
occasional HP-UX yacc test. But I seem to recall that that combinatio
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> At 2008-08-28 20:09:21 +0900, [EMAIL PROTECTED] wrote:
>> For the git hosted projects, should we send in the latest patch file
>> to this list?
> Yes, please do that.
Yes. You should *not* assume that reviewers are going to look at the
git reposito
Bernd Helmle <[EMAIL PROTECTED]> writes:
> I've used above function to construct OpExpr expressions with equality
> operators in the past, but it seems it was removed and there's no
> replacement for it?
Look at get_sort_group_operators() instead. Or use the type cache
directly.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Korry Douglas wrote:
>> Why not use the %output directive in the grammar file instead; that way
>> you don't need to add any special flags to the Makefile.
> I think only bison supports that directive.
We're pretty much assuming bison anyway, no? I
Korry Douglas wrote:
1) Use bison's -o option to put the output file in the right place
directly,
if we are dealing with bison (and don't bother to support code coverage
analysis with other yaccs), or
2) Run a pattern replacement across the grammar output files as their are
renamed.
Why not u
The problem with those files is that the source file contains lines
like this:
#line 1042 "y.tab.c"
but that source file does not exist, as it is renamed to gram.c.
We could fix that in one of two ways:
1) Use bison's -o option to put the output file in the right place
directly,
if we are
Gregory Stark wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
The reason for that problem is that the shared object needs to be linked
with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
linked, which includes the missing symbol.) This is not done because the
shared o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The reason for that problem is that the shared object needs to be linked
> with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
> linked, which includes the missing symbol.) This is not done because the
> shared object link rule
At 2008-08-28 20:09:21 +0900, [EMAIL PROTECTED] wrote:
>
> For the git hosted projects, should we send in the latest patch file
> to this list?
Yes, please do that.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Michelle Caisse wrote:
> Also, two tests fail with the following diff when the build is
> configured with --enable-coverage.
>RETURNS trigger
>AS
> '/home/michelle/trunkClean/pgsql/src/test/regress/../../../contrib/spi/refi
>nt.so' LANGUAGE C;
> + ERROR: could not load library
> "/
Hi,
2008/8/27 Josh Berkus <[EMAIL PROTECTED]>:
> Folks,
>
> The september commit fest starts in one week. The goal, this time, is to
> start reviewing on day 1 of the commit fest and not spend the first 3 days
> collecting extra patches.
>
> So if your patch isn't on the list *on* September 1, it
Michelle Caisse wrote:
> gcov gets confused when source files are generated. I eliminated
> src/backend/bootstrap and ../parser from coverage analysis to avoid
> errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042 "y.tab.c"
but that sour
I've used above function to construct OpExpr expressions with equality
operators in the past, but it seems it was removed and there's no
replacement for it?
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Tom Lane wrote:
> I hadn't read it yet, but that makes it wrong already. There's no need
> for any new inval traffic --- the existing syscache inval messages on
> pg_proc entries should serve fine.
Yes, creating a new message type was a bit short sighted -- attached is a patch
that uses syscache
Hi Bernd,
Bernd Helmle wrote:
--On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore
<[EMAIL PROTECTED]> wrote:
I have a session pool, where all connections to the database are
obtained as a superuser. On issuing connections to the client, we
invoke either SET ROLE or SET SESSION AUTHO
--On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore
<[EMAIL PROTECTED]> wrote:
I have a session pool, where all connections to the database are
obtained as a superuser. On issuing connections to the client, we
invoke either SET ROLE or SET SESSION AUTHORIZATION and switch to
a role wi
36 matches
Mail list logo