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
Robert Haas 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, especially if you want so
Robert Haas writes:
> On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane 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 ha
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
http://www.postgresql
(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
On Fri, Feb 1, 2013 at 2:34 PM, Andres Freund 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 auto-vacuum inspired by
Christopher Browne 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 store a single
float
Daniel Farina writes:
> On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas 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 resolves to functions in
> pg_pr
Pavel Stehule 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 either.)
However, what I want
On Fri, Feb 1, 2013 at 4:59 PM, Robert Haas wrote:
> On Thu, Jan 31, 2013 at 3:18 PM, Alvaro Herrera
> 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 no
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas wrote:
> On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
> I would like to not create any -> operators, so t
On 2013-02-01 14:05:46 -0800, Jeff Janes wrote:
> On Wed, Jan 30, 2013 at 6:55 AM, Andres Freund wrote:
> >
> > c.f.
> > vacuum_set_xid_limits:
> > /*
> > * Determine the table freeze age to use: as specified by
> > the caller,
> > * or vacuum_fre
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 2/1/13 3:21 PM, Tom Lane wrote:
> Peter Eisentraut 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
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan wrote:
>>> On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
I would like to not create any -> operators, so that that syntax could
be used in the future for metho
On Wed, Jan 30, 2013 at 6:55 AM, Andres Freund 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 3:18 PM, Alvaro Herrera
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
this crowd; I'm not even
Tom Lane wrote:
> Andres Freund 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 make it a
On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane 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 first time we've
had
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 lin
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
Peter Eisentraut 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 after mistak
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
On Wed, Jan 30, 2013 at 12:59 PM, Dimitri Fontaine
wrote:
> 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
On Tue, Jan 29, 2013 at 1:55 PM, Alvaro Herrera
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:
>
> + erep
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 4246727
On Fri, 01 Feb 2013 18:11:13 +0100, Peter Eisentraut
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 options. What will hap
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 writes:
> > > > ! ereport(ERROR,
> > > > !
On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian 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 option
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 thre
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 th
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/15/13 6:53 PM, Tom Lane wrote:
> Peter Eisentraut 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)))'
>> >
* 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 addi
2013/2/1 Pavel Stehule :
> 2013/2/1 Tom Lane :
>> Andrew Dunstan 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 tw
2013/2/1 Tom Lane :
> Andrew Dunstan 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 entire
2013/2/1 Andrew Dunstan :
>
> On 02/01/2013 10:38 AM, Tom Lane wrote:
>>
>> Andrew Dunstan 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
Andrew Dunstan 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 to whether we l
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 (rela
On Fri, Feb 1, 2013 at 9:07 PM, Alvaro Herrera 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.
>
+1. I think th
On 02/01/2013 10:38 AM, Tom Lane wrote:
Andrew Dunstan 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
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" unt
On Fri, Feb 1, 2013 at 9:04 PM, Tom Lane wrote:
> Pavan Deolasee 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 I'm sure there would be similar
such e
Andrew Dunstan 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 with
dropping it
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 analyz
Pavan Deolasee 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 to just off analyze.
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 basic
Andres Freund 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, so don't
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
> poi
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.
> >
>
2013/2/1 Pavel Stehule :
> 2013/2/1 Peter Eisentraut :
>> On 2/1/13 8:00 AM, Pavel Stehule wrote:
>>> 2013/2/1 Marko Tiikkaja :
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.
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 s
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.
2013/2/1 Peter Eisentraut :
> On 2/1/13 8:00 AM, Pavel Stehule wrote:
>> 2013/2/1 Marko Tiikkaja :
>>> 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 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. I
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
tr
On 2/1/13 8:00 AM, Pavel Stehule wrote:
> 2013/2/1 Marko Tiikkaja :
>> 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
On 01/31/2013 11:17 PM, Tom Lane wrote:
Andrew Dunstan 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
constant I'd like to proces
On Fri, Feb 1, 2013 at 6:10 PM, Pavan Deolasee wrote:
>
>
>
>>
>> 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
> thats
2013/2/1 Marko Tiikkaja :
> 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 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 (pgsql-hackers@pos
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 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. He
2013/2/1 Daniel Farina :
> On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai 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
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai 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 contrib/postgres_fdw to apply, but i
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 m
On Fri, Feb 1, 2013 at 3:07 PM, Pavan Deolasee 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
--
Sent via pgsql-hac
(re-adding hackers)
On Fri, Feb 1, 2013 at 2:46 PM, Vlad Bailescu 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
necessarily say that o
On 01/02/13 20:43, Peter Geoghegan wrote:
On Sunday, 27 January 2013, Robert Haas 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 ever will and cau
On Thu, Jan 31, 2013 at 4:40 PM, Dimitri Fontaine wrote:
> Andrew Dunstan 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
>
+1
After looking at both the SQL
70 matches
Mail list logo