On Tue, Mar 27, 2012 at 03:17:36AM +0100, Greg Stark wrote:
I may be forgetting something obvious here but is there even a
function to send an interrupt signal? That would trigger the same
behaviour that a user hitting C-c would trigger which would only be
handled at the next
On Mon, Mar 26, 2012 at 5:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On Mon, Mar 26, 2012 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Could you give us a brain dump on the sketch? I've never seen how to
do it without unreasonable overhead.
Hm. So my
On Tue, Mar 27, 2012 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
This is probably a dumb question but... surely there's more than 2
committers able to review?
Able and willing might be two different things. Alvaro, Heikki, and
Magnus have all been
Hi,
First things first, thanks for the review!
I'm working on a new version of the patch to fix all the specific
comments you called nitpicking here and in your previous email. This
new patch will also implement a single list of triggers to run in
alphabetical order, not split by ANY/specific
On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
I think the more important question is a policy question: do we want
it to work like this? It seems like a policy question that ought to
be left to the DBA, but we have no policy management framework for
DBAs to configure what they
Hi,
fprintf(stderr, _(%s: could not identify system: %s\n),
progname, PQerrorMessage(conn));
Since PQerrorMessage() result includes a trailing newline, the above
log message in pg_basebackup doesn't need to include a trailing \n.
Attached patch gets rid of that \n.
Shigeru HANADA wrote:
I've implemented pgsql_fdw's own deparser and enhanced some features
since last post. Please apply attached patches in the order below:
Changes from previous version
=
1) Don't use remote EXPLAIN for cost/rows estimation, so now planner
On Mon, Mar 26, 2012 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander mag...@hagander.net wrote:
s/segment/file/g?
We're already using file to mean something different *internally*,
don't we? And since
On Thu, Jan 26, 2012 at 11:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 24, 2012 at 4:39 AM, Thomas Ogrisegg
tom-...@patches.fnord.at wrote:
While testing a backup script, I noticed that pg_basebackup exits with
0, even if it had errors while writing the backup to disk when the
Thanks for the comments.
(2012/03/27 18:36), Albe Laurenz wrote:
2) Defer planning stuffs as long as possible to clarify the role of
each
function. Currently GetRelSize just estimates result rows from local
statistics, and GetPaths adds only one path which represents SeqScan
on
remote
2012/3/26 Shigeru HANADA shigeru.han...@gmail.com:
(2012/03/15 23:06), Shigeru HANADA wrote:
Although the patches are still WIP, especially in WHERE push-down part,
but I'd like to post them so that I can get feedback of the design as
soon as possible.
I've implemented pgsql_fdw's own
Shigeru HANADA wrote:
My gut feeling is that planning should be done by the server which
will execute the query.
Agreed, if selectivity of both local filtering and remote filtering
were
available, we can estimate result rows correctly and choose better
plan.
How about getting # of rows
On Tue, Mar 27, 2012 at 3:22 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
According to what I've learned in the last couple of months, array_agg
is not ready for fallback ways like dumping to tuplestore. Even
merge-state is not able for them. The problem is that the executor
doesn't know
On Tue, Mar 27, 2012 at 4:27 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
In the first versions of the patch I did try to have a single point
where to integrate the feature and that didn't work out. If you want to
publish information such as object id, name and schema you need to have
On Tue, Mar 27, 2012 at 11:04, Noah Misch n...@leadboat.com wrote:
On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
I think the more important question is a policy question: do we want
it to work like this? It seems like a policy question that ought to
be left to the DBA, but we
On 22.03.2012 23:42, Alex wrote:
Okay, at last here's v9, rebased against current master branch.
Some quick comments on this patch:
I see a compiler warning:
fe-connect.c: In function ‘conninfo_parse’:
fe-connect.c:4113: warning: unused variable ‘option’
Docs are missing.
I wonder if you
On Tue, Mar 27, 2012 at 02:58:26PM +0200, Magnus Hagander wrote:
On Tue, Mar 27, 2012 at 11:04, Noah Misch n...@leadboat.com wrote:
On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
I think the more important question is a policy question: do we want
it to work like this? ?It
On Tuesday, March 27, 2012 02:55:47 PM Robert Haas wrote:
On Tue, Mar 27, 2012 at 4:27 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
In the first versions of the patch I did try to have a single point
where to integrate the feature and that didn't work out. If you want to
publish
On 03/26/2012 01:54 PM, Andrew Dunstan wrote:
On 03/26/2012 01:34 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 03/26/2012 01:06 PM, Heikki Linnakangas wrote:
Is it possible this job is inserting and then updating (or deleteing)
the row it just inserted and doing a
Noah Misch n...@leadboat.com writes:
On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
I think the more important question is a policy question: do we want
it to work like this?
The DBA can customize policy by revoking public execute permissions on
pg_catalog.pg_terminate_backend
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 22.03.2012 23:42, Alex wrote:
Okay, at last here's v9, rebased against current master branch.
Some quick comments on this patch:
Heikki, thank you for taking a look at this!
I see a compiler warning:
fe-connect.c: In
On Tue, Mar 27, 2012 at 9:37 AM, Andres Freund and...@2ndquadrant.com wrote:
Not necessarily. One use-case is doing something *before* something happens
like enforcing naming conventions, data types et al during development/schema
migration.
That is definitely a valid use case. The only
On Fri, Mar 16, 2012 at 8:34 PM, Greg Stark st...@mit.edu wrote:
On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis pg...@j-davis.com wrote:
There is a lot of difference between those two. In particular, it looks
like the problem you are seeing is coming from the background writer,
which is not
Robert Haas robertmh...@gmail.com writes:
I am coming more and more strongly to the conclusion that we're going
in the wrong direction here. It seems to me that you're spending an
enormous amount of energy implementing something that goes by the name
COMMAND TRIGGER when what you really want
Robert Haas robertmh...@gmail.com writes:
I actually think that, to really meet all needs here, we may need the
ability to get control in more than one place. For example, one thing
that KaiGai has wanted to do (and I bet Dimitri would live to be able
to do it too, and I'm almost sure that
Excerpts from Fujii Masao's message of mar mar 27 06:40:34 -0300 2012:
Anyway, should I add this patch into the next CF? Or is anyone planning
to commit the patch for 9.2?
I think the correct thing to do here is add to next CF, and if some
committer has enough interest in getting it quickly
Hi,
On Tuesday, March 27, 2012 04:29:58 PM Robert Haas wrote:
On Tue, Mar 27, 2012 at 9:37 AM, Andres Freund and...@2ndquadrant.com
wrote:
Not necessarily. One use-case is doing something *before* something
happens like enforcing naming conventions, data types et al during
On Tue, Mar 27, 2012 at 11:05 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I agree that it's not a very helpful decision, but I'm not the one who
said we wanted command triggers rather than event triggers. :-)
Color me unconvinced about event triggers. That's not answering my use
Peter Geoghegan pe...@2ndquadrant.com writes:
On 22 March 2012 17:19, Tom Lane t...@sss.pgh.pa.us wrote:
Either way, I think we'd be a lot better advised to define a single
hook post_parse_analysis_hook and make the core code responsible
for calling it at the appropriate places, rather than
On tor, 2012-03-22 at 23:42 +0200, Alex wrote:
Okay, at last here's v9, rebased against current master branch.
Attached is a patch on top of your v9 with two small fixes:
- Don't provide a check target in libpq/Makefile if it's not
implemented.
- Use the configured port number for running the
On Tue, Mar 27, 2012 at 11:58 AM, Andres Freund and...@2ndquadrant.com wrote:
I still think the likeliest way towards that is defining some behaviour we
want
regarding
* naming conflict handling
* locking
And then religiously make sure the patch adheres to that. That might need some
On Mon, Mar 26, 2012 at 7:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fine. What do you propose, specifically?
The end of the month is coming up. How about we propose to close the
'fest on April 1st? Anything that's not committable by then goes to
the 9.3 list. If one week seems too short,
On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas robertmh...@gmail.com wrote:
I think the more important question is a policy question: do we want
it to work like this? It seems like a policy question that ought to
be left to the DBA, but we have no policy management framework for
DBAs to
On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina dan...@heroku.com wrote:
On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas robertmh...@gmail.com wrote:
I think the more important question is a policy question: do we want
it to work like this? It seems like a policy question that ought to
be left to
On Tue, Mar 27, 2012 at 1:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar mar 27 14:38:47 -0300 2012:
On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina dan...@heroku.com wrote:
On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas robertmh...@gmail.com
Excerpts from Robert Haas's message of mar mar 27 14:38:47 -0300 2012:
On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina dan...@heroku.com wrote:
On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas robertmh...@gmail.com wrote:
I think the more important question is a policy question: do we want
it
On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Isn't it the case that many web applications run under some common
database user regardless of the underlying webapp user? I wouldn't say
that's an unimportant case. Granted, the webapp user wouldn't have
Robert Haas robertmh...@gmail.com wrote:
Daniel Farina dan...@heroku.com wrote:
Is there a hypothetical DBA that doesn't want a mere-mortal user
to be able to signal one of their own backends to do cancel
query, rollback the transaction, then close the socket? If so,
why?
Setting aside
On Tue, Mar 27, 2012 at 10:48 AM, Daniel Farina dan...@heroku.com wrote:
On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Isn't it the case that many web applications run under some common
database user regardless of the underlying webapp user? I wouldn't say
On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
Well, I guess if you have different people sharing the same
user-ID, you probably wouldn't want that.
As Tom pointed out, if there's another person sharing the user ID
you're using, and you don't trust them, their ability to
On Thu, Mar 22, 2012 at 7:38 PM, Ants Aasma a...@cybertec.at wrote:
On Wed, Mar 21, 2012 at 5:01 PM, Robert Haas robertmh...@gmail.com wrote:
This seems to have bitrotted again. :-(
Can you please rebase again?
Rebased.
I've committed the core of this. I left out the stats collector
Andres Freund and...@anarazel.de wrote:
On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
Well, I guess if you have different people sharing the same
user-ID, you probably wouldn't want that.
As Tom pointed out, if there's another person sharing the user ID
you're using, and
Peter Eisentraut pete...@gmx.net writes:
On tor, 2012-03-22 at 23:42 +0200, Alex wrote:
Okay, at last here's v9, rebased against current master branch.
Attached is a patch on top of your v9 with two small fixes:
- Don't provide a check target in libpq/Makefile if it's not
implemented.
-
On Tue, Mar 27, 2012 at 2:58 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Mar 22, 2012 at 7:38 PM, Ants Aasma a...@cybertec.at wrote:
On Wed, Mar 21, 2012 at 5:01 PM, Robert Haas robertmh...@gmail.com wrote:
This seems to have bitrotted again. :-(
Can you please rebase again?
On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the core of this. I left out the stats collector
stuff, because it's still per-table and I think perhaps we should back
off to just per-database. I changed it so that it does not conflate
wait time with
Peter Geoghegan pe...@2ndquadrant.com writes:
I've attached a patch with the required modifications.
I've committed the core-backend parts of this, just to get them out of
the way. Have yet to look at the pg_stat_statements code itself.
I restored the location field to the ParamCoerceHook
On 27 March 2012 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
I've committed the core-backend parts of this, just to get them out of
the way. Have yet to look at the pg_stat_statements code itself.
Thanks. I'm glad that we have that out of the way.
I ended up choosing not to apply that bit. I
Hi,
On Tuesday, March 27, 2012 07:34:46 PM Robert Haas wrote:
On Tue, Mar 27, 2012 at 11:58 AM, Andres Freund and...@2ndquadrant.com
wrote:
I still think the likeliest way towards that is defining some behaviour
we want regarding
* naming conflict handling
* locking
And then
On Wed, Feb 22, 2012 at 6:53 AM, Greg Smith g...@2ndquadrant.com wrote:
A look back on this now that I'm done with it does raise one large question
though. I added some examples of how to measure timing overhead using psql.
While I like the broken down timing data that this utility provides,
On 03/27/2012 03:14 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de wrote:
On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
Well, I guess if you have different people sharing the same
user-ID, you probably wouldn't want that.
As Tom pointed out, if there's another
On Tue, Mar 27, 2012 at 4:05 PM, Andres Freund and...@2ndquadrant.com wrote:
Looking up oids and such before calling the trigger doesn't seem to be
problematic from my pov. Command triggers are a superuser only facility,
additional information they gain are no problem.
Thinking about that
On Sat, Mar 24, 2012 at 02:22:24AM +0200, Marko Kreen wrote:
Main advantage of including PQgetRow() together with low-level
rowproc API is that it allows de-emphasizing more complex parts of
rowproc API (exceptions, early exit, skipresult, custom error msg).
And drop/undocument them or simply
[ just for the archives' sake ]
Peter Geoghegan pe...@2ndquadrant.com writes:
On 27 March 2012 18:15, Tom Lane t...@sss.pgh.pa.us wrote:
Now, if what it wants to know about is the parameterization status
of the query, things aren't ideal because most of the info is hidden
in parse-callback
Alex a...@commandprompt.com writes:
Peter Eisentraut pete...@gmx.net writes:
Attached is a patch on top of your v9 with two small fixes:
- Don't provide a check target in libpq/Makefile if it's not
implemented.
- Use the configured port number for running the tests (otherwise it
runs
On Tue, Mar 27, 2012 at 1:30 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, that does sort of leave an arguable vulnerability. Should the
same user only be allowed to kill the process from a connection to
the same database?
It might be a reasonable restriction in theory, but I doubt
On Tue, Mar 27, 2012 at 3:22 PM, Ants Aasma a...@cybertec.at wrote:
On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the core of this. I left out the stats collector
stuff, because it's still per-table and I think perhaps we should back
off to just
On Tue, Mar 27, 2012 at 7:58 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the core of this. I left out the stats collector
stuff, because it's still per-table and I think perhaps we should back
off to just per-database. I changed it so that it does not conflate
wait time with
On Tue, Mar 27, 2012 at 8:41 PM, Greg Stark st...@mit.edu wrote:
On Tue, Mar 27, 2012 at 7:58 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the core of this. I left out the stats collector
stuff, because it's still per-table and I think perhaps we should back
off to just
On Wed, Mar 28, 2012 at 12:30 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Fujii Masao's message of mar mar 27 06:40:34 -0300 2012:
Anyway, should I add this patch into the next CF? Or is anyone planning
to commit the patch for 9.2?
I think the correct thing to do here
(2012/03/27 20:32), Thom Brown wrote:
2012/3/26 Shigeru HANADAshigeru.han...@gmail.com:
* pgsql_fdw_v17.patch
- Adds pgsql_fdw as contrib module
* pgsql_fdw_pushdown_v10.patch
- Adds WHERE push down capability to pgsql_fdw
* pgsql_fdw_analyze_v1.patch
- Adds pgsql_fdw_analyze
On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
pg_test_timing utility, to measure clock monotonicity and timing cost.
When I compiled this, I got a compiler warning. Attached patch
silences the warning.
Also I found one trivial problem in the doc of pg_test_timing. The
A user complained on pgsql-performance that SELECT col FROM table
GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
to return tuples from hash-aggregate as they are found when no
aggregate functions are in use. Attached is a first shot at that. The
planner is modified so that
62 matches
Mail list logo
