Looks good to me.
Will mark Ready for Committer
Thanks
On Thu, Dec 20, 2012 at 2:30 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 19.12.2012 06:30, Jeevan Chalke wrote:
On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
Hi,
attached
2012/12/26 Pavel Stehule pavel.steh...@gmail.com:
2012/12/25 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
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
Greg Smith g...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us schrieb:
Greg Smith g...@2ndquadrant.com 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
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
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
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
On 23.12.2012 16:37, Fujii Masao wrote:
On Fri, Dec 21, 2012 at 1:48 AM, Fujii Masaomasao.fu...@gmail.com wrote:
On Sat, Dec 15, 2012 at 9:36 AM, Fujii Masaomasao.fu...@gmail.com wrote:
I found another requested timeline does not contain minimum recovery point
error scenario in HEAD:
1. Set
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*
On Wed, Dec 26, 2012 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Dec 26, 2012 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us 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
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:
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
On Wed, Dec 26, 2012 at 11:47 PM, Greg Smith g...@2ndquadrant.com 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.
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 and
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 adding
* 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 created dates, we
Greg Stark st...@mit.edu writes:
On Wed, Dec 26, 2012 at 11:47 PM, Greg Smith g...@2ndquadrant.com 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
Stephen Frost sfr...@snowman.net 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
* 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
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
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
24 matches
Mail list logo
