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 column of this
> type.
> > Here is what happens:
>
> >
> 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 column of this type.
> Here is what happens:
> postgresql=> explain analyze UPDATE attribute_type_conf SET rowform =
On Saturday, April 06, 2013 12:38 AM Robert Haas wrote:
> On Fri, Apr 5, 2013 at 1:12 AM, Amit Kapila
> wrote:
> > If we just put it to freelist, then next time if it get allocated
> directly
> > from bufhash table, then who will remove it from freelist
> > or do you think that, in BufferAlloc, if
On Fri, 2013-04-05 at 23:44 +0100, Peter Geoghegan wrote:
> On Fri, Apr 5, 2013 at 11:39 PM, Andres Freund wrote:
> > The respective macro magic is already in place, its just not used in all
> > places. The problem is more that we can't easily use it in all places
> > because e.g. in the one case
On Fri, 2013-04-05 at 18:14 -0400, Tom Lane wrote:
> Since gcc 4.8 is going to be on a lot of people's machines pretty
> soon,
> I think we need to do something to prevent it from breaking 8.4.x and
> 9.0.x. It looks like our choices are (1) teach configure to enable
> -fno-aggressive-loop-optimiz
On Fri, Apr 5, 2013 at 7:39 PM, Jeff Davis wrote:
> On Fri, 2013-04-05 at 19:22 -0500, Jaime Casanova wrote:
>> On Fri, Apr 5, 2013 at 8:09 AM, Andres Freund wrote:
>> >
>> > How does the attached version look? I verified that it survives
>> > recovery, but not more.
>> >
>>
>> I still got errors
On Fri, 2013-04-05 at 19:22 -0500, Jaime Casanova wrote:
> On Fri, Apr 5, 2013 at 8:09 AM, Andres Freund wrote:
> >
> > How does the attached version look? I verified that it survives
> > recovery, but not more.
> >
>
> I still got errors when executing make installcheck in a just compiled
> 9.3d
On Fri, Apr 5, 2013 at 8:09 AM, Andres Freund wrote:
>
> How does the attached version look? I verified that it survives
> recovery, but not more.
>
I still got errors when executing make installcheck in a just compiled
9.3devel + this_patch, this is when setting wal_level higher than
minimal.
At
On Fri, Apr 05, 2013 at 11:17:30AM +0200, Nicolas Barbier wrote:
> 2013/4/5 Noah Misch :
> > On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
> >> +1. Having unlogged matviews without having incremental updates yet,
> >> isn't super useful anyway.
> >
> > I would have surmised the o
On Fri, 2013-04-05 at 10:34 +0200, Florian Pflug wrote:
> Maybe we could scan forward to check whether a corrupted WAL record is
> followed by one or more valid ones with sensible LSNs. If it is,
> chances are high that we haven't actually hit the end of the WAL. In
> that case, we could either log
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 your current patch), regardless of
the current settings
- take W
On Fri, Apr 5, 2013 at 11:50 PM, Tom Lane wrote:
> Hm, I see 4 places in HEAD. But in any case, is
My mistake. I had REL9_2_STABLE checked out.
> int16values[1];/* VARIABLE LENGTH ARRAY */
> } int2vector; /* VARIABLE LENGTH STRUCT */
>
> really better th
Peter Geoghegan writes:
> Are you proposing that we use the FLEXIBLE_ARRAY_MEMBER macro in every
> single place where we currently use the one element array pattern?
Yup, exactly.
> I count one place where we currently use FLEXIBLE_ARRAY_MEMBER. It'd be
> pretty ugly to have that everywhere, in
Andres Freund writes:
> The respective macro magic is already in place, its just not used in all
> places. The problem is more that we can't easily use it in all places
> because e.g. in the one case mentioned here the array isn't in the last
> place *in the back branches*.
I don't think we shoul
On Fri, Apr 5, 2013 at 11:39 PM, Andres Freund wrote:
> The respective macro magic is already in place, its just not used in all
> places. The problem is more that we can't easily use it in all places
> because e.g. in the one case mentioned here the array isn't in the last
> place *in the back br
Kevin Grittner wrote:
> I think a large part of what is at issue here stems from a bad
> name for the new bool field I added to the RelationData structure
> -- instead of rd_isscannable it should probably be called
> something like rd_ispopulated. The current name led to some
> fuzzy thinking on
On 2013-04-05 23:28:03 +0100, Peter Geoghegan wrote:
> On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane wrote:
> > It also strikes me that we ought to take this as a warning sign
> > that we need to work on getting rid of coding like the above in favor
> > of genuine "flexible arrays", before the gcc boy
Peter Geoghegan writes:
> On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane wrote:
>> It also strikes me that we ought to take this as a warning sign
>> that we need to work on getting rid of coding like the above in favor
>> of genuine "flexible arrays", before the gcc boys think of some other
>> overly
On 06/04/13 11:14, Tom Lane wrote:
After quite a bit of hair-pulling trying to install Fedora 19 Alpha,
I've been able to reproduce the initdb-time failure that's currently
being seen on buildfarm member anchovy, and was also complained of
recently by an end user:
http://www.postgresql.org/messag
On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane wrote:
> It also strikes me that we ought to take this as a warning sign
> that we need to work on getting rid of coding like the above in favor
> of genuine "flexible arrays", before the gcc boys think of some other
> overly-cute optimization based on the
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 column of this type.
Here is what happens:
postgresql=> explain analyze UPDATE attribute_type_conf SET rowform =
rowform +1 where rowform <= 18;
ERROR: unsupported type: 132852
postg
After quite a bit of hair-pulling trying to install Fedora 19 Alpha,
I've been able to reproduce the initdb-time failure that's currently
being seen on buildfarm member anchovy, and was also complained of
recently by an end user:
http://www.postgresql.org/message-id/CAOD=oq-kq3eg5sovryovxduqibvwc8r
Hi Guys,
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().
Diff attached.
formatting_dead_code.diff
Description: Binary data
--
GJ
--
Sent via pgsql-hackers
Jeff Davis wrote:
> My opinion is that we don't need to be perfect as long as we
> catch 99% of random errors and we don't have any major blind
> spots.
+1
> 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 sl
On Fri, 2013-04-05 at 21:39 +0300, Ants Aasma wrote:
> Yes, I just managed to get myself some time so I can look at it some
> more. I was hoping that someone would weigh in on what their
> preferences are on the performance/effectiveness trade-off and the
> fact that we need to use assembler to mak
On 4/5/13 12:23 PM, Jeff Davis wrote:
Are you still looking into SIMD? Right now, it's using the existing CRC
implementation. Obviously we can't change it after it ships. Or is it
too late to change it already?
Simon just headed away for a break, so I'll try to answer this. He
committed with
On Fri, Apr 5, 2013 at 1:12 AM, Amit Kapila wrote:
> If we just put it to freelist, then next time if it get allocated directly
> from bufhash table, then who will remove it from freelist
> or do you think that, in BufferAlloc, if it gets from bufhash table, then it
> should verify if it's in free
On Fri, Apr 5, 2013 at 7:23 PM, Jeff Davis wrote:
> On Tue, 2013-03-26 at 03:34 +0200, Ants Aasma wrote:
>> The main thing to look out for is that we don't
>> have any blind spots for conceivable systemic errors. If we decide to
>> go with the SIMD variant then I intend to figure out what the blin
On Apr 4, 2013, at 2:11 PM, Tom Lane wrote:
> I think this should be addressed in extend.sgml not only on the CREATE
> EXTENSION reference page. After thinking awhile I came up with the
> attached wording. Further wordsmithing anyone?
Works for me, though I think it would be useful to have a t
On Tue, 2013-03-26 at 03:34 +0200, Ants Aasma wrote:
> The main thing to look out for is that we don't
> have any blind spots for conceivable systemic errors. If we decide to
> go with the SIMD variant then I intend to figure out what the blind
> spots are and show that they don't matter.
Are you
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 array, however.
--
Kevin Grittner
EnterpriseDB: http://www.
Kevin Grittner wrote:
> I think I need to review the whole thread again to make sure I
> wasn't too quick to concede the point.
On a fresh reading of this, I think a large part of what is at
issue here stems from a bad name for the new bool field I added to
the RelationData structure -- instead
On Fri, Apr 05, 2013 at 07:00:38AM -0700, Kevin Grittner wrote:
> Noah Misch wrote:
>
> > The SQL commands I cited as responsible for creating or removing
> > the fork all make a new relfilenode anyway. Thus, "add" actually
> > means creating the fork with the new relfilenode, and "remove"
> > a
Noah Misch wrote:
> The SQL commands I cited as responsible for creating or removing
> the fork all make a new relfilenode anyway. Thus, "add" actually
> means creating the fork with the new relfilenode, and "remove"
> actually means omitting the fork from the new relfilenode. The
> association
Noah Misch wrote:
> On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
>> +1. Having unlogged matviews without having incremental updates
>> yet, isn't super useful anyway.
>
> I would have surmised the opposite
Hmm. I was thinking about the fact that a full refresh can be
unlogge
Tom Lane wrote:
> I realize that there's no other (easy) way to make unlogged
> matviews reset to an invalid state on crash, but that doesn't
> make this design choice less of a disaster. It boxes us into
> something that's entirely unable to support transitions between
> scannable and unscannab
On Thu, Apr 4, 2013 at 8:26 AM, Kohei KaiGai wrote:
> OK, I follow the manner of the terminology as we usually call it.
> The attached patch just replaced things you suggested.
Thanks, I have committed this, after making some changes to the
comments and documentation. Please review the changes a
On 2013-04-04 17:39:16 -0700, Jeff Davis wrote:
> On Thu, 2013-04-04 at 22:39 +0200, Andres Freund wrote:
> > I don't think its really slower. Earlier the code took WalInsertLock
> > everytime, even if we ended up not logging anything. Thats far more
> > epensive than a single spinlock. And the cop
* Matthias (nitrogen...@gmail.com) wrote:
> >In this example, hashing the large table is actually 2 seconds *faster*
> >than hashing the small table (again, all on my laptop).
>
> Are you running the laptop on battery? When I've benchmarked pgsql
> last time I used my laptop as well and it only oc
On Thu, Apr 04, 2013 at 06:07:17PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Apr 03, 2013 at 05:49:18PM -0400, Tom Lane wrote:
> >> No. This is an absolute disaster. It's taking something we have always
> >> considered to be an irrelevant implementation detail and making it into
>
In this example, hashing the large table is actually 2 seconds *faster*
than hashing the small table (again, all on my laptop).
Are you running the laptop on battery? When I've benchmarked pgsql last
time I used my laptop as well and it only occured to me after a lot of
trying that laptops (
2013/4/5 Noah Misch :
> On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
>
>> +1. Having unlogged matviews without having incremental updates yet,
>> isn't super useful anyway.
>
> I would have surmised the opposite: since an unlogged MV requires a full
> refresh at unpredictable m
On Apr4, 2013, at 23:21 , Jeff Janes wrote:
> This brings up a pretty frightening possibility to me, unrelated to data
> checksums. If a bit gets twiddled in the WAL file due to a hardware issue or
> a "cosmic ray", and then a crash happens, automatic recovery will stop early
> with the failed
Tom Lane writes:
> I think this should be addressed in extend.sgml not only on the CREATE
> EXTENSION reference page. After thinking awhile I came up with the
> attached wording. Further wordsmithing anyone?
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formatio
Alvaro Herrera writes:
> Now, it annoys me that we now have three places that know about object
> types supported by event triggers: there's a large struct of command tag
> substrings (event_trigger_support), then there's these two functions.
> It might be better to add ObjectType and ObjectClass
Brendan Jurd writes:
> Well for what it's worth I would expect cardinality() to return the
> total number of elements in the array (per ArrayGetNItems). It's
> consistent with the spec's identification of an array as a
> "collection". You can chunk the elements into dimensions however you
> want
46 matches
Mail list logo
