Re: [HACKERS] Patch review for logging hooks (CF 2012-01)

On Tue, Mar 6, 2012 at 10:37 PM, Tom Lane wrote: > Applied with minor editorialization (mainly just improving the > comments). Thanks and kudos to all the reviewers! regards, Martin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] Failed assertion during recovery of partial WAL file

Encountered the following FailedAssertion while testing database recovery (actually this would be HS) with partial WAL file: LOG: restored log file "00010003" from archive LOG: consistent recovery state reached at 0/3001EEC LOG: record with zero length at 0/3001EEC LOG: redo do

[HACKERS] libpq SSL with non-blocking sockets

I believe I have found a bug in libpq COPY handling with non-blocking SSL connections. The bug manifests itself by dropping the connection in PGputCopyData() with "server closed the connection unexpectedly" message. The connection drop only occurs with nonblocking connections - blocking connections

Re: [HACKERS] libpq SSL with non-blocking sockets

On 06/12/2011 04:22 AM, Robert Haas wrote: > One idea is that we could add outBuffer2/outBufSize2 to struct > pg_conn, or something along those lines with less obviously stupid > naming. Normally those would be unused, but in the special case where > SSL indicates that we must retry the call with

Re: [HACKERS] libpq SSL with non-blocking sockets

On 06/25/2011 12:14 AM, Steve Singer wrote: > I'm not a libpq guru but I've given your patch a look over. > Thanks for the review! I have since simplified the patch to assume that partial SSL writes are disabled -- according to SSL_write(3) this is the default behaviour. Now the SSL retry buffer

[HACKERS] log files and permissions

With logging_collector enabled, all the postgres log files are created with mode 0600. This makes life complicated if users other than "postgres" need to be able to examine the log files as well. Common example of this is when the database runs under "postgres" user and DBA-s have named accounts.

Re: [HACKERS] log files and permissions

Martin Pihlak wrote: > Attached is a patch that adds a GUC "log_file_mode" which allows to specify > the creation mode for the log files. Presently it lacks documentation, which > I'll add if the idea is generally acceptable. > Now it really is attached. regards

Re: [HACKERS] log files and permissions

Tom Lane wrote: > It doesn't appear to me that this helps unless you are willing to make > the containing director(ies) group-readable/executable as well, which is > something we've resisted doing. > The log can be moved outside of data directory by setting "log_directory" to an absolute path. Th

Re: [HACKERS] log files and permissions

Martin Pihlak wrote: > Attached is a patch that adds a GUC "log_file_mode" which allows to specify > the creation mode for the log files. Presently it lacks documentation, which > I'll add if the idea is generally acceptable. > Updated patch attached. regards,

Re: [HACKERS] log files and permissions

Itagaki Takahiro wrote: > I checked "log_file_mode GUC" patch, and found a couple of Windows-specific > and translation issues. Thank you for the review. Attached patch attempts to fix these issues. > * fchmod() is not available on some platforms, including Windows. > fh = fopen(filename, mod

Re: [HACKERS] log files and permissions

Itagaki Takahiro wrote: > I think the patch is almost ready for committer except the following > three issues: > > 2010/7/13 Fujii Masao : >>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777) >> The sticky bit cannot be set via log_file_mode. Is this intentional? Yes -- I don't

Re: [HACKERS] log files and permissions

Tom Lane wrote: > Itagaki Takahiro writes: >> ... >> We should also check the value not to be something like 0699. >> How about checking it with (file_mode & ~0666) != 0 ? >> ... >> I want show_log_file_mode to print the setting value in octal format. > > It seems like a whole lot of lily-gilding

Re: [HACKERS] libpq SSL with non-blocking sockets

On 07/03/2011 05:08 AM, Steve Singer wrote: > Since the original patch was submitted as a WIP patch and this version > wasn't sent until well into the commit fest I am not sure if it > qualifies for a committer during this commitfest or if it needs to wait > until the next one. > If possible I wo

Re: [HACKERS] libpq SSL with non-blocking sockets

On 07/16/2011 12:46 AM, Tom Lane wrote: > I think the direction to move in ought to be to use the existing buffer > as-is, and have pqCheckOutBufferSpace refuse to enlarge the buffer while > we are in "write frozen" state. It should be OK to append data to the > buffer, though, so long as we remem

Re: [HACKERS] libpq SSL with non-blocking sockets

On 07/24/2011 11:33 PM, Tom Lane wrote: > I've applied the simplified fix (just set SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER) > as well as a patch to improve the error reporting situation. > Cool that this turned out to be a one-line fix. Thanks! regards, Martin -- Sent via pgsql-hackers mailing li

Re: [HACKERS] Disable OpenSSL compression

On 11/08/2011 03:59 PM, Albe Laurenz wrote: > If there are concerns about that, maybe a GUC variable like > ssl_compression (defaulting to off) would be a solution. > I'd vote for a libpq connect option instead. Something like sslcompress=yes|no accompanied by PGSSLCOMPRESS environment variable.

Re: [HACKERS] logging in high performance systems.

On 11/24/2011 06:33 PM, Theo Schlossnagle wrote: > I see the next steps being: > 1) agreeing that a problem exists (I know one does, but I suppose > consensus is req'd) +1, high volume logging is also a huge problem here at Skype. Some of the issues that immediately come to mind: - extracting us

Re: [HACKERS] 9.2 Reviewfest - logging hooks patch

On 01/13/2012 05:29 AM, Christopher Maujean wrote: > Patch > > > > In reviewing the referenced patch, we found that it has no developer > documentation and no regression tests. While it compiles and installs, > there is nothin

Re: [HACKERS] Generate call graphs in run-time

On 01/09/2012 10:00 PM, Joel Jacobson wrote: > Because of this I decided to sample data in run-time to get a real-life > picture of the system. > Any functions not being called in productions are not that important to > include in the documentation anyway. FWIW I have a similar problem - with a si

Re: [HACKERS] Patch review for logging hooks (CF 2012-01)

On 01/17/2012 07:35 PM, Marti Raudsepp wrote: > Here's my review for the "logging hooks" patch queued for the 2012-01 > CommitFest by Martin Pihlak. > Thanks for reviewing! > There's a minor whitespace problem. When declaring variables, and the > data type is

Re: [HACKERS] Generate call graphs in run-time

On 01/17/2012 11:13 AM, Joel Jacobson wrote: > Since you only care about the parentfuncid in one level, it looks like > you will only be able to get a total call graph of all possible > function calls, and not each unique call graph per transaction. True, for my purposes (function dependencies and

Re: [HACKERS] Patch review for logging hooks (CF 2012-01)

On 01/18/2012 03:56 AM, Fujii Masao wrote: > or syslog process (if you use syslog). So ISTM that there is no > guarantee that the order of log messages processed by the > hook is same as that of messages written to the log file. For > example, imagine the case where two backends call EmitErrorRepor

Re: [HACKERS] Patch review for logging hooks (CF 2012-01)

On 01/17/2012 11:40 PM, Marti Raudsepp wrote: > It seems you missed a comment, that the current implementation is also > affected by client_min_messages. I think that being affected by > client-specific settings is surprising. I would put the > if(emit_log_hook) inside the existing if(edata->output

[HACKERS] stored procedure stats in collector

Howdy, I'm working on a patch to extend the stats collector to handle stored procedure statistics (call counts, duration etc). The goal is to make this information visible via pg_stat functions/views. The collection would be controllable via "stats_function_level" GUC and will have minimal overhe

Re: [HACKERS] stored procedure stats in collector

Neil Conway wrote: (schemaname, procname, nargs) is still ambiguous in the face of function overloading. Although the presence of procid uniquely identifies each function anyway, if you're going to include the name and argument information, it might be worth including the argument types as well

Re: [HACKERS] stored procedure stats in collector

Tom Lane wrote: I really dislike that approach to deciding which functions to count. The main problem with it is that it will try to count C-language functions that are added after initdb, such as contrib stuff and third-party add-ons like postgis. The percentage overhead for a typical short C f

Re: [HACKERS] stored procedure stats in collector

Howdy, Here's an updated version of the function stats patch. The biggest change is that by default only procedural language functions are counted. The GUC variable stats_function_level now takes 3 values: on, off and all. The latter also counts SQL and C language functions, "on" means only to co

Re: [HACKERS] stored procedure stats in collector

Neil Conway wrote: On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote: The GUC variable stats_function_level now takes 3 values: on, off and all. That seems a confusing set of values. Perhaps "off", "pl", and "all" would be clearer? Makes sense. It appear

Re: [HACKERS] stored procedure stats in collector

It seems that the overhead is unnoticeable if disabled, very visible for lightweight functions and heavy callers. Almost unnoticeable for more compute intensive functions. The very high system times seem odd. Maybe you have a machine with slow gettimeofday()? So it seems (on Ubuntu 7.04). Re

Re: [HACKERS] stored procedure stats in collector

hubert depesz lubaczewski wrote: On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote: That seems a confusing set of values. Perhaps "off", "pl", and "all" would be clearer? I'm curious if you've measured the performance overhead of enabling this functionality. i'm quite worried about "

Re: [HACKERS] What happened to pl/proxy and FDW?

Josh Berkus wrote: > I thought the idea was that we were going to add PL/proxy to 8.5, with > support for the foriegn data wrapper syntax? What happened to that? > Using SQL/MED for defining pl/proxy clusters is still in the TODO list. I hope to do something about it during the next few weeks. H

[HACKERS] fdw validation function vs zero catalog id

It appears that the function for validating generic options to a FDW, SERVER and USER MAPPING is always passed a catalog oid of 0. Whereas it should actually be passed the oid of the catalog that the options apply to. Attached patch fixes the issue by passing the proper catalog id from transformGe

Re: [HACKERS] fdw validation function vs zero catalog id

Tom Lane wrote: > According to what? I can't find any documentation whatsoever on what > arguments that function is supposed to get. > > regards, tom lane > According to http://www.postgresql.org/docs/8.4/static/sql-createforeigndatawrapper.html: "The validator function m

Re: [HACKERS] fdw validation function vs zero catalog id

Tom Lane wrote: >> "The validator function must take two arguments: one of type text[], which >> will contain the array of options as stored in the system catalogs, and one >> of type oid, which will be the OID of the system catalog containing the >> options, or zero if the context is not known." >

Re: [HACKERS] fdw validation function vs zero catalog id

I wrote: > The validator is run for the generic options specified to CREATE/ALTER FDW, > SERVER and USER MAPPING (+ possible future SQL/MED objects). In this case the > catalog is always known. Also we can assume that the catalog is known, if a > user > runs the validator directly. So yes, AFAICS

[HACKERS] plan invalidation vs stored procedures

Howdy, What is the status of plan invalidation vs stored procedures? From the initial design discussion I understand that function change handling was postponed to "some time in the future". Is anybody already working on that or maybe some ideas of how to implement this? The business case for the

Re: [HACKERS] plan invalidation vs stored procedures

Pavel Stehule wrote: > Hello > > try version 8.3. There lot of dependencies are solved. > Yes, 8.3 was the version I was testing with. Same results on the HEAD: $ psql -e -f test.sql select version(); version

Re: [HACKERS] plan invalidation vs stored procedures

>> DROP FUNCTION >> create function foo() returns integer as $$ begin return 2; end; $$ language >> plpgsql; >> CREATE FUNCTION >> execute c1; >> psql:test.sql:11: ERROR: cache lookup failed for function 36555 > > This is simply a bad, wrong, stupid way to do it. Why do you not use > CREATE OR

[HACKERS] Patch: plan invalidation vs stored procedures

This is a followup for thread "plan invalidation vs stored procedures". The background is that it is impossible to change function return type without dropping and recreating. Unfortunately dropping a function ruins all of the prepared statements that reference that function (including other funct

Re: [HACKERS] Patch: plan invalidation vs stored procedures

Tom Lane wrote: > Martin Pihlak <[EMAIL PROTECTED]> writes: >> Changing statement result type is also currently prohibited in >> StorePreparedStatement. There maybe good reasons for this, > > How about "the SQL spec says so"? > > Admittedly, it's a

Re: [HACKERS] Patch: plan invalidation vs stored procedures

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

[HACKERS] reducing statistics write overhead

Howdy, The statistics collector currently dumps the stats file at every 500ms. This is a major problem if the file becomes large -- occasionally we've been forced to disable stats collection to cope with it. Another issue is that while the file is frequently written, it is seldom read. Typically

Re: [HACKERS] reducing statistics write overhead

Tom Lane wrote: > Martin Pihlak <[EMAIL PROTECTED]> writes: >> So, as a simple optimization I am proposing that the file should be >> only written when some backend requests statistics. This would >> significantly reduce the undesired write traffic at the cost of >

Re: [HACKERS] reducing statistics write overhead

Magnus Hagander wrote: > I wrote a patch for this some time back, that was actually applied. > Turns out it didn't work, and I ran out of time to fix it, so it was > backed out again. And then I forgot about it :-) If you look through the > cvs history of pgstat you should be able to find it - mayb

Re: [HACKERS] reducing statistics write overhead

Tom Lane wrote: > Timestamp within the file is certainly better than trying to rely on > filesystem timestamps. I doubt 1 sec resolution is good enough, and > I'd also be worried about issues like clock skew between the > postmaster's time and the filesystem's time. > Attached is a patch which a

Re: [HACKERS] reducing statistics write overhead

Tom Lane wrote: > Hmm. With the timestamp in the file, ISTM that we could put all the > intelligence on the reader side. Reader checks file, sends message if ... snip ... > remember the file timestamp it last wrote out. There are various ways > you could design it but what comes to mind here is

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera wrote: >> Attached is a patch that implements the described signalling. > > Are we keeping the idea that the reader sends a stat message when it > needs to read stats? What about the lossiness of the transport? > As the message is resent in the wait loop, the collector should rec

[HACKERS] per-table autovacuum configuration

There is an autovacuum TODO item suggesting pg_autovacuum to be replaced with pg_class.reloptions. Original discussion at: http://archives.postgresql.org/pgsql-hackers/2007-02/msg01440.php A lot of time has passed -- is the proposal still valid or are there any new thoughts on the matter? Perhaps

Re: [HACKERS] per-table autovacuum configuration

Alvaro Herrera wrote: >> any new thoughts on the matter? Perhaps someone is already working >> on it? > > It is still a wanted feature, but a couple of people have offered > patches and I'm waiting for them ... > Aha, good. I was considering taking a stab at it, but under the circumstances will

Re: [HACKERS] contrib/pg_stat_statements

ITAGAKI Takahiro wrote: > I'd like to submit pg_stat_statements contrib module, that counts up > incoming statements in shared memory and summarizes the result as a view. > It is just a statements-version of pg_stat_user_functions. > Nice work! There is one feature I'd like to request -- we need t

Re: [HACKERS] Withdraw PL/Proxy from commitfest

Hannu Krosing wrote: > In my brief reading of SQL-MED spec I could only find info on defining > FOREIGN SERVER and FOREIGN-DATA WRAPPER and nowhere in these could one > define connection parameters like username and password. It is cleverly hidden. The CREATE SERVER and CREATE USER MAPPING take g

Re: [HACKERS] Withdraw PL/Proxy from commitfest

Hannu Krosing wrote: >> It is cleverly hidden. The CREATE SERVER and CREATE USER MAPPING take >> generic options (list of key/value pairs). These can be used for >> defining the actual connection to the remote server. > > Are you sure this is how it is intended to be done ? > Yes. > In pl/proxy

Re: [HACKERS] Withdraw PL/Proxy from commitfest

David Fetter wrote: > DBI's DBD::Excel > is a more extreme example of this kind of thing. You can get connect > strings that look like this: > > my $hDb = DBI->connect( > "DBI:Excel:file=dbdtest.xls", > undef, > undef, > {

[HACKERS] SQL/MED compatible connection manager

Howdy, Currently pl/proxy, dblink, DBI-link etc. each have their own remote connection info management infrastructure (or none at all). It would certainly help if they could use a common connection database -- with access control, pg_dump support, etc. There have been hints that a SQL/MED compatib

Re: [HACKERS] SQL/MED compatible connection manager

> Per SQL:2008, there are no expected changes to SQL/MED from SQL:2003. > As such, two weeks ago, I completed a full review of SQL/MED and am > planning to fully implement it for 8.5. Currently, I'm working on a > proof of concept and have created a SQL/MED access method (sqlmed) as > well as star

Re: [HACKERS] contrib/pg_stat_statements

ITAGAKI Takahiro wrote: > It might be possbile to add a queryText field into QueryDesc > and all of the codes using QueryDesc initialize the field with > their own query texts, but it requires modifications in many > different modules and copying query text might be needed. > I don't want to do it

Re: [HACKERS] SQL/MED compatible connection manager

Chris Browne wrote: > Slony-I does some vaguely similar stuff in its handling of "connection > paths"; here's the schema: > > create table @[EMAIL PROTECTED] ( > pa_server int4, > pa_client int4, > pa_conninfo text

Re: [HACKERS] SQL/MED compatible connection manager

> I have put together a draft that describes a possible implementation: > http://wiki.postgresql.org/wiki/SqlMedConnectionManager > I'll update this with an experimental patch. This implements: * System catalogs for FDW, SERVER and USER MAPPING * regserver data type for servers (convert from text

Re: [HACKERS] contrib/pg_stat_statements

ITAGAKI Takahiro wrote: >> But is the idea of extending QueryDesc generally acceptable? Is it OK >> to make a copy of the query string? > > The only thing I'm worried about is that QueryDesc lives longer than > its queryText. Can I assume it never occurs? > I just finished validating this -- it

Re: [HACKERS] SQL/MED compatible connection manager

Here is an updated patch. I'm also submitting this to November Commitfest - I believe it is possible to get this into shape for 8.4. This is still a WIP but I really need a review before moving on with the syntax, pg_dump support etc. Currently the system catalogs and user accessible connection lo

Re: [HACKERS] auto_explain contrib moudle

Jeff Davis wrote: > It still needs to be merged with HEAD. > ExecutorRun function signature has changed to return void. Other than that it seems OK. I'll add a few additional notes: One thing that I noticed was that tab completion queries are also explained if "explain.log_min_duration" is set to

Re: [HACKERS] SQL/MED compatible connection manager

Attached is next revision of the connection manager, this is now nearly feature complete -- the syntax is there, privileges are implemented. Should apply cleanly to HEAD and pass regression. There are some usage examples at: http://wiki.postgresql.org/wiki/SqlMedConnectionManager#Examples Some iss

Re: [HACKERS] auto_explain contrib moudle

Jeff Davis wrote: > It's logged at the LOG level, just like log_min_duration_statement, and > seems to have the same behavior. What do you think it should do > differently? > There was actually a patch to disable the psql notices, but there were some concerns and I think it was removed: http://arc

Re: [HACKERS] auto_explain contrib moudle

Jeff Davis wrote: > I still don't understand why this psql patch is desirable. Who sets > their client_min_messages to LOG in psql? And if they do, why would they > expect different behavior that they always got from the already-existing > GUC log_min_duration_statement? > I know a few ;) In my en

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > Looks very good, please continue. > Thanks, will do :) > On your wiki page, you have this example: > > CREATE SERVER userdb TYPE 'plproxy_cluster' > FOREIGN DATA WRAPPER plproxy > OPTIONS ( > server='dbname=userdb_p0 host=127.0.0.1 port=6000', >

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > Attached is my current patch after surgery. I have mainly worked on > making naming better and more consistent. > Thanks. > Problem: You have implemented foreign-data wrappers and foreign servers > as schema-qualified objects, but the standard has them outside schemas,

Re: [HACKERS] psql commands for SQL/MED

Alvaro Herrera wrote: >> What about \dM prefix, M standing for MED? It seems free in my 8.3 psql >> here. > > So \dMf for foreign servers, \dMu for user mappings, etc? That seems good. > I find the mixed case commands somewhat inconvinient -- too easy to make typing mistakes, also slow to ente

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > Now the way I read the FDWs you provide (default and pgsql), you are > creating your own API for initialization and options validation that is > not in the standard. That would appear to contradict the idea of a > standard interface. I understand that option validation i

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: >> worry too much about the function pointers getting stale due to library >> changes and reloads, as that requires some deliberate actions as a >> superuser. > > I never understood that reload business complete anyway. If you think > there are issues at run time, they sho

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > I have committed this without the functions. I have some thoughts on > what to do about that, but right now I'm exhausted. ;-) > Great news :) Thanks a lot for your support and contributions! regards, Martin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] [COMMITTERS] pgsql: SQL/MED catalog manipulation facilities This doesn't do any

Heikki Linnakangas wrote: > The callers of transformGenericOptions-function in foreigncmds.c use > OidIsValid to check the return value of transformGenericOptions, but it > returns an array, not an Oid. I committed a fix for that, we'll see if > it heals the buildfarm. > Thanks for that. There wa

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > Well, what this function essentially does is a text transformation of the > options, something like this: > > peter=# SELECT array_to_string(fdwoptions || srvoptions || umoptions, ' ') > FROM pg_foreign_data_wrapper fdw, pg_foreign_server srv, pg_user_mappings um > WHE

Re: [HACKERS] dblink vs SQL/MED

Joe Conway wrote: >> Two specific questions on this approach: >> 1. This implies that the exact same dblink_connstr_check() is performed >>on a predefined foreign server and user mapping as a raw connstr -- >>is this desireable? I'm not entirely clear on the intended purpose >>and use o

Re: [HACKERS] dblink vs SQL/MED - security and implementation details

Joe Conway wrote: > I'm mainly concerned about re-opening security holes that we spent a lot > of time debating and subsequently closing. I suspect if we assume that > any FDW-derived connect string can bypass the checks we put in place, we > will regret it later. But I'm open to arguments on both

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > Martin Pihlak wrote: >>> I would call it something like >>> >>> pg_postgresql_fdw_options_string(server, user) returns text >> >> Hmm, it is probably a good idea to avoid the fdw abbreviation -- the term >> "foreign dat

Re: [HACKERS] dblink vs SQL/MED - security and implementation details

Tom Lane wrote: > Peter Eisentraut writes: >> I think you want some permission checking on fdtest then, right? > > What about the permissions on the system catalogs themselves? > AFAICT, the pg_user_mappings view will expose user passwords to > the "owner" of the foreign server, which doesn't see

Re: [HACKERS] dblink vs SQL/MED - security and implementation details

Peter Eisentraut wrote: > On Tuesday 06 January 2009 05:54:14 Joe Conway wrote: >> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest'); >> dblink_connect >> >> OK >> (1 row) > > I think you want some permission checking on fdtest then, right? > The proposed "conne

Re: [HACKERS] SQL/MED dummy vs postgresql wrapper

Peter Eisentraut wrote: > Eventually, the postgresql_fdw library should contain an implementation that > actually connects to a PostgreSQL database and does useful things (dblink > replacement, basically). Right now, we are proposing to use it as connection > information storage. But I think

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera wrote: > Tom Lane escribió: > >> (In fact, maybe this patch ought to include some sort of maximum update >> rate tunable? The worst case behavior could actually be WORSE than now.) > > Some sort of "if stats were requested in the last 500 ms, just tell the > requester to read the

Re: [HACKERS] reducing statistics write overhead

Tom Lane wrote: > I never understood why autovacuum should need a particularly short fuse > on the stats file age to start with. If the launcher is launching > multiple workers into the same database with only a few milliseconds > between them, isn't the launcher pretty broken anyhow? ISTM that s

Re: [HACKERS] FWD: Re: Updated backslash consistency patch

Bruce Momjian wrote: > Bruce Momjian wrote: >> I know we don't like the current behavior, but I think we need to make >> them consistent first for easy testing and so when we change it, it will >> remain consistent. >> >> I will work on a consensus patch soon for the new behavior. > The "\dXU *.*

Re: [HACKERS] reducing statistics write overhead

I wrote: > I was thinking that the launcher should only request fresh stats at wakeup, > the workers could then reuse that file. This could be implemented by calling > pgstat_clear_snapshot only at launcher wakeup and setting max stats age to > to autovacuum_naptime for the workers. > Attached is

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera wrote: > You missed putting back the BUG comment that used to be there about > this. > This was deliberate, I did mention the condition in the comment at the beginning of the file. This actually makes it a feature :) Seriously though, do you think that this is still a problem? Giv

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera wrote: > I agree that pgstats is not ideal (we've said this from the very > beginning), but I doubt that updating pg_class is the answer; you'd be > generating thousands of dead tuples there. > But we already do update pg_class after vacuum -- in vac_update_relstats(). Hmm, that pe

Re: [HACKERS] Inappropriate failure conditions in foreign_data regression test

> By chance I noticed that the foreign_data regression test fails if run > in an installation where "bob" is a live user. It appears to be > assuming that half a dozen other fairly common names don't belong to > real users, either. Could we make this a little less fragile? Maybe Attached is a p

Re: [HACKERS] stored procedure stats in collector

Howdy, > Did you post an updated patch to HEAD? > No, but I guess its just about time. Hopefully I'll have something to show next week. regards, Martin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpre

Re: [HACKERS] some broken on pg_stat_user_functions

Pavel Stehule wrote: > then documentation is probably little bit wrong (needs some additional > comment) . This text specifies using option 'all' for sql functions. > Attached documentation patch attempts to clarify this. regards, Martin diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/conf

[HACKERS] psql \d commands and information_schema

Attached is a patch that modifies psql \dX commands to treat objects in information_schema as "system objects". This prevents them from showing up in \dX *.* and polluting the user objects list. This is especially annoying if user objects are in multiple schemas, and one wants to get a quick overvi

Re: [HACKERS] SQL/MED compatible connection manager

Peter Eisentraut wrote: > I have been thinking about this for a great while now. I am not yet > comfortable with how we manage the access rights here. We have > restricted access to the user mappings catalog to hide passwords, but it > is not entirely clear why a password must be stored in a user

Re: [HACKERS] psql \d commands and information_schema

Bruce Momjian wrote: > I have applied a simplified version of your patch, attached, that adds > just a "AND <>" line to the query; I was a little concerned that IN > might affect performance, and the macros seemed kind of complicated. > Thanks. > Also, since my patch this morning any pattern w

Re: [HACKERS] psql \d commands and information_schema

Tom Lane wrote: > I don't find this to be a pressing problem. If the user has lots of > schemas, they probably have lots of objects too, and are unlikely to > need such a thing. Current behaviour makes it impossible to get a quick overview of all the user defined objects. And it doesn't really ma

Re: [HACKERS] psql \d commands and information_schema

Tom Lane wrote: > Well, if they're all in your search_path then plain old \df will do > fine. If they're not in your search path then I think it gets pretty > questionable whether they're "user defined" in a real sense. It seems > more likely that you've got a pile of modules loaded, and which of

Re: [HACKERS] Non-blocking communication between a frontend and a backend (pqcomm)

Fujii Masao wrote: > http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php > > In line with Robert's suggestion, I submit non-blocking pqcomm patch > as a self-contained one. > Here's my initial review of the non-blocking pqcomm patch. The patch applies cleanly and passes regression.