--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
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
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
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
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 source
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 may get
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
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:
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 rules
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
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
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
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? It's
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.
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 repository.
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
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-UX yacc
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 including any
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 that reviewers are
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
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
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 already
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
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:
#
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
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
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.
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
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
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_*
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
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
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 accepted by
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
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 on the
35 matches
Mail list logo
