Re: [HACKERS] too much pgbench init output

On 6.1.2013 05:07, Tatsuo Ishii wrote: >> On 6.1.2013 03:03, Tatsuo Ishii wrote: >>> As a committer, I have looked into the patch. I noticed two things: >>> >>> 1) In the help you put '-q' option into "Common options" section. I >>> think this should be moved to "Initialization options" section bec

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote: 2013-01-05 05:58 keltezéssel, Amit kapila írta: > On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: >> Hi, >> I am reviewing your patch. > Thank you very much. > >> Yes, you are right adding a new LWLock will avoid the u

Re: [HACKERS] too much pgbench init output

> On 6.1.2013 03:03, Tatsuo Ishii wrote: >> As a committer, I have looked into the patch. I noticed two things: >> >> 1) In the help you put '-q' option into "Common options" section. I >> think this should be moved to "Initialization options" section because >> the option is only applied while in

Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

On 3.1.2013 20:33, Magnus Hagander wrote: > On Thu, Jan 3, 2013 at 8:31 PM, Tomas Vondra wrote: >> On 3.1.2013 18:47, Heikki Linnakangas wrote: >>> How about creating the new directory as a direct subdir of $PGDATA, >>> rather than buried in global? "global" is supposed to contain data >>> related

Re: [HACKERS] PATCH: optimized DROP of multiple tables within a transaction

On 4.1.2013 17:42, Robert Haas wrote: > On Mon, Dec 31, 2012 at 11:51 AM, Tomas Vondra wrote: >> I thought I followed the conding style - which guidelines have I broken? > > + /* If there are no non-local relations, then we're done. Release the > memory > + * and return. */ > > Multi-l

Re: [HACKERS] too much pgbench init output

On 6.1.2013 03:03, Tatsuo Ishii wrote: > As a committer, I have looked into the patch. I noticed two things: > > 1) In the help you put '-q' option into "Common options" section. I > think this should be moved to "Initialization options" section because > the option is only applied while initializ

[HACKERS] question: foreign key constraints and AccessExclusive locks

When adding a foreign key constraint on tableA which references tableB, why is an AccessExclusive lock on tableB necessary? Wouldn't a lock that prevents writes be sufficient, or does PostgreSQL have to modify *both* tables in some fashion? I'm using PostgreSQL 8.4 on Linux. -- Jon -- Sent via

Re: [HACKERS] too much pgbench init output

> On 19.12.2012 06:30, Jeevan Chalke wrote: >> >> >> >> On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra > > wrote: >> >> Hi, >> >> attached is a new version of the patch that >> >> (a) converts the 'log_step_seconds' variable to a constant (and does >>

[HACKERS] dynamic SQL - possible performance regression in 9.2

On Wednesday, January 2, 2013, Tom Lane wrote: > Jeff Janes writes: > > Using a RULE-based partitioning instead with row by row insertion, the > > plancache changes slowed it down by 300%, and this patch doesn't change > > that. But that seems to be down to the insertion getting planned > > rep

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

Jeff Janes writes: > [moved to hackers] > On Wednesday, December 5, 2012, Tom Lane wrote: >> Hm. To tell you the truth, in October I'd completely forgotten about >> the January patch, and was thinking that the 1/1 cost had a lot >> of history behind it. But if we never shipped it before 9.2

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

On 21 December 2012 14:08, Robert Haas wrote: > I'm sure it's possible; I don't *think* it's terribly easy. I'm inclined to agree that this isn't a terribly pressing issue. Certainly, the need to introduce a bunch of new infrastructure to detect this case seems hard to justify. -- Peter Geogheg

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

Robert, > I'm sure it's possible; I don't *think* it's terribly easy. The > usual > algorithm for cycle detection is to have each node send to the next > node the path that the data has taken. But, there's no unique > identifier for each slave that I know of - you could use IP address, > but tha

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > But those tables are filled only when we execute COMMENT ON statement... > then your idea is create a 'null' comment every time we create a single > object... is it? Yes, and have the actual 'description' field (as it's variable) at the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc

Simon Riggs writes: > On 4 January 2013 22:42, Tom Lane wrote: >> Invent a "one-shot" variant of CachedPlans for better performance. > Just a moment of reflection here but I did already invent a "one-shot" > plan concept in a patch submission to 9.2, called exactly that, which > enables a variet

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander wrote: > So, it turns out the reason I got no feedback on this tool, was that I > forgot both to email about and to actually push the code to github :O > So this is actually code that's almost half a year old and that I was > supposed to submit for

Re: [HACKERS] bad examples in pg_dump README

On Sat, Jan 5, 2013 at 7:34 AM, Magnus Hagander wrote: > On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt wrote: > Do we need to keep it at all, really? Certainly the introductory part > is covered in the main documentation already... Pretty much. (I did find note #2 mildly interesting.) > I be

Re: [HACKERS] enhanced error fields

2013/1/5 Peter Geoghegan : > On 5 January 2013 16:56, Pavel Stehule wrote: >>> It seems that we're in agreement, then. I'll prepare a version of the >>> patch very similar to the one I previously posted, but with some >>> caveats about how reliably the values can be used. I think that that >>> sho

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Stephen Frost wrote: > > * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > > * also we discuss about create two new catalogs, one local and another > > shared (like pg_description and pg_shdescription) to track creation times > > of all database objects. > > Creating a separate catalo

Re: [HACKERS] enhanced error fields

On 5 January 2013 16:56, Pavel Stehule wrote: >> It seems that we're in agreement, then. I'll prepare a version of the >> patch very similar to the one I previously posted, but with some >> caveats about how reliably the values can be used. I think that that >> should be fine. > > is there agreeme

Re: [HACKERS] git author vs committer

On Thu, Sep 13, 2012 at 9:00 AM, Magnus Hagander wrote: > On Thu, Sep 13, 2012 at 5:22 AM, Peter Eisentraut wrote: >> On Wed, 2012-09-12 at 19:13 +0200, Magnus Hagander wrote: >>> Just to be clear, what you're saying is we want to change the policy >>> that says "committer must be on list of appr

Re: [HACKERS] Reporting hba lines

On Fri, Jun 29, 2012 at 4:39 PM, Tom Lane wrote: > Magnus Hagander writes: >> Turned out to be a bit more work than I thought, since the current >> parser reads pg_hba byte by byte, and not line by line. So I had to >> change that. See attached, seems reasonable? > > A couple of comments: > > * I

Re: [HACKERS] enhanced error fields

2013/1/4 Peter Geoghegan : > On 4 January 2013 18:07, Tom Lane wrote: >> Exactly. To my mind, the *entire* point of this patch is to remove the >> need for people to try to dig information out of potentially-localized >> message strings. It's not clear to me that we have to strain to provide >>

Re: [HACKERS] enhanced error fields

Hello 2013/1/4 Robert Haas : > On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan > wrote: >> Now, as to the question of whether we need to make sure that >> everything is always fully qualified - I respectfully disagree with >> Stephen, and maintain my position set out in the last round of >> fee

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

2013-01-05 16:58 keltezéssel, Magnus Hagander írta: On Sat, Jan 5, 2013 at 3:41 PM, Magnus Hagander wrote: On Thu, Jan 3, 2013 at 1:33 PM, Boszormenyi Zoltan wrote: 2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta: 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta: 2013-01-02 10:12

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > * also we discuss about create two new catalogs, one local and another > shared (like pg_description and pg_shdescription) to track creation times > of all database objects. Creating a separate catalog (or two) every time we want to trac

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

On Sat, Jan 5, 2013 at 3:41 PM, Magnus Hagander wrote: > On Thu, Jan 3, 2013 at 1:33 PM, Boszormenyi Zoltan wrote: >> 2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta: >> >> 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta: >> >> 2013-01-02 10:12 keltezéssel, Magnus Hagander írta: >> At

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Fri, Jan 4, 2013 at 4:07 PM, Peter Eisentraut wrote: > On 1/3/13 3:26 PM, Robert Haas wrote: > > It's true, as we've often > > said here, that leveraging the OS facilities means that we get the > > benefit of improving OS facilities "for free" - but it also means that > > we never exceed what

Re: [HACKERS] [PATCH] Make pg_basebackup configure and start standby [Review]

On Thu, Jan 3, 2013 at 1:33 PM, Boszormenyi Zoltan wrote: > 2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta: > > 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta: > > 2013-01-02 10:12 keltezéssel, Magnus Hagander írta: > Attached is the quotes-v2 patch, the function is renamed and > the

Re: [HACKERS] bad examples in pg_dump README

On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt wrote: > The ./src/bin/pg_dump README contains several inoperable examples. > First, this suggestion: > > | or to list tables: > | > | pg_restore --table | less > > seems bogus, i.e. the --table option requires an argument specifing > which

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote: > On 1/3/13 12:30 PM, Robert Haas wrote: >> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander wrote: >>> Any particular reason? It goes pretty tightly together with >>> pg_receivexlog, which is why I'd prefer putting it alongside that one. >>

[HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Sat, Jan 05, 2013 at 08:05:11AM +0100, Boszormenyi Zoltan wrote: > 2013-01-05 05:58 keltez?ssel, Amit kapila ?rta: >> On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: >>> In create_conf_lock_file(): >> >>> Can't we add a new LWLock and use it as a critical section instead >>> of wa

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

2013-01-05 05:58 keltezéssel, Amit kapila írta: On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: Hi, I am reviewing your patch. Thank you very much. Since you are using a constant string, it would be a little faster to use "sizeof(string)-1" as it can be computed at compile-time