Forget to mention, that:
- VACUUM is running on the master;
- current state is unchanged for 20 hours.
2012/9/26 Виктор Егоров vyego...@gmail.com:
I'm afraid I'm exactly in this situation now.
Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) was:
INFO:
Hi,
On Tue, 2012-09-25 at 20:42 -0400, Robert Haas wrote:
It seems therefore that REINDEX + VACUUM with
vacuum_freeze_table_age=0 is not quite sufficient to recover from this
problem. If your index has come to contain a circularity, vacuum will
fail to terminate, and you'll need to drop it
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Wed, Sep 26, 2012 at 12:17 AM, Daymel Bonne Solís dbo...@uci.cu wrote:
Hello hackers:
I need a list of all triggers created in my database, but the view
system_information.triggers does not show truncate
Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 5:30 PM, Peter Eisentraut pete...@gmx.net
wrote:
I haven't followed the details of the htup header reorganization, but
I
have noticed that a number of external extension modules will be
broken
because of the move of GETSTRUCT() and to a lesser
Hi,
On Wednesday, September 26, 2012 07:57:06 AM Виктор Егоров wrote:
I'm afraid I'm exactly in this situation now.
:(
Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE)
It recommended doing a REINDEX first though? I guess you didn't do that?
was: INFO:
On 09/26/2012 02:48 AM, Andrew Dunstan wrote:
On 09/25/2012 08:35 PM, Peter Eisentraut wrote:
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
Actually, after reading another message you sent, I thought you were
going to respond that your proposed transforms feature would cover it.
I had
On Wed, Sep 26, 2012 at 4:14 PM, Albe Laurenz laurenz.a...@wien.gv.atwrote:
Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 5:30 PM, Peter Eisentraut pete...@gmx.net
wrote:
I haven't followed the details of the htup header reorganization, but
I
have noticed that a number of external
You're right, REINDEX was not done.
I've stopped the VACUUM, did a proper server restart (pg_ctl -m fast -w restart)
and will work on rebuilding relations.
Seems like I have another issue with a bunch of bloated tables on my way also.
Thanks for the support.
2012/9/26 Andres Freund
On Tuesday, September 25, 2012 01:48:34 PM Michael Paquier wrote:
On Tue, Sep 25, 2012 at 5:55 PM, Andres Freund and...@2ndquadrant.comwrote:
On Tuesday, September 25, 2012 04:37:05 AM Michael Paquier wrote:
On Tue, Sep 25, 2012 at 8:13 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 09/26/2012 03:08 AM, Daniel Farina wrote:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Wed, Sep 26, 2012 at 12:17 AM, Daymel Bonne Solís dbo...@uci.cu wrote:
Hello hackers:
I need a list of all triggers created in my database, but the view
Hi Merlin,
thanks, your code works perfectly.
Cheers,
Petr
On 10.9.2012 16:33, Merlin Moncure wrote:
On Mon, Sep 10, 2012 at 8:42 AM, Petr Chmelar chmel...@fit.vutbr.cz wrote:
Hi there,
we tried to create the libpqtypes enum binary send but it doesn't work:
// register types
On Wed, Sep 26, 2012 at 8:13 PM, Andres Freund and...@2ndquadrant.comwrote:
On Tuesday, September 25, 2012 01:48:34 PM Michael Paquier wrote:
On Tue, Sep 25, 2012 at 5:55 PM, Andres Freund and...@2ndquadrant.com
wrote:
On Tuesday, September 25, 2012 04:37:05 AM Michael Paquier wrote:
Hi,
I've been struggling with autovacuum generating a lot of I/O and CPU on
some of our
systems - after a night spent analyzing this behavior, I believe the
current
autovacuum accidentally behaves a bit like a stress-test in some corner
cases (but
I may be seriously wrong, after all it was a
I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?
1. Add a new varlena column to pg_proc catalog table,
On Wednesday, September 26, 2012 02:39:36 PM Michael Paquier wrote:
Do you think it is acceptable to consider that the user has to do the
cleanup of the old or new index himself if there is a failure?
The problem I see is that if you want the thing to be efficient you might end
up
doing step
Excerpts from Peter Eisentraut's message of mar sep 25 21:30:59 -0300 2012:
I haven't followed the details of the htup header reorganization, but I
have noticed that a number of external extension modules will be broken
because of the move of GETSTRUCT() and to a lesser extent
heap_getattr().
On Mon, Sep 24, 2012 at 9:18 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think this is fundamentally wrong, or at least misleading, because it
documents OID as if it were an ordinary column. Somebody who did
select * from pg_class and didn't see any
Daniel Farina dan...@heroku.com writes:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
The definition of information_schema.triggers contains this:
-- TRIGGER_TYPE_UPDATE; we intentionally omit TRIGGER_TYPE_TRUNCATE
so it seems that we are not showing TRUNCATE
Albe Laurenz laurenz.a...@wien.gv.at writes:
Hitoshi Harada wrote:
But it's only add #include access/htup_details.h? I'd not argue
it's harmful unless I missed your point.
I guess the point is that you need an #ifdef if you want a module
to be able to build with both 9.3 and lower versions.
On 09/25/2012 08:56 PM, Robert Haas wrote:
On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That
Antonin Houska antonin.hou...@gmail.com writes:
I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?
Excerpts from Peter Eisentraut's message of mié sep 26 11:18:51 -0300 2012:
On 9/26/12 10:07 AM, Tom Lane wrote:
I can't get excited about this either. This isn't the first, or the
last, change that add-on modules can expect to have to make to track
newer Postgres versions. If we allow
Hi,
After much distractions I've at least been able to do something about
that bug report.
Marko Kreen mark...@gmail.com writes:
1) Dumpable sequences are not supported - if sequence is tagged
with pg_catalog.pg_extension_config_dump(), the pg_dump tries
to run COPY on it.
I can only
On 9/25/12 8:48 PM, Andrew Dunstan wrote:
That still leaves the other uses for having well known Oids (or possibly
UUIDs) for non-builtin types (e.g. so Drivers don't have to look them up
in the catalogs, or having issues when types are added to the core.)
Here is a problem: If I write an
On 9/26/12 10:07 AM, Tom Lane wrote:
I can't get excited about this either. This isn't the first, or the
last, change that add-on modules can expect to have to make to track
newer Postgres versions. If we allow Peter's complaint to become the
new project policy, we'll never be able to make
Really, as far as autovacuum is concerned, it would be much more useful
to be able to reliably detect that a table has been recently vacuumed,
without having to request a 10ms-recent pgstat snapshot. That would
greatly reduce the amount of time autovac spends on pgstat requests.
--
Álvaro
On Wed, Sep 26, 2012 at 5:43 AM, Tomas Vondra t...@fuzzy.cz wrote:
First - our system really is not a common one - we do have ~1000 of
databases of
various size, each containing up to several thousands of tables (several
user-defined
tables, the rest serve as caches for a reporting
On 26 September 2012 15:02, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
The definition of information_schema.triggers contains this:
-- TRIGGER_TYPE_UPDATE; we intentionally omit
On 26-09-2012 09:43, Tomas Vondra wrote:
I've been struggling with autovacuum generating a lot of I/O and CPU on some
of our
systems - after a night spent analyzing this behavior, I believe the current
autovacuum accidentally behaves a bit like a stress-test in some corner cases
(but
I may
On Wed, Sep 26, 2012 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
The definition of information_schema.triggers contains this:
-- TRIGGER_TYPE_UPDATE; we intentionally
On 26-09-2012 11:08, Simon Riggs wrote:
I suggest we implement that with some kind of switch/case in the view
definition.
-- parameter can be set in a session and defaults to on
SET compliance_information_schema TO off;
--
Euler Taveira de Oliveira - Timbira
Dne 26.09.2012 16:51, Jeff Janes napsal:
On Wed, Sep 26, 2012 at 5:43 AM, Tomas Vondra t...@fuzzy.cz wrote:
First - our system really is not a common one - we do have ~1000
of
databases of
various size, each containing up to several thousands of tables
(several
user-defined
tables, the rest
Excerpts from Euler Taveira's message of mié sep 26 11:53:27 -0300 2012:
On 26-09-2012 09:43, Tomas Vondra wrote:
5) splitting the single stat file into multiple pieces - e.g. per database,
written separately, so that the autovacuum workers don't need to read all
the data even for
On Wed, Sep 26, 2012 at 5:36 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
After much distractions I've at least been able to do something about
that bug report.
Thanks.
2) If there is schema with functions, but nothing else,
create extension pgq_coop from 'unpackaged';
drop extension
Excerpts from Tomas Vondra's message of mié sep 26 12:25:58 -0300 2012:
Dne 26.09.2012 16:51, Jeff Janes napsal:
I think forking it off to to another value would be better. If you
are an autovacuum worker which is just starting up and so getting its
initial stats, you can tolerate a stats
Dne 26.09.2012 17:29, Alvaro Herrera napsal:
Excerpts from Tomas Vondra's message of mié sep 26 12:25:58 -0300
2012:
Dne 26.09.2012 16:51, Jeff Janes napsal:
I think forking it off to to another value would be better. If
you
are an autovacuum worker which is just starting up and so
Peter Eisentraut pete...@gmx.net writes:
Here is a problem: If I write an hstore-ng extension, I have two
In the patch for Finer Extension Dependencies, the offer is that you
have the hstore-ng extension provide the 'hstore' feature.
https://commitfest.postgresql.org/action/patch_view?id=727
On Wed, Sep 26, 2012 at 8:25 AM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 26.09.2012 16:51, Jeff Janes napsal:
What is generating the endless stream you are seeing is that you have
1000 databases so if naptime is one minute you are vacuuming 16 per
second. Since every database gets a new
Marko Kreen mark...@gmail.com writes:
Can we work out a minimal example to reproduce the bug?
Yes, the above text or sql/pgq_coop/sql/pgq_coop_init_ext.sql
I guess you could replace pgq_coop with any extension just
consisting of just functions.
I did just that, with a single function, and
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Euler Taveira's message of mié sep 26 11:53:27 -0300 2012:
On 26-09-2012 09:43, Tomas Vondra wrote:
5) splitting the single stat file into multiple pieces - e.g. per database,
written separately, so that the autovacuum workers
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
fallback is to use the type's string representation, as now.
2. add a cast hstore - json
On Wed, Sep 26, 2012 at 9:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Euler Taveira's message of mié sep 26 11:53:27 -0300 2012:
On 26-09-2012 09:43, Tomas Vondra wrote:
5) splitting the single stat file into multiple pieces - e.g.
Andrew Dunstan and...@dunslane.net writes:
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
fallback is to use the type's string
On 09/26/2012 01:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
On Sat, Sep 22, 2012 at 06:08:19PM -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On 09/22/2012 11:49 PM, Andrew Dunstan wrote:
Not really, I guess we should for the sake of consistency, although TBH
I find it just useless noise and rather wish we hadn't started the
On Mon, Sep 24, 2012 at 03:55:35PM -0700, Josh Berkus wrote:
On 9/24/12 3:43 PM, Simon Riggs wrote:
On 24 September 2012 17:36, Josh Berkus j...@agliodbs.com wrote:
For me, the Postgres user interface should include
* REINDEX CONCURRENTLY
I don't see why we don't have REINDEX
I'm marking this patch Ready for Committer. I suggest backpatching it to 9.2;
the patch corrects an oversight in 9.2 changes. There's more compatibility
value in backpatching than in retaining distinct behavior for 9.2 only.
On Thu, Jun 28, 2012 at 09:32:41AM -0700, Josh Kupershmidt wrote:
!
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
I think I just got bitten hard by a commit in mid July... git sha1 3855968.
In some of our old tables going back several years we a column named
'event' as in:
CREATE TABLE tblaudittrail (
id bigint NOT NULL,
siteid integer NOT NULL,
entrytype character varying(25),
form
On 27/09/12 02:59, Christopher Browne wrote:
On Wed, Sep 26, 2012 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
The definition of information_schema.triggers contains this:
On 26.9.2012 18:29, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Euler Taveira's message of miĂŠ sep 26 11:53:27 -0300 2012:
On 26-09-2012 09:43, Tomas Vondra wrote:
5) splitting the single stat file into multiple pieces - e.g. per database,
written
On 26.9.2012 18:14, Jeff Janes wrote:
On Wed, Sep 26, 2012 at 8:25 AM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 26.09.2012 16:51, Jeff Janes napsal:
What is generating the endless stream you are seeing is that you have
1000 databases so if naptime is one minute you are vacuuming 16 per
second.
On Sat, 2012-09-01 at 00:29 -0400, Tom Lane wrote:
this is a spec-defined syntax so surely the SQL standard ought to tell
us what to do. But I'm darned if I see anything in the standard that
defines the actual *behavior* of a LATERAL query.
I have it another read and couldn't find anything
Brian Weaver cmdrcluel...@gmail.com writes:
In some of our old tables going back several years we a column named
'event' as in:
event character varying(1000)
I was working off trunk and the database refuses to create this table
any longer. Is this by design or is it a regression bug?
I was able to patch the 9.2.0 code base in 1 day and change my entire
architecture strategy for replication
into self healing async master-master-master and the tiniest bit of
sharding code imaginable
Sounds cool. Do you have a fork available on Github? I'll try it out.
--
Josh Berkus
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-01 at 00:29 -0400, Tom Lane wrote:
this is a spec-defined syntax so surely the SQL standard ought to tell
us what to do. But I'm darned if I see anything in the standard that
defines the actual *behavior* of a LATERAL query.
I have it
Yes that is correct. I thought timeline change happens only when somebody
does PITR.
Can you please tell me why we change timeline after promotion, because the
original
Timeline concept was for PITR and I am not able to trace from code the
reason
why on promotion it is required?
I've had it with mopping up after oversights like this one:
http://archives.postgresql.org/pgsql-hackers/2012-09/msg01057.php
We made a script (src/tools/check_keywords.pl) to check for this type of
error years ago, and even added it to the top-level maintainer-check
target awhile back, but
Josh:
The good part is you are the first person to ask for a copy
and I will send you the hook code that I have and you can be a good sport
and put it on GitHub, that is great, you can give us both credit for a
joint effort, I do the code,
you put it GitHub.
The not so good part is that the
On 09/26/2012 09:16 PM, Tom Lane wrote:
I've had it with mopping up after oversights like this one:
http://archives.postgresql.org/pgsql-hackers/2012-09/msg01057.php
We made a script (src/tools/check_keywords.pl) to check for this type of
error years ago, and even added it to the top-level
On Tue, Sep 25, 2012 at 05:36:54PM +0300, Devrim Gunduz wrote:
Hi,
I just performed a test upgrade from 9.1 to 9.2, and used --new-port
variable. However, the analyze_new_cluster.sh does not include the new
port, thus when I run it, it fails. Any chance to add the port number to
the
On Mon, Sep 24, 2012 at 10:57:02AM +, Amit kapila wrote:
Rebased version of patch based on latest code.
I like the direction you're taking with this patch; the gains are striking,
especially considering the isolation of the changes.
You cannot assume executor-unmodified columns are also
I checked this patch. It looks good, but here are still some points to be
discussed.
* I have a question. What is the meaning of INT64_IS_BUSTED?
It seems to me a marker to indicate a platform without 64bit support.
However, the commit 901be0fad4034c9cf8a3588fd6cf2ece82e4b8ce
says as
Hi Alvaro,
Let me volunteer for reviewing, of course, but now pgsql_fdw is in my queue...
If some other folks can also volunteer it soon, it is welcome.
2012/9/26 Alvaro Herrera alvhe...@2ndquadrant.com:
Excerpts from Alvaro Herrera's message of mié sep 26 13:04:34 -0300 2012:
Excerpts from
On Thursday, September 27, 2012 6:30 AM Josh Berkus wrote:
Yes that is correct. I thought timeline change happens only when
somebody
does PITR.
Can you please tell me why we change timeline after promotion,
because the
original
Timeline concept was for PITR and I am not able to
Noah Misch n...@leadboat.com writes:
You cannot assume executor-unmodified columns are also unmodified from
heap_update()'s perspective. Expansion in one column may instigate TOAST
compression of a logically-unmodified column, and that counts as a change for
xlog delta purposes.
Um ... what
On Thursday, September 27, 2012 10:19 AM
Noah Misch n...@leadboat.com writes:
You cannot assume executor-unmodified columns are also unmodified
from
heap_update()'s perspective. Expansion in one column may instigate
TOAST
compression of a logically-unmodified column, and that counts as
67 matches
Mail list logo
