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 CHECK_FOR_INTE
On Mon, Mar 26, 2012 at 5:11 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Mon, Mar 26, 2012 at 6:15 PM, Tom Lane 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 original plan was dependent on adding the st
On Tue, Mar 27, 2012 at 12:39 AM, Tom Lane wrote:
> Thom Brown 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 looking at stuff, but I think
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 c
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 th
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 \
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 plann
On Mon, Mar 26, 2012 at 11:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander wrote:
s/segment/file/g?
>
>>> We're already using "file" to mean something different *internally*,
>>> don't we? And since pg_controldata shows fairly internal inform
On Thu, Jan 26, 2012 at 11:48 PM, Robert Haas wrote:
> On Tue, Jan 24, 2012 at 4:39 AM, Thomas Ogrisegg
> 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
>> backup file is to be sent to stdout.
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
>> re
2012/3/26 Shigeru HANADA :
> (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 deparser and enhanced
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
On Tue, Mar 27, 2012 at 3:22 AM, Hitoshi Harada 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 how to serialize/d
On Tue, Mar 27, 2012 at 4:27 AM, Dimitri Fontaine
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
> specialized code spre
On Tue, Mar 27, 2012 at 11:04, Noah Misch 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 have no poli
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 sho
On Tue, Mar 27, 2012 at 02:58:26PM +0200, Magnus Hagander wrote:
> On Tue, Mar 27, 2012 at 11:04, Noah Misch 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
On Tuesday, March 27, 2012 02:55:47 PM Robert Haas wrote:
> On Tue, Mar 27, 2012 at 4:27 AM, Dimitri Fontaine
>
> 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
On 03/26/2012 01:54 PM, Andrew Dunstan wrote:
On 03/26/2012 01:34 PM, Tom Lane wrote:
Andrew Dunstan 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 large number of such
in
Noah Misch 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 and interpo
Heikki Linnakangas 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 function ‘conninfo_parse’:
> fe-co
On Tue, Mar 27, 2012 at 9:37 AM, Andres Freund 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 reason why we don't
have
On Fri, Mar 16, 2012 at 8:34 PM, Greg Stark wrote:
> On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis 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 running during initdb.
>
Robert Haas 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 is an EVENT TRIGGE
Robert Haas 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 Dan Farina would lik
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
wrote:
> > Not necessarily. One use-case is doing something *before* something
> > happens like enforcing naming conventions, data types et al during
> > development/schema migration.
>
On Tue, Mar 27, 2012 at 11:05 AM, Dimitri Fontaine
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
> cases.
Could we get
Peter Geoghegan writes:
>> On 22 March 2012 17:19, Tom Lane 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 supposing that
>>> the contri
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 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
> refactoring of exist
On Mon, Mar 26, 2012 at 7:39 PM, Tom Lane 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, how about 2 we
On Mon, Mar 26, 2012 at 4:53 PM, 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 do or
On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina wrote:
> On Mon, Mar 26, 2012 at 4:53 PM, 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
On Tue, Mar 27, 2012 at 1:46 PM, Alvaro Herrera
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 wrote:
>> > On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
>> >> I think the more important question is a policy
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 wrote:
> > On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
> >> I think the more important question is a policy question: do we want
> >> it to work like this? It seems li
On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
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
> permission to run arbitrary
Robert Haas wrote:
> Daniel Farina 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 possible bugs in the mechanis
On Tue, Mar 27, 2012 at 10:48 AM, Daniel Farina wrote:
> On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
> 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. Grant
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 abili
On Thu, Mar 22, 2012 at 7:38 PM, Ants Aasma wrote:
> On Wed, Mar 21, 2012 at 5:01 PM, Robert Haas 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
stuff, because it's still per-tabl
Andres Freund 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 you d
Peter Eisentraut 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.
>
> - Use t
On Tue, Mar 27, 2012 at 2:58 PM, Robert Haas wrote:
> On Thu, Mar 22, 2012 at 7:38 PM, Ants Aasma wrote:
>> On Wed, Mar 21, 2012 at 5:01 PM, Robert Haas wrote:
>>> This seems to have bitrotted again. :-(
>>>
>>> Can you please rebase again?
>>
>> Rebased.
>
> I've committed the core of this. I
On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas 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 I/O time. Maybe t
Peter Geoghegan 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 signature, but
> the re
On 27 March 2012 20:26, Tom Lane 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 remain of the op
Hi,
On Tuesday, March 27, 2012 07:34:46 PM Robert Haas wrote:
> On Tue, Mar 27, 2012 at 11:58 AM, Andres Freund
wrote:
> > I still think the likeliest way towards that is defining some behaviour
> > we want regarding
> > * naming conflict handling
> > * locking
> >
> > And then religiously make
On Wed, Feb 22, 2012 at 6:53 AM, Greg Smith 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, I'm
> not sure whe
On 03/27/2012 03:14 PM, Kevin Grittner wrote:
Andres Freund 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 us
On Tue, Mar 27, 2012 at 4:05 PM, Andres Freund 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 I think we
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 simp
[ just for the archives' sake ]
Peter Geoghegan writes:
> On 27 March 2012 18:15, Tom Lane 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 fields that aren't of globally expo
Alex writes:
> Peter Eisentraut 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 against my system instal
On Tue, Mar 27, 2012 at 1:30 PM, Andrew Dunstan 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 it's much of
On Tue, Mar 27, 2012 at 3:22 PM, Ants Aasma wrote:
> On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas 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
On Tue, Mar 27, 2012 at 7:58 PM, Robert Haas 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 I/O time. Maybe t
On Tue, Mar 27, 2012 at 8:41 PM, Greg Stark wrote:
> On Tue, Mar 27, 2012 at 7:58 PM, Robert Haas 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
On Wed, Mar 28, 2012 at 12:30 AM, Alvaro Herrera
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 is add to next CF
(2012/03/27 20:32), Thom Brown wrote:
> 2012/3/26 Shigeru HANADA:
>> * 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 function for u
On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas 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
patch fixes that.
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 wh
Hi,
i was trying to create triggers that redirect INSERT/UPDATE/DELETE
actions from parent to childs, but found that UPDATE/DELETE doesn't
get redirected. Actually, the triggers BEFORE UPDATE and BEFORE DELETE
aren't even fired.
I haven't tried with AFTER triggers to see if they are fired but i
t
63 matches
Mail list logo
