On Thursday, September 27, 2012 10:19 AM
> Noah Misch 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
> chan
Noah Misch 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 about BEFORE t
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 no
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 :
> Excerpts from Alvaro Herrera's message of mié sep 26 13:04:34 -0300 2012:
>> Excerpts from Kohei KaiGai's message
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 follows
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 unm
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 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 "mai
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 co
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 none
> 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 requi
Peter Eisentraut 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 another
> 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 Berku
Brian Weaver 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?
It's a bug. The even
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
On 26.9.2012 18:14, Jeff Janes wrote:
> On Wed, Sep 26, 2012 at 8:25 AM, Tomas Vondra 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
>>> secon
On 26.9.2012 18:29, Tom Lane wrote:
> Alvaro Herrera 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 t
On 27/09/12 02:59, Christopher Browne wrote:
On Wed, Sep 26, 2012 at 10:02 AM, Tom Lane wrote:
Daniel Farina writes:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova wrote:
The definition of information_schema.triggers contains this:
-- TRIGGER_TYPE_UPDATE; we intentionally omit TRIGGER_TYP
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 character
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan 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
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 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 wrote:
> >>
> For me, the Postgres user interface should include
> * REINDEX CONCURRENTLY
> >>
> >> I don't see why we don't have REINDEX CONC
On Sat, Sep 22, 2012 at 06:08:19PM -0400, Tom Lane wrote:
> Hannu Krosing 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
> >> trend when
On 09/26/2012 01:46 PM, Tom Lane wrote:
Andrew Dunstan 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 typ
Andrew Dunstan 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 representation, as now
On Wed, Sep 26, 2012 at 9:29 AM, Tom Lane wrote:
> Alvaro Herrera 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 separate
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
Alvaro Herrera 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 don't need to read a
Marko Kreen 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 couldn't rep
On Wed, Sep 26, 2012 at 8:25 AM, Tomas Vondra 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 process, t
Peter Eisentraut 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
Now, that s
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 getti
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
On Wed, Sep 26, 2012 at 5:36 PM, Dimitri Fontaine
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 pgq_coop;
>> cr
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
Dne 26.09.2012 16:51, Jeff Janes napsal:
On Wed, Sep 26, 2012 at 5:43 AM, Tomas Vondra 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 ca
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 http://www.timbira.co
On Wed, Sep 26, 2012 at 10:02 AM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova
>> wrote:
>>> The definition of information_schema.triggers contains this:
>>> -- TRIGGER_TYPE_UPDATE; we intentionally omit TRIGGER_TYPE_TRUNCATE
>>> so it seems that w
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
On 26 September 2012 15:02, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova
>> wrote:
>>> The definition of information_schema.triggers contains this:
>>> -- TRIGGER_TYPE_UPDATE; we intentionally omit TRIGGER_TYPE_TRUNCATE
>>> so it seems that we are
On Wed, Sep 26, 2012 at 5:43 AM, Tomas Vondra 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 application - ye
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 Herre
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 mak
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 "
Hi,
After much distractions I've at least been able to do something about
that bug report.
Marko Kreen 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 reproduce that i
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 al
Antonin Houska 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?
> 1. Add a new varlena
On 09/25/2012 08:56 PM, Robert Haas wrote:
On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing u
"Albe Laurenz" 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.
I can't get
Daniel Farina writes:
> On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova
> 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 triggers intentionally,
>> but
On Mon, Sep 24, 2012 at 9:18 PM, Stephen Frost 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 "oid" in the
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 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
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,
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
On Wed, Sep 26, 2012 at 8:13 PM, Andres Freund wrote:
> On Tuesday, September 25, 2012 01:48:34 PM Michael Paquier wrote:
> > On Tue, Sep 25, 2012 at 5:55 PM, Andres Freund >wrote:
> > > On Tuesday, September 25, 2012 04:37:05 AM Michael Paquier wrote:
> > > > On Tue, Sep 25, 2012 at 8:13 AM, And
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 wrote:
Hi there,
we tried to create the libpqtypes enum binary send but it doesn't work:
// register types
PGregisterType user_def[] = { {"seq
On 09/26/2012 03:08 AM, Daniel Farina wrote:
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova wrote:
On Wed, Sep 26, 2012 at 12:17 AM, Daymel Bonne Solís wrote:
Hello hackers:
I need a list of all triggers created in my database, but the view
system_information.triggers does not show truncat
On Tuesday, September 25, 2012 01:48:34 PM Michael Paquier wrote:
> On Tue, Sep 25, 2012 at 5:55 PM, Andres Freund wrote:
> > On Tuesday, September 25, 2012 04:37:05 AM Michael Paquier wrote:
> > > On Tue, Sep 25, 2012 at 8:13 AM, Andres Freund > >
> > >wrote:
> > > Could you clarify what do you m
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 :
>> Last ent
On Wed, Sep 26, 2012 at 4:14 PM, Albe Laurenz wrote:
> Hitoshi Harada wrote:
> > On Tue, Sep 25, 2012 at 5:30 PM, Peter Eisentraut
> 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
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 th
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: "meta_version
Hitoshi Harada wrote:
> On Tue, Sep 25, 2012 at 5:30 PM, Peter Eisentraut
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 extent
>> hea
On Tue, Sep 25, 2012 at 10:55 PM, Jaime Casanova wrote:
> On Wed, Sep 26, 2012 at 12:17 AM, Daymel Bonne Solís wrote:
>> Hello hackers:
>>
>> I need a list of all triggers created in my database, but the view
>> system_information.triggers does not show truncate triggers, but it does for
>> inser
65 matches
Mail list logo
