On 1/30/13 7:52 AM, Jeevan Chalke wrote:
Looks good this time.
Will mark Ready for committor
Thanks for reviewing it more carefully than I did! :-) And my apologies
for the confusion earlier.
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put
On 2013-01-29 16:09:52 +1100, Josh Berkus wrote:
I have to admit, I fail to see why this is a good idea. There isn't much
of an efficiency bonus in freezing early (due to hint bits) and vacuums
over vacuum_freeze_table_age are considerably more expensive as they
have to scan the whole
Andres Freund and...@2ndquadrant.com wrote:
On 2013-01-29 16:09:52 +1100, Josh Berkus wrote:
I have to admit, I fail to see why this is a good idea. There
isn't much of an efficiency bonus in freezing early (due to
hint bits) and vacuums over vacuum_freeze_table_age are
considerably more
Hi,
I took the liberty to create a new thread for $subject, because the main
comments I've been receiving about Event Triggers at this point is how
difficult it is to try and follow our discussions about them.
In order for everybody interested to be able to easily get the important
bits of
On 2013-01-30 05:39:29 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-01-29 16:09:52 +1100, Josh Berkus wrote:
I have to admit, I fail to see why this is a good idea. There
isn't much of an efficiency bonus in freezing early (due to
hint bits) and
From: Tom Lane t...@sss.pgh.pa.us
Since we've fixed a couple of relatively nasty bugs recently, the core
committee has determined that it'd be a good idea to push out PG update
releases soon. The current plan is to wrap on Monday Feb 4 for public
announcement Thursday Feb 7. If you're aware of
2013-01-28 15:20 keltezéssel, Hari Babu írta:
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout
patch
for about 3 weeks. Does anyone have a little
2013-01-30 15:29 keltezéssel, Zoltán Böszörményi írta:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my
On 2013-01-30 14:58:24 +0100, Andres Freund wrote:
So reducing vacuum_freeze_min_age not only helps minimize the
writes that are needed when autovacuum needs to scan the entire
heap, but also decreases the frequency of those full-table scans.
But it increases the amount of pages that are
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people may object so I
will keep that in code committors plate.
I have no opinion on this
On Tuesday, January 29, 2013 7:42 PM Amit Kapila wrote:
On Tuesday, January 29, 2013 3:53 PM Heikki Linnakangas wrote:
On 29.01.2013 11:58, Amit Kapila wrote:
Can there be another way with which current patch code can be made
better,
so that we don't need to change the encoding
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected .out file is not
updated properly.
Which regress check failed? The .out file was updated in the patch for
prepared_xacts.sql where the
MauMau maumau...@gmail.com writes:
When I ran pg_ctl stop -mi against the primary, some applications
connected to the primary did not stop. ...
The root cause is that gettext() is called in the signal handler quickdie()
via errhint().
Yeah, it's a known hazard that quickdie() operates like
On 2013-01-30 10:23:09 -0500, Tom Lane wrote:
MauMau maumau...@gmail.com writes:
When I ran pg_ctl stop -mi against the primary, some applications
connected to the primary did not stop. ...
The root cause is that gettext() is called in the signal handler quickdie()
via errhint().
On Mon, Jan 28, 2013 at 9:09 PM, Josh Berkus j...@agliodbs.com wrote:
Let's do this by example. TableA is a large table which receives an
almost constant stream of individual row updates, inserts, and deletes.
DEFAULTS:
XID 1: First rows in TableA are updated.
XID 200m: Anti-wraparound
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people may object so I
will keep that in code
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-30 10:23:09 -0500, Tom Lane wrote:
Yeah, it's a known hazard that quickdie() operates like that.
What about not translating those? The messages are static and all memory
needed by postgres should be pre-allocated.
That would reduce our
On Wed, Jan 30, 2013 at 5:39 AM, Kevin Grittner kgri...@ymail.com wrote:
Andres Freund and...@2ndquadrant.com wrote:
Don't think I did. I was talking about vacuum_freeze_table_age
because that influences the amount of full-table scans
Not any more than vacuum_freeze_min_age does.
There is a
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people
2013-01-30 16:06 keltezéssel, Hari Babu írta:
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected .out file is not
updated properly.
Which regress check failed? The .out file was updated in
Hi,
As the discussion about Event Triggers seems to be confusing at times
for people trying to follow at home, I've put together a wiki page that
tries as making things clear about the use cases we want to solve and
how, and about what has been commited already and the remaining work to
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So please find attached to this email an implementation of the sql_drop
event trigger, that refrains on exposing any new information to the
users.
Already a v1 of that patch, per comments from Álvaro I reuse the
ObjectAddresses facility rather
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's
correctness, so
I
Andres Freund and...@2ndquadrant.com wrote:
I can't imagine that anybody with a large database ran pg
successfully with a small freeze_min_age due to this.
I can't speak to this from personal experience, because at
Wisconsin Courts we found ourselves best served by running a
database VACUUM
On 2013-01-30 10:21:07 -0800, Kevin Grittner wrote:
It seems to be broken since the initial introduction of
freeze_table_age in 6587818542e79012276dcfedb2f97e3522ee5e9b.
Trivial patch attached.
I didn't see a patch attached.
The archive has it, so I for once haven't forgotten sending
Kevin Grittner kgri...@ymail.com wrote:
To: Andres Freund and...@2ndquadrant.com
Trivial patch attached.
I didn't see a patch attached.
Never mind; I was looking in the wrong spot. (I just switched
email providers again because the last one couldn't seem to get the
email headers right for
Jeff Janes jeff.ja...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
So reducing vacuum_freeze_min_age not only helps minimize the
writes that are needed when autovacuum needs to scan the entire
heap,
How does it do that? If the tuple doesn't need to frozen now
because it was
On 1/28/13 6:25 PM, Tom Lane wrote:
I think we need to tighten this down by having index-constraint creation
check for conflicts with other constraint types. It also seems like it
might be a good idea to put in a unique index to enforce the intended
lack of conflicts --- note that the existing
On 1/25/13 11:56 AM, Christopher Browne wrote:
With a little bit of noodling around, here's a thought for a joint function
that I*think* has reasonably common scales:
f(deadtuples, relpages, age) =
deadtuples/relpages + e ^ (age*ln(relpages)/2^32)
Be careful with dead/relpages, because
On 1/29/13 6:40 PM, Tom Lane wrote:
I wrote:
Over in the thread about enhanced error fields, I claimed that
constraints are uniquely named among those associated with a table,
or with a domain. But it turns out that that ain't necessarily so,
because the code path for index constraints doesn't
I looked into the odd behavior noted recently on pgsql-novice that
the error context stack reported by plpgsql could differ between
first and subsequent occurrences of the same error:
http://www.postgresql.org/message-id/26370.1358539...@sss.pgh.pa.us
This seems to be specific to errors that are
Jim Nasby j...@nasby.net wrote:
the only reason to freeze is XID wrap
The conclusions you draw seem to be based on a slightly different
premise than stated here; the conclusions are only supported by the
assumption that the only reason to freeze at any particular moment
is to assure that all
2013/1/30 Tom Lane t...@sss.pgh.pa.us:
I looked into the odd behavior noted recently on pgsql-novice that
the error context stack reported by plpgsql could differ between
first and subsequent occurrences of the same error:
http://www.postgresql.org/message-id/26370.1358539...@sss.pgh.pa.us
On Wed, Jan 30, 2013 at 04:07:45PM +1100, Josh Berkus wrote:
I don't think I like --force because it isn't clear if we are forcing
the start to have done something, or forcing the server to be running.
Do we need this idempotent feature for stop too?
Yes, of course.
If idempotent
On 30/01/13 22:23, Tom Lane wrote:
BTW, I'm also wondering if it's really necessary for plpython/plpy_spi.c
to be looking into spi_priv.h ...
As far as I can tell, it's not necessary, spi.h would be perfectly fine.
Cheers,
Jan
--
Sent via pgsql-hackers mailing list
On Wed, Jan 30, 2013 at 4:05 PM, Jim Nasby j...@nasby.net wrote:
On 1/25/13 11:56 AM, Christopher Browne wrote:
With a little bit of noodling around, here's a thought for a joint
function
that I*think* has reasonably common scales:
f(deadtuples, relpages, age) =
deadtuples/relpages +
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com writes:
I think the solution is the typical one. That is, to just remember the
receipt of SIGQUIT by setting a global variable and call siglongjmp() in
quickdie(), and perform tasks currently done in quickdie() when
sigsetjmp()
On 1/30/13 3:28 PM, Kevin Grittner wrote:
Jim Nasby j...@nasby.net wrote:
then the *ideal* time to start a freeze vacuum on a table is so
that the vacuum would end *exactly* as we were about to hit XID
wrap.
For a tuple which you know is going to survive long enough to be
frozen, the
On 1/30/13 4:37 PM, Christopher Browne wrote:
From a more practical standpoint, I think it would be extremely useful to
have a metric that showed how quickly a table churned. Something like dead
tuples per time period. Comparing that to the non-bloated table size should
give a very strong
MauMau maumau...@gmail.com writes:
From: Tom Lane t...@sss.pgh.pa.us
The long and the short of it is that SIGQUIT is the emergency-stop panic
button. You don't use it for routine shutdowns --- you use it when
there is a damn good reason to and you're prepared to do some manual
cleanup if
This isn't an area that admits of quick-fix solutions --- everything
we might do has disadvantages. Also, the lack of complaints to date
shows that the problem is not so large as to justify panic responses.
I'm not really inclined to mess around with a tradeoff that's been
working pretty
On 2013-01-31 08:27:13 +0900, Tatsuo Ishii wrote:
This isn't an area that admits of quick-fix solutions --- everything
we might do has disadvantages. Also, the lack of complaints to date
shows that the problem is not so large as to justify panic responses.
I'm not really inclined to mess
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-31 08:27:13 +0900, Tatsuo Ishii wrote:
What about adding a caution to the doc something like:
pg_ctl -m -i stop may cause a PostgreSQL hang if native laguage support
enabled.
That doesn't entirely solve the problem, see quote and reply
What about adding a caution to the doc something like:
pg_ctl -m -i stop may cause a PostgreSQL hang if native laguage
support enabled.
That doesn't entirely solve the problem, see quote and reply in
6845.1359561...@sss.pgh.pa.us
Oh, I see now.
I think adding errmsg_raw() or
On 01/30/2013 11:03 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 11:03 AM, Tom Lane wrote:
FWIW, I'd vote for not enabling that by default --- it's basically an
unwarranted assumption about how wide people's terminal windows are.
Well, we could actually set the wrap value to 0, which would mean
On Wednesday, January 23, 2013 5:36 PM Etsuro Fujita wrote:
Hi Amit,
Thank you for your review. Ive rebased and updated the patch. Please
find attached the patch.
Test case issues:
--
1. Broken pipe is not handled in case of psql \copy command;
Issue are as
You can get nearly all the benefits of your sane settings just by
increasing autovacuum_freeze_max_age and leaving vacuum_freeze_min_age
alone. (Assuming the table doesn't get vacuumed for other reasons)
Correct, it's the ratio that matters.
--
Josh Berkus
PostgreSQL Experts Inc.
On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii is...@postgresql.org wrote:
So if my understating is correct, 1)Tomas Vondra commits to work on
Windows support for 9.4, 2)on the assumption that one of Andrew
Dunstan, Dave Page or Magnus Hagander will help him in Windows
development.
Ok? If
49 matches
Mail list logo
