[HACKERS] dynamic SQL - possible performance regression in 9.2

Hello I rechecked performance of dynamic SQL and it is significantly slower in 9.2 than 9.1 -- 9.1 postgres=# create or replace function test() returns void as $$ begin for i in 1..100 loop execute 'select 1'; end loop; end $$ language plpgsql; CREATE FUNCTION postgres=# \timing Timing is on.

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

This information could be extremely useful for forensics, debugging, ETL processes (many of which create tables as part of their processes), etc. I'd say "moderately useful" at best. Quite a number of things could make the creation dates misleading or not distinctive (think partition replac

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > To mention just one problem, are we going to add nonstandard, > non-backwards-compatible syntax to every single kind of CREATE to allow > pg_dump to preserve the creation dates? Perhaps 'ALTER' would be a better place to put it, but concerns around how to m

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

Stephen Frost writes: > * Josh Berkus (j...@agliodbs.com) wrote: >> On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote: >>> This proposal is about add a column "datcreated" on "pg_database" to store >>> the "timestamp" of the database creation. >> I agree that it would be useful. However, if we'

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

Greg Stark writes: > On Wed, Dec 26, 2012 at 11:47 PM, Greg Smith wrote: >> It would be nice if this were just something like a memory issue on this >> system. That I'm getting the same very odd value every time--this refcount >> of 1073741824--makes it seem less random than I expect from bad me

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

* Josh Berkus (j...@agliodbs.com) wrote: > On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote: > >This proposal is about add a column "datcreated" on "pg_database" to store > >the "timestamp" of the database creation. > > I agree that it would be useful. However, if we're going to get > into crea

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

On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote: Hi all, This proposal is about add a column "datcreated" on "pg_database" to store the "timestamp" of the database creation. I agree that it would be useful. However, if we're going to get into created dates, we should at least consider add

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

Hi all, This proposal is about add a column "datcreated" on "pg_database" to store the "timestamp" of the database creation. A couple weeks ago I had a trouble with a PostgreSQL instance, actually our ERP had some strange behaviors with some data loss, but I searched for ERRORs in log files (OS a

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On Wed, Dec 26, 2012 at 11:47 PM, Greg Smith wrote: > It would be nice if this were just something like a memory issue on this > system. That I'm getting the same very odd value every time--this refcount > of 1073741824--makes it seem less random than I expect from bad memory. > Once I get a few

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On 12/26/12 5:28 PM, Greg Stark wrote: Did you ever say what kind of hardware it was? This is the local reference count so I can't see how it could be a race condition or anything like that but it sure smells a bit like one. Agreed, that smell is the reason I'm proceeding so far like this is an

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On 12/26/12 5:40 PM, Greg Stark wrote: Also, do you have the buffer id of the broken buffer? I wonder if it's not just any buffer but always the same same buffer even if it's a different block in that buffer. I just added something looking for that. Before I got to that I found another crash:

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On Wed, Dec 26, 2012 at 6:33 PM, Tom Lane wrote: > Yeah, that destroys my theory that there's something broken about index > management specifically. Now we're looking for something that can > affect any buffer's refcount, which more than likely means it has > nothing to do with the buffer's cont

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On Wed, Dec 26, 2012 at 6:33 PM, Tom Lane wrote: > Yeah, that destroys my theory that there's something broken about index > management specifically. Now we're looking for something that can > affect any buffer's refcount, which more than likely means it has > nothing to do with the buffer's cont

Re: [HACKERS] Feature Request: pg_replication_master()

There already are two ways to promote a server out of recovery. One is creating the trigger file. The other is "pg_ctl promote". (it uses a trigger file called $PGDATA/promote internally, but that's invisible to the user). Right, I was thinking of the trigger file to put a server *into* repli

Re: [HACKERS] Switching timeline over streaming replication

On 23.12.2012 16:37, Fujii Masao wrote: On Fri, Dec 21, 2012 at 1:48 AM, Fujii Masao wrote: On Sat, Dec 15, 2012 at 9:36 AM, Fujii Masao wrote: I found another "requested timeline does not contain minimum recovery point" error scenario in HEAD: 1. Set up the master 'M', one standby 'S1', and

Re: [HACKERS] Feature Request: pg_replication_master()

On 26.12.2012 21:55, Josh Berkus wrote: I'm not sure that my POV exactly matches up with Tom's, but on the last point, I strongly agree that the use of the trigger file makes it trivial to integrate Postgres warm standby management into 3rd party tools. I'm not against coming up with a new API

Re: [HACKERS] Feature Request: pg_replication_master()

I'm not sure that my POV exactly matches up with Tom's, but on the last point, I strongly agree that the use of the trigger file makes it trivial to integrate Postgres warm standby management into 3rd party tools. I'm not against coming up with a new API that's better for postgres dedicated tool

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

On 12/26/12 1:58 PM, anara...@anarazel.de wrote: I don't think its necessarily only one buffer - if I read the above output correctly Greg used the suggested debug output which just put the elog(WARN) before the Assert... Greg, could you output all "bad" buffers and only assert after the loop

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

Tom Lane schrieb: >Greg Smith writes: >> To try and speed up replicating this problem I switched to a smaller >> database scale, 100, and I was able to get a crash there. Here's the > >> latest: > >> 2012-12-26 00:01:19 EST [2278]: WARNING: refcount of >base/16384/57610 >> blockNum=118571,

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

Greg Smith writes: > To try and speed up replicating this problem I switched to a smaller > database scale, 100, and I was able to get a crash there. Here's the > latest: > 2012-12-26 00:01:19 EST [2278]: WARNING: refcount of base/16384/57610 > blockNum=118571, flags=0x106 is 1073741824 shou

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

To try and speed up replicating this problem I switched to a smaller database scale, 100, and I was able to get a crash there. Here's the latest: 2012-12-26 00:01:19 EST [2278]: WARNING: refcount of base/16384/57610 blockNum=118571, flags=0x106 is 1073741824 should be 0, globally: 0 2012-12-

Re: [HACKERS] Feature Request: pg_replication_master()

On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane wrote: > Josh Berkus writes: >>> What the patch doesn't change is the requirement to have a file that >>> causes the server to place itself into archive recovery. So there is >>> no more recovery.conf and instead we have a file called >>> recovery.trigger

Re: [HACKERS] proposal: regrole type?

2012/12/26 Pavel Stehule : > 2012/12/25 Tom Lane : >> Pavel Stehule writes: >>> * We can reduce to half lot of functions \df has_* (84 functions) >> >> Not without breaking existing queries. A function taking regrole might >> look like it substitutes for one taking a text-string user name as long

Re: [HACKERS] too much pgbench init output

Looks good to me. Will mark "Ready for Committer" Thanks On Thu, Dec 20, 2012 at 2:30 AM, Tomas Vondra wrote: > 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 n