[HACKERS] doc hdparm also support SATA

from the pg doc： http://www.postgresql.org/docs/devel/static/wal-reliability.html :On Linux, IDE drives can be queried using hdparm -I; write caching is enabled if there is a * next to Write cache. hdparm -W 0 can be used to turn off write caching. SCSI drives can be queried using sdparm

Re: [HACKERS] isolation test fails on installcheck

On Sun, Apr 7, 2013 at 12:54 AM, Jaime Casanova wrote: > On Sat, Apr 6, 2013 at 11:28 PM, Tom Lane wrote: >> Jaime Casanova writes: >>> On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane wrote: Curious though that we have not seen this in the buildfarm ... >> >>> anyway, your commit fix the pro

Re: [HACKERS] isolation test fails on installcheck

On Sat, Apr 6, 2013 at 11:28 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane wrote: >>> Curious though that we >>> have not seen this in the buildfarm ... > >> anyway, your commit fix the problem. thanks > > Thanks for confirming. What platform are you t

Re: [HACKERS] isolation test fails on installcheck

Jaime Casanova writes: > On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane wrote: >> Curious though that we >> have not seen this in the buildfarm ... > anyway, your commit fix the problem. thanks Thanks for confirming. What platform are you testing on, anyway? I'm still wondering why you saw it when t

Re: [HACKERS] isolation test fails on installcheck

On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane wrote: > Curious though that we > have not seen this in the buildfarm ... anyway, your commit fix the problem. thanks -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +5

Re: [HACKERS] Process title for autovac

On Sat, Apr 6, 2013 at 4:20 PM, Jeff Janes wrote: > I've often wanted to know what the autovacuum worker was doing. The process > title seems like the best place to get this information, but the process > title tells me what database it is in, but not what table it is working on. > > The attached

Re: [HACKERS] unused code in float8_to_char , formatting.c ?

On Thu, Apr 4, 2013 at 6:47 PM, Greg Jaskiewicz wrote: > Looking around the code Today, one of my helpful tools detected this dead > code. > As far as I can see, it is actually unused call to strlen() in formatting.c, > float8_to_char(). I poked at this a little and suggest the following somewh

Re: [HACKERS] isolation test fails on installcheck

Jaime Casanova writes: > I was running some tests, and noted $SUBJECT. > It fails consistently on current HEAD (without any patch). > ... > Attached regressions.diff, basically the fails give an error of > "select failed: Interrupted system call" Hm, looks to me like the select() error path at is

Re: [HACKERS] Unrecognized type error (postgres 9.1.4)

Ok! I will try to reproduce in a smaller scenario. On Sat, Apr 6, 2013 at 9:53 PM, Amit Kapila wrote: > On Saturday, April 06, 2013 12:18 PM Rodrigo Barboza wrote: > >On Sat, Apr 6, 2013 at 12:23 AM, Amit Kapila > wrote: > >> On Saturday, April 06, 2013 3:57 AM Rodrigo Barboza wrote: > > >>Hel

Re: [HACKERS] Back branches vs. gcc 4.8.0

On Fri, Apr 5, 2013 at 9:45 PM, Peter Eisentraut wrote: > So I think this is not a compiler bug or an arms race. We just need to > fix the code. So I'm in favor of backporting. I can certainly see this argument. I understand Tom's point about an arms race, but back-porting this doesn't feel te

Re: [HACKERS] Unrecognized type error (postgres 9.1.4)

On Saturday, April 06, 2013 12:18 PM Rodrigo Barboza wrote: >On Sat, Apr 6, 2013 at 12:23 AM, Amit Kapila wrote: >> On Saturday, April 06, 2013 3:57 AM Rodrigo Barboza wrote: >>Hello. >> I created a type my_uint that is a unsigned int 32. >> I am trying to update data of a table that contains a

Re: [HACKERS] Process title for autovac

On 07/04/13 08:20, Jeff Janes wrote: I've often wanted to know what the autovacuum worker was doing. The process title seems like the best place to get this information, but the process title tells me what database it is in, but not what table it is working on. The attached patch demonstrates t

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 04/04/2013 01:03 PM, Vibhor Kumar wrote: > I did some testing on this patch with 9.1 and 9.2 source code. Testing > included following: > 1. Configured PostGIS with 9.1 and 9.2 > 2. verified all switches of pg_dump with regression db. > 3. Checked other extensions, to verify if this impacting t

[HACKERS] pg_dump with postgis extension dumps rules separately

If I create a database and install postgis as an extension, and then run pg_dump I get this: [...] CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; [...] CREATE RULE geometry_columns_delete AS ON DELETE TO geometry_columns DO INSTEAD NOTHING; [...] Shouldn't that CREATE RULE be implicit

[HACKERS] Process title for autovac

I've often wanted to know what the autovacuum worker was doing. The process title seems like the best place to get this information, but the process title tells me what database it is in, but not what table it is working on. The attached patch demonstrates the concept of what I want. I put the c

[HACKERS] PROPOSAL: tracking aggregated numbers from pg_stat_database

Hi, I'm regularly using pg_stat_database view to analyze various aspects of behavior of the cluster. The #1 issue I'm constantly running into is that to get cluster-level view (across all the databases), the table needs to be aggregated like this: SELECT SUM(blks_hit) blks_hit,

[HACKERS] Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog

On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas wrote: > > Incidentally, I bumped into another custom backup script just a few weeks > back that also excluded backup_label. I don't know what the author was > thinking when he wrote that, but it seems to be a surprisingly common > mistake. Maybe

Re: [HACKERS] corrupt pages detected by enabling checksums

On Fri, Apr 5, 2013 at 6:09 AM, Andres Freund wrote: > How does the attached version look? I verified that it survives > recovery, but not more. > > Jeff, any chance you can run this for a round with your suite? > I've run it for a while now and have found no problems. Thanks, Jeff

Re: [HACKERS] Back branches vs. gcc 4.8.0

Peter Eisentraut writes: > The reason that the whole code wasn't converted right away was (besides > a lot of legwork with sizeof and offsetoff) that flexible array members > aren't allowed in the middle of structs. Which eventually led to the > mentioned commit 8137f2c32322c624e0431fac1621e8e931

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-05 16:29:47 -0700, Jeff Davis wrote: > On Fri, 2013-04-05 at 15:09 +0200, Andres Freund wrote: > > How does the attached version look? I verified that it survives > > recovery, but not more. > > Comments: > > * Regarding full page writes, we can: > - always write full pages (as in yo

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd wrote: > On 6 April 2013 01:59, Kevin Grittner wrote: >> Brendan Jurd wrote: >> >>> The language specifically allows for zero elements, and does not >>> contemplate multiple dimensions. >> >> I don't remember anything in the spec which would prohibit the data >> type of an array ele

[HACKERS] Fwd: Range types (DATERANGE, TSTZRANGE) in a foreign key with "inclusion" logic

Hello, this is a re-post from the SQL user list 2 month ago, because I assume only a developer can answer the questions below. Thanks, Matthias Nagel -- Weitergeleitete Nachricht -- Betreff: Range types (DATERANGE, TSTZRANGE) in a foreign key with "inclusion" logic Datum: Mit

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 6 April 2013 01:59, Kevin Grittner wrote: > Brendan Jurd wrote: > >> The language specifically allows for zero elements, and does not >> contemplate multiple dimensions. > > I don't remember anything in the spec which would prohibit the data > type of an array element from itself being an arra

Re: [HACKERS] Enabling Checksums

On 05.04.2013 23:25, Kevin Grittner wrote: Jeff Davis wrote: Also, the first version doesn't necessarily need to perform well; we can leave optimization as future work. +1, as long as we don't slow down instances not using the feature, and we don't paint ourselves into a corner. Speaking of