>>> On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii 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?
> 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.
http:
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
Andrew Dunstan 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 always
> wrap.
On 01/30/2013 11:03 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja 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 othe
>> 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
Andres Freund 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 in
> 6845.13
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 t
> 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
"MauMau" writes:
> From: "Tom Lane"
>> 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 necessary.
> How about 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 ind
On 1/30/13 3:28 PM, Kevin Grittner wrote:
Jim Nasby 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 *ideal* time to freez
From: "Tom Lane"
"MauMau" 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()
returns in PostgresMain().
I think
On Wed, Jan 30, 2013 at 4:05 PM, Jim Nasby 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
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 (pgsql-hackers@postgresql.
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.
2013/1/30 Tom Lane :
> 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
Jim Nasby 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 tuples are froz
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 d
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 do
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 de
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 i
Jeff Janes wrote:
> Kevin Grittner 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 already frozen, that just means
Kevin Grittner wrote:
> To: Andres Freund
>> 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 threading purposes.)
-Kevin
--
S
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 s
Andres Freund 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 FREEZE ANALYZE each nig
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch 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 wrote:
>>
>> > You're the second commentator to be skittish about the patch's
>> > correctness, so
>> > I won't argue against a con
Dimitri Fontaine 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 than building my own L
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
accomplish
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
Andrew Dunstan writes:
> On 01/30/2013 09:58 AM, Tom Lane wrote:
>> Marko Tiikkaja 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
>>>
On Wed, Jan 30, 2013 at 5:39 AM, Kevin Grittner wrote:
> Andres Freund 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 lot more room for vacuum_freez
Andres Freund 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 exposure slightly,
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja 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.
On Mon, Jan 28, 2013 at 9:09 PM, Josh Berkus 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 autovac of
On 2013-01-30 10:23:09 -0500, Tom Lane wrote:
> "MauMau" 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
"MauMau" 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 that.
> I t
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 wher
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 encodin
Marko Tiikkaja 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 to on
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 th
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 lock_timeo
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
From: "Tom Lane"
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 any bug fixes yo
On 2013-01-30 05:39:29 -0800, Kevin Grittner wrote:
> Andres Freund 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 ov
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 inform
Andres Freund 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 expensive a
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
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
49 matches
Mail list logo
