On Thu, Jan 31, 2013 at 4:40 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Andrew Dunstan and...@dunslane.net writes:
Well, we could actually set the wrap value to 0, which would mean always
wrap. That wouldn't be making any assumption about the user's terminal
window size ;-)
+1
On 01/02/13 20:43, Peter Geoghegan wrote:
On Sunday, 27 January 2013, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
If we're going to start installing safeguards against doing stupid
things, there's a long list of scenarios that happen far more
regularly than this
(re-adding hackers)
On Fri, Feb 1, 2013 at 2:46 PM, Vlad Bailescu v...@mojitosoftware.com wrote:
I'm pretty sure the io is from the autovacuum on master table because it's
last_autovacuum stats update almost every minute
That only proves that the master table is being vacuumed, but does not
On Fri, Feb 1, 2013 at 3:07 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
(re-adding hackers)
Apologies. Did not realize that the original email was on
pgsql-general. Vlad, please copy -general on your responses.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On 01/28/2013 02:13 AM, Robert Haas wrote:
If we're going to start installing safeguards against doing stupid
things, there's a long list of scenarios that happen far more
regularly than this ever will and cause far more damage.
I'm not sure this approach is consistent with other decisions
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed the v10 patch cannot be applied on the latest master branch
cleanly. The attached ones were rebased.
Hello,
I'm just getting started looking at this, but notice that the second
patch relies on
2013/2/1 Daniel Farina dan...@heroku.com:
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed the v10 patch cannot be applied on the latest master branch
cleanly. The attached ones were rebased.
Hello,
I'm just getting started looking at this, but notice that
On 01/26/2013 10:56 PM, Noah Misch wrote:
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
Just to confirm, I think that this is ready for commit as posted in
20130101025421.ga17...@tornado.leadboat.com.
I'll amend my docs changes and submit them separately.
Thanks. Here's a
Hello
now a most hard work is done and I would to enable access to new
error fields from plpgsql.
these new fields are column_name, constraint_name, datatype_name,
table_name and schema_name.
This proposal has impact on two plpgsql statements - RAISE and GET
STACKED DIAGNOSTICS.
I am sending
On 2/1/13 1:47 PM, Pavel Stehule wrote:
now a most hard work is done and I would to enable access to new
error fields from plpgsql.
Is there a compelling reason why we wouldn't provide these already in 9.3?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
2013/2/1 Marko Tiikkaja pgm...@joh.to:
On 2/1/13 1:47 PM, Pavel Stehule wrote:
now a most hard work is done and I would to enable access to new
error fields from plpgsql.
Is there a compelling reason why we wouldn't provide these already in 9.3?
a time for assign to last commitfest is out.
On Fri, Feb 1, 2013 at 6:10 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
2012-12-05 00:44:23 EET LOG: automatic analyze of table
fleet.fleet.vehicle_position system usage: CPU 4.46s/0.61u sec elapsed
465.09 sec
This is the interesting piece of information. So its the auto analyze
On 01/31/2013 11:17 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
What's the best way for me to find out if a given parameter of a
function is a constant? The context is that it's expensive to process,
and in most cases will in fact be a constant, so if it is in fact a
On 2/1/13 8:00 AM, Pavel Stehule wrote:
2013/2/1 Marko Tiikkaja pgm...@joh.to:
On 2/1/13 1:47 PM, Pavel Stehule wrote:
now a most hard work is done and I would to enable access to new
error fields from plpgsql.
Is there a compelling reason why we wouldn't provide these already in 9.3?
a
fmgr.c contains this:
/*
* !!! OLD INTERFACE !!!
*
* fmgr() is the only remaining vestige of the old-style caller support
* functions. It's no longer used anywhere in the Postgres
distribution,
* but we should leave it around for a release or two to ease the
On 2013-01-22 22:19:25 -0500, Tom Lane wrote:
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
2013/2/1 Peter Eisentraut pete...@gmx.net:
On 2/1/13 8:00 AM, Pavel Stehule wrote:
2013/2/1 Marko Tiikkaja pgm...@joh.to:
On 2/1/13 1:47 PM, Pavel Stehule wrote:
now a most hard work is done and I would to enable access to new
error fields from plpgsql.
Is there a compelling reason why we
On 1/31/13 5:42 PM, MauMau wrote:
Thank you for sharing your experience. So you also considered making
postmaster SIGKILL children like me, didn't you? I bet most of people
who encounter this problem would feel like that.
It is definitely pg_ctl who needs to be prepared, not the users. It
On 02/01/2013 06:12 AM, Craig Ringer wrote:
On 01/26/2013 10:56 PM, Noah Misch wrote:
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
Just to confirm, I think that this is ready for commit as posted in
20130101025421.ga17...@tornado.leadboat.com.
I'll amend my docs changes and
2013/2/1 Pavel Stehule pavel.steh...@gmail.com:
2013/2/1 Peter Eisentraut pete...@gmx.net:
On 2/1/13 8:00 AM, Pavel Stehule wrote:
2013/2/1 Marko Tiikkaja pgm...@joh.to:
On 2/1/13 1:47 PM, Pavel Stehule wrote:
now a most hard work is done and I would to enable access to new
error fields
On 2013-02-01 08:55:24 -0500, Peter Eisentraut wrote:
On 1/31/13 5:42 PM, MauMau wrote:
Thank you for sharing your experience. So you also considered making
postmaster SIGKILL children like me, didn't you? I bet most of people
who encounter this problem would feel like that.
It is
Andres Freund wrote:
Hi,
The fklocks patch moved HeapSatisfiesHOTandKeyUpdate (or rather
HeapSatisfiesHOTUpdate back then) to be called way earlier in
heap_update as its needed to know which lock level is
required. Unfortunately the oid of the new tuple isn't yet setup at that
point.
Andres Freund and...@2ndquadrant.com writes:
On 2013-02-01 08:55:24 -0500, Peter Eisentraut wrote:
I found an old patch that I had prepared for this, which I have
attached. YMMV.
+static void
+quickdie_alarm_handler(SIGNAL_ARGS)
+{
+/*
+ * We got here if ereport() was blocking,
Andres Freund wrote:
If youre careful you can also notice that there is an interesting typo
in the freeze table computation. Namely it uses freeze_min_age instead
of freeze_table_age. Which probably explains why I had so bad
performance results with lowering vacuum_freeze_min_age, it
Pavan Deolasee pavan.deola...@gmail.com writes:
While looking at this particular case on -general, I realized that there is
no way to *only* disable auto-analyze on a table. While one can cheat like
what I suggested to the OP by setting threshold very high, I think it will
be useful to be able
Pavan Deolasee escribió:
While looking at this particular case on -general, I realized that there is
no way to *only* disable auto-analyze on a table. While one can cheat like
what I suggested to the OP by setting threshold very high, I think it will
be useful to be able to just off analyze.
Andrew Dunstan and...@dunslane.net writes:
fmgr.c contains this:
* DEPRECATED, DO NOT USE IN NEW CODE
Should we just drop all support for the old interface now?
Is there any actual benefit to removing it? I don't recall that
it's been the source of any maintenance burden. I'd be fine
On Fri, Feb 1, 2013 at 9:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
A new reloption such as autovacuum_analyze_enabled is what we need.
This seems to me to be a wart that doesn't fix the actual problem ---
IMHO this case is just an example, but
On 01.02.2013 02:04, Josh Berkus wrote:
I thought this was only a 9.3 issue, but it turns out to be
reproduceable on 9.2.2. Basically, I did:
1. master is queicent ... no writes occuring.
2. createded cascading replica (reprep1) from replica (repmaster)
3. reprep1 remains in recovery mode
On 02/01/2013 10:38 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
fmgr.c contains this:
* DEPRECATED, DO NOT USE IN NEW CODE
Should we just drop all support for the old interface now?
Is there any actual benefit to removing it? I don't recall that
it's been the source
On Fri, Feb 1, 2013 at 9:07 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Pavan Deolasee escribió:
A new reloption such as autovacuum_analyze_enabled is what we need.
I was thinking in this option just three days ago, so yeah.
I think we also want an option to turn off just vacuum.
Tomas Vondra wrote:
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index be3adf1..4ec485e 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -64,10 +64,14 @@
/* --
* Paths for the statistics files (relative to
Andrew Dunstan and...@dunslane.net writes:
My hope was that if we got rid of the old stuff we wouldn't need to use
PG_FUNCTION_INFO_V1(myfunc);
in external modules any more (I recently got bitten through forgetting
this and it cost me an hour or two).
Oh. Well, that's entirely unrelated
2013/2/1 Andrew Dunstan and...@dunslane.net:
On 02/01/2013 10:38 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
fmgr.c contains this:
* DEPRECATED, DO NOT USE IN NEW CODE
Should we just drop all support for the old interface now?
Is there any actual benefit to
2013/2/1 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
My hope was that if we got rid of the old stuff we wouldn't need to use
PG_FUNCTION_INFO_V1(myfunc);
in external modules any more (I recently got bitten through forgetting
this and it cost me an hour or two).
2013/2/1 Pavel Stehule pavel.steh...@gmail.com:
2013/2/1 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
My hope was that if we got rid of the old stuff we wouldn't need to use
PG_FUNCTION_INFO_V1(myfunc);
in external modules any more (I recently got bitten through
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
but some users uses V0 for glibc functions - it is probably ugly hack,
but it allows using external libraries - and should be possible still
use it
No, I don't think we need or want to continue to support such an ugly,
ugly, hack.
+1 for adding
On 1/15/13 6:53 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I'll take another stab at providing pkg-config files for the client-side
libraries.
This bit:
+echo 'Libs.private: $(filter-out
$(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))'
On 02/01/2013 11:20 AM, Tom Lane wrote:
I'm not really thrilled with switching the default assumption to be V1,
especially not if we implement that by telling authors they can stop
bothering with the macros. The pain will just come back sometime in the
future when we decide we need a function
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
On Fri, 21 Dec 2012 16:14:19 +0100, I wrote:
I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause.
Here's the second version of the patch, addressing the syntax issues.
I think the
On Fri, Feb 1, 2013 at 12:37:21PM -0300, Alvaro Herrera wrote:
Pavan Deolasee escribió:
While looking at this particular case on -general, I realized that there is
no way to *only* disable auto-analyze on a table. While one can cheat like
what I suggested to the OP by setting threshold
On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian br...@momjian.us wrote:
On Fri, Feb 1, 2013 at 12:37:21PM -0300, Alvaro Herrera wrote:
A new reloption such as autovacuum_analyze_enabled is what we need.
I was thinking in this option just three days ago, so yeah.
I think we also want an
On Tue, Jan 29, 2013 at 08:34:24PM -0500, Noah Misch wrote:
On Fri, Jan 25, 2013 at 11:28:58PM -0500, Bruce Momjian wrote:
On Fri, Jan 25, 2013 at 11:08:56PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
! ereport(ERROR,
!
On Fri, 01 Feb 2013 18:11:13 +0100, Peter Eisentraut pete...@gmx.net
wrote:
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
Here's the second version of the patch, addressing the syntax issues.
I think the new syntax is horribly ugly. The actual command name should
always come first, not
I've been able to reproduce the problem reported by Pius Chan in bug
#7819. With some logging added that prints the OldestXmin values used
by vacuum and cluster operations, the reason is fairly clear:
2013-02-01 13:41:12 EST 8011 LOG: vacuuming test with OldestXmin 1760160
FreezeLimit
On Tue, Jan 29, 2013 at 1:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Heikki Linnakangas wrote:
Tolerate timeline switches while pg_basebackup -X fetch is running.
I just noticed that this commit introduced a few error messages that
have a file argument which is not properly quoted:
On Wed, Jan 30, 2013 at 12:59 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
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
create extension hstore with schema pg_catalog;
alter extension hstore set schema public;
ERROR: 0A000: cannot remove dependency on schema pg_catalog because it
is a system object
drop extension hstore; -- works
I've seen this happen cleaning up after mistakenly misplaced extensions.
I suspect
Peter Eisentraut pete...@gmx.net writes:
create extension hstore with schema pg_catalog;
alter extension hstore set schema public;
ERROR: 0A000: cannot remove dependency on schema pg_catalog because it
is a system object
drop extension hstore; -- works
I've seen this happen cleaning up
I have encountered two unrelated flaws in the psql table output.
First, when using unaligned vertical mode (\a \x on), there is always an
empty line after the last record. This also means that an empty result
set prints an empty line, instead of nothing.
Second, when using aligned vertical mode
On Fri, February 1, 2013 21:22, Peter Eisentraut wrote:
I have encountered two unrelated flaws in the psql table output.
First, when using unaligned vertical mode (\a \x on), there is always an
empty line after the last record. This also means that an empty result
set prints an empty line,
On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In any case, I no longer have much faith in the idea that letting
GetOldestXmin go backwards is really safe.
That is admittedly kind of weird behavior, but I think one could
equally blame this on CLUSTER. This is hardly the
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-18 10:33:16 -0500, Tom Lane wrote:
Really I'd prefer not to move the backend definitions out of postgres.h
at all, just because doing so will lose fifteen years of git history
about those particular lines (or at least
On Thu, Jan 31, 2013 at 3:18 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
My intention was to apply a Nasby correction to Browne Strength and call
the resulting function Browne' (Browne prime). Does that sound better?
/me rests head in hands. I'm not halfway clever enough to hang with
On Wed, Jan 30, 2013 at 6:55 AM, Andres Freund and...@2ndquadrant.com wrote:
c.f.
vacuum_set_xid_limits:
/*
* Determine the table freeze age to use: as specified by the
caller,
* or vacuum_freeze_table_age, but in any case not more than
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
I would like to not create any - operators, so that that
On 2/1/13 3:21 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
create extension hstore with schema pg_catalog;
alter extension hstore set schema public;
ERROR: 0A000: cannot remove dependency on schema pg_catalog because it
is a system object
drop extension hstore; -- works
On 2/1/13 11:06 AM, Andrew Dunstan wrote:
My hope was that if we got rid of the old stuff we wouldn't need to use
PG_FUNCTION_INFO_V1(myfunc);
in external modules any more
My fear with that would be that people would start forgetting this and
modules won't work with older PG versions
On 2013-02-01 14:05:46 -0800, Jeff Janes wrote:
On Wed, Jan 30, 2013 at 6:55 AM, Andres Freund and...@2ndquadrant.com wrote:
c.f.
vacuum_set_xid_limits:
/*
* Determine the table freeze age to use: as specified by
the caller,
* or
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter
On Fri, Feb 1, 2013 at 4:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 31, 2013 at 3:18 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
My intention was to apply a Nasby correction to Browne Strength and call
the resulting function Browne' (Browne prime). Does that sound
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch related to your proposal
I looked at this a bit. It's getting there, though I still don't trust
the places where you've chosen to clear the prefix setting. (Looking at
it, I'm now not sure that I trust the implementation of \g
Daniel Farina dan...@heroku.com writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not difficult for people who
The problem being: even though pg_operator
Christopher Browne cbbro...@gmail.com writes:
I picked values that I knew could be easily grabbed, and we don't
have an immediate tuples-per-page estimate on pg_class.
Er, what? reltuples/relpages is exactly that estimate --- in fact,
it's only because of historical accident that we don't
On Fri, Feb 1, 2013 at 2:34 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-02-01 14:05:46 -0800, Jeff Janes wrote:
As far as I can tell this bug kicks in when your cluster gets to be
older than freeze_min_age, and then lasts forever after. After that
point pretty much every
(sending this again; it was eaten by the ethernet)
Heikki,
I thought this was only a 9.3 issue, but it turns out to be
reproduceable on 9.2.2. Basically, I did:
1. master is queicent ... no writes occuring.
2. createded cascading replica (reprep1) from replica (repmaster)
3. reprep1 remains in
Hi,
I'm having trouble with range types and btree_gist - after some playing
I believe it's
caused by a bug in how btree_gist handles text columns. All this is on
freshly compiled
9.2.2.
I'm trying to achieve almost exactly what's described in the second
example on
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In any case, I no longer have much faith in the idea that letting
GetOldestXmin go backwards is really safe.
That is admittedly kind of weird behavior, but I think one could
equally
Robert Haas robertmh...@gmail.com writes:
Having said that, I agree that a fix in GetOldestXmin() would be nice
if we could find one, but since the comment describes at least three
different ways the value can move backwards, I'm not sure that there's
really a practical solution there,
On Monday, January 28, 2013, Kevin Grittner wrote:
IMO, anything which changes an anti-wraparound vacuum of a
bulk-loaded table from read the entire table and rewrite nearly
the complete table with WAL-logging to rewriting a smaller portion
of the table with WAL-logging is an improvement.
70 matches
Mail list logo
