On Fri, Aug 7, 2009 at 11:33 PM, Bruce Momjian wrote:
> Third, Robert, you should have communicated to the list that you were
> going to work on the patch, so that there would not be duplicate effort
> if someone else was also working on it. As I understood it, Heikki was
> in control of the patch
2009/8/8 Bruce Momjian :
> Just to verify, this patch was about comments on composite columns, not
> about dumping comments on index columns (as the subject states), right?
> We do have a TODO for index column comments:
Correct.
If you scroll up a couple of messages [1] you'll see that I added th
Tom Lane wrote:
> Brendan Jurd writes:
> > I've also done an initial review of the patch. Everything looks sane
> > and the patch works as advertised. I made a couple of minor tweaks
> > for code-style and comment consistency, and my version 3 is attached.
>
> > I'm marking this patch Ready for
Robert Haas wrote:
> On Fri, Aug 7, 2009 at 11:33 PM, Bruce Momjian wrote:
> > Third, Robert, you should have communicated to the list that you were
> > going to work on the patch, so that there would not be duplicate effort
> > if someone else was also working on it. ?As I understood it, Heikki wa
On Aug 7, 2009, at 11:50 PM, Bruce Momjian wrote:
David Fetter wrote:
Odds are that the patch submitters will not understand enough to
know how to modify pg_migrator, but just knowing something broke is
usually enough for the hackers group to find a fix.
This is a pretty serious drawback. I
David Fetter wrote:
> > Odds are that the patch submitters will not understand enough to
> > know how to modify pg_migrator, but just knowing something broke is
> > usually enough for the hackers group to find a fix.
>
> This is a pretty serious drawback. If we're going to require that
> people s
Paul Matthews wrote:
> EPSILON in postgres is 1.0E-06
> EPSILON for floats is 1.19209e-07
> EPSILON for doubles is 2.22045E-016
>
Bad form to reply to my own post and all. If EPSILON for double
represented 1mm, then postgres is rounding to the nearest 10,000,000 km.
Since its only about 38
Joshua D. Drake wrote:
> On Wed, 2009-07-15 at 17:27 +0100, Simon Riggs wrote:
> > On Tue, 2009-07-14 at 21:12 -0400, Robert Haas wrote:
> > >
>
> > It's going to be very confusing if people submit their own versions of
> > it. So now we have mine, Heikki's and Robert's. I'd like this to stop
> >
As we are now into the last week of this CommitFest (hopefully), I
have moved all of the patches that were listed as "Waiting on Author"
to "Returned with Feedback". I feel pretty good about doing this
because most of these patches have been waiting on author for a long
time, or they were reviewed
I am sorry I forgot to write my opinion on these.
Do we want to differentiate views from tables in these commands or not ?
I'd like to have views separate but I don't feel strongly about it.
However having single statement for TABLE, VIEW and SEQUENCE is not a
good idea IMHO, it will add confus
Tom Lane wrote:
> No, I'm worried about code that supposes that it can divide by (x - y)
> after testing that FPeq(x,y) is not true. point_sl() for instance.
>
> We could perhaps fix those specific issues by testing the difference
> explicitly instead of doing it like that. But there's still the
Tom Lane wrote:
> It's a hack but it's dealing with an extremely real problem, namely
> the built-in inaccuracy of floating-point arithmetic. You can't just
> close your eyes to that and hope that everything will be okay.
>
If the above statement was true, then the FP* macros should be extended
Michael Paquier writes:
> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
> 2PC
> by sending the state files of prepared transactions to shared memory instead
> of disk.
I don't understand how this can possibly work. The entire point of
2PC is that the state file is g
Tom Lane wrote:
David Fetter writes:
I am not suggesting that this change be immediate, and it's not ivory
tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
about the development practices of Oracle, or DB2, or eve
David Fetter writes:
> I am not suggesting that this change be immediate, and it's not ivory
> tower. It's just how everybody else does it.
You keep saying that, and it's completely meaningless. What do you know
about the development practices of Oracle, or DB2, or even Mysql?
On Fri, Aug 07, 2009 at 06:02:32PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > I think it's a lot more nebulous than that. At the same time I think the
> > days when we can blithely change the on-disk format with hardly a
> > thought for migration are over. IOW, there's agreement things
Alvaro Herrera writes:
> Is there any reason we didn't move the pg_freespace function from
> contrib to core?
Is there a reason we *should* move it? The current definition doesn't
leave me feeling that it's more than a low-level hacker's tool.
regards, tom lane
--
Sent
Andrew Dunstan writes:
> I think it's a lot more nebulous than that. At the same time I think the
> days when we can blithely change the on-disk format with hardly a
> thought for migration are over. IOW, there's agreement things have to
> change, but the exact shape of the change is not yet cl
Hi,
Is there any reason we didn't move the pg_freespace function from
contrib to core?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Neil Best writes:
> On Fri, Aug 7, 2009 at 12:33 PM, Tom Lane wrote:
>> BTW, the "SSL renegotiation failure" bit
>> suggests that it could have been an OpenSSL bug not a real network
>> lossage, so you might want to see how up-to-date your openssl libraries
>> are.
> Thanks for your comments, Tom
Олег Царев escribió:
> Hello all!
> If no one objecte (all agree, in other say) i continue work on patch -
> particulary, i want support second strategy (tuple store instead of
> hash-table) for save order of source (more cheap solution in case with
> grouping sets + order by), investigate and brai
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> It looks like you've got a corrupted page in shared buffers, and every
>> time the system tries to flush it to disk for a checkpoint, it fails.
> Will the database be able to restart with a corrupted WAL?
I don't think you have a corrupted WAL.
Alvaro Herrera wrote:
David Fetter wrote:
This is a pretty serious drawback. If we're going to require that
people send migration scripts when they change the on-disk format,
this needs to be easy.
But, are we?
I think it's a lot more nebulous than that. At the same time I th
On Fri, Aug 07, 2009 at 05:32:13PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > This is a pretty serious drawback. If we're going to require that
> > people send migration scripts when they change the on-disk format,
> > this needs to be easy.
>
> But, are we?
This is an area where
David Fetter wrote:
> This is a pretty serious drawback. If we're going to require that
> people send migration scripts when they change the on-disk format,
> this needs to be easy.
But, are we?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Compa
On Fri, Aug 07, 2009 at 04:07:08PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> > > David Fetter writes:
> > > > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> > > >> And I doubt we'd bother generating pg_migrator bu
On Fri, Aug 7, 2009 at 12:33 PM, Tom Lane wrote:
> BTW, the "SSL renegotiation failure" bit
> suggests that it could have been an OpenSSL bug not a real network
> lossage, so you might want to see how up-to-date your openssl libraries
> are.
Thanks for your comments, Tom. The operation seems more
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Bruce asked me to look for places in the docs that mention that an
> > > ANALYZE is recommended, to mention the possibility that autovacuum takes
> > > care. This patch does that.
> >
> > I think you found the right places
Tom Lane wrote:
Emmanuel Cecchet writes:
I got an error like this:
ERROR: xlog flush request 1/C121E998 is not satisfied --- flushed only to
1/BCBCB440
CONTEXT: writing block 529 of relation 1663/233690/1247
WARNING: could not write block 529 of 1663/233690/1247
DETAIL: Multi
"Kevin Grittner" writes:
> Robert Haas wrote:
>> So should we give up on this patch?
> No, this is not news; just confirmation of the earlier gut feelings
> and less convincing statistics that there is no problem. Tom's
> argument that if there's no slowdown for common cases, preventing
> O(N
Emmanuel Cecchet writes:
> I got an error like this:
> ERROR: xlog flush request 1/C121E998 is not satisfied --- flushed only to
> 1/BCBCB440
> CONTEXT: writing block 529 of relation 1663/233690/1247
> WARNING: could not write block 529 of 1663/233690/1247
> DETAIL: Multiple failures --- wri
I wrote:
> I remember someone else on the thread saying [...]
> it provided better structure for future enhancements.
Found the reference:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg00078.php
This was the email which I thought confirmed that the changes were
worth it, even in
Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> That might be a bit excessive. As I understand it, arrays of built-in
> >> types
> >> (e.g., int[]) should work fine. I suspect the majority of uses of arrays
> >> will
> >> be with built-in types, so allowing that would
David Fetter wrote:
> On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> > >> And I doubt we'd bother generating pg_migrator builds that work
> > >> for pairs of alpha releases.
> >
> > > That's an i
Tom Lane wrote:
> Magnus Hagander writes:
> > I haven't actually looked into pg_migrator enough to know how likely
> > it is that it'll "just work" going alpha->alpha when there have only
> > been "normal" changes? How invasive are the changes that actually
> > require pg_migrator to be touched at
Magnus Hagander wrote:
> > The bug-fixing situation for betas and RCs is a bit different because
> > it's expected that there will be a compatible update available shortly.
> > So you can usually assume that updating to the next beta/RC/release will
> > fix whatever problems got found. ?Alphas are
Alvaro Herrera wrote:
> David Fetter wrote:
>
> > Is it strictly necessary that its release cycles match exactly those
> > of the database engine, or would it be OK for it to release as needed,
> > not triggering a major PostgreSQL release?
>
> Well, pg_migrator already released an 8.4.1 ...
Wel
Tom Lane wrote:
> Peter Eisentraut writes:
> > Is there a good reason for $subject, other than that the code is entangled
> > with other ALTER TABLE code?
>
> I think it could be lower, but it would take nontrivial restructuring of
> the ALTER TABLE support. In particular, consider what happens
Robert Haas wrote:
> On Mon, Aug 3, 2009 at 2:07 PM, David Fetter wrote:
> > On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> >> David Fetter writes:
> >> > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> >> >> And I doubt we'd bother generating pg_migrator builds that work
On Fri, Aug 7, 2009 at 3:36 PM, Sam Mason wrote:
> On Fri, Aug 07, 2009 at 03:18:54PM -0400, Robert Haas wrote:
>> On Fri, Aug 7, 2009 at 3:08 PM, Kevin Grittner
>> wrote:
>> > With the 20 samples from that last round of tests, the answer (rounded
>> > to the nearest percent) is 60%, so "probably
Robert Haas wrote:
> So should we give up on this patch?
No, this is not news; just confirmation of the earlier gut feelings
and less convincing statistics that there is no problem. Tom's
argument that if there's no slowdown for common cases, preventing
O(N^2) behavior for extreme cases is c
Hi,
I got an error like this:
ERROR: xlog flush request 1/C121E998 is not satisfied --- flushed only to
1/BCBCB440
CONTEXT: writing block 529 of relation 1663/233690/1247
WARNING: could not write block 529 of 1663/233690/1247
DETAIL: Multiple failures --- write error might be permanent.
Th
On Fri, Aug 07, 2009 at 03:18:54PM -0400, Robert Haas wrote:
> On Fri, Aug 7, 2009 at 3:08 PM, Kevin Grittner
> wrote:
> > With the 20 samples from that last round of tests, the answer (rounded
> > to the nearest percent) is 60%, so "probably noise" is a good summary.
>
> So should we give up on
On Fri, Aug 07, 2009 at 02:08:21PM -0500, Kevin Grittner wrote:
> With the 20 samples from that last round of tests, the answer (rounded
> to the nearest percent) is 60%, so "probably noise" is a good summary.
> Combined with the 12 samples from earlier comparable runs with the
> prior version of t
On Fri, Aug 7, 2009 at 3:08 PM, Kevin
Grittner wrote:
> Sam Mason wrote:
>
>> All we're saying is that we're less than 90% confident that there's
>> something "significant" going on. All the fiddling with standard
>> deviations and sample sizes is just easiest way (that I know of)
>> that statist
Sam Mason wrote:
> All we're saying is that we're less than 90% confident that there's
> something "significant" going on. All the fiddling with standard
> deviations and sample sizes is just easiest way (that I know of)
> that statistics currently gives us of determining this more formally
>
On Fri, Aug 07, 2009 at 07:48:15PM +0100, Greg Stark wrote:
> On Fri, Aug 7, 2009 at 7:13 PM, Tom Lane wrote:
> > Underflow. x!=y does not imply (x-y) != 0, if x and y are sufficiently
> > small and close together. The difference could underflow to zero.
>
> Actually I don't think subtraction ca
Stephen Frost wrote:
As for changing the
default ACL syntax to not be based around SCHEMA- I'm concerned that
we'll then have to define some kind of ordering preference if we get
away from the defaults being associated with the container object. If
we have defaults for users and schemas, which t
Heikki Linnakangas writes:
> Tom Lane wrote:
>> So that confirms my speculation that btree index cleanup is the source
>> of the message. We have two basic approaches to dealing with it:
>>
>> 1. Decide that the check added to XLogInsert is wrong and take it out.
>>
>> 2. Arrange for some sort
On Fri, Aug 7, 2009 at 7:13 PM, Tom Lane wrote:
> Sam Mason writes:
>> On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
>>> No, I'm worried about code that supposes that it can divide by (x - y)
>>> after testing that FPeq(x,y) is not true. point_sl() for instance.
>
>> OK, but I'm still
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
> >> No, I'm worried about code that supposes that it can divide by (x - y)
> >> after testing that FPeq(x,y) is not true. point_sl() for instance.
>
> > OK
Tom Lane wrote:
> Alvaro Herrera writes:
>> Today we got a report in the spanish list about the message in $subject.
>> The server is 8.4 running on Windows.
>
> I accidentally managed to reproduce this in HEAD just now, by kill -9'ing
> a backend that was in the midst of a COPY IN operation (I w
Sam Mason writes:
> On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
>> No, I'm worried about code that supposes that it can divide by (x - y)
>> after testing that FPeq(x,y) is not true. point_sl() for instance.
> OK, but I'm still not sure what you're getting at.
Underflow. x!=y doe
Alvaro Herrera writes:
> Today we got a report in the spanish list about the message in $subject.
> The server is 8.4 running on Windows.
I accidentally managed to reproduce this in HEAD just now, by kill -9'ing
a backend that was in the midst of a COPY IN operation (I was trying to
reproduce Nei
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > Sorry, I'm struggling to parse that. I think it's all the double
> > negatives. Are you saying that HYPOT() should really return zero when
> > it's currently giving back would be FPzero?
>
> No, I'm worried about
I wrote:
> Hmm, so it looks like the connection dropped and libpq failed to
> recognize that, or maybe libpq was okay but psql needs to check a bit
> more carefully here. I'll take a look.
I could not reproduce this problem in testing, but after eyeballing
the code awhile I have a theory. It loo
On Fri, Aug 7, 2009 at 12:04 PM, Tom Lane wrote:
> There is definitely not enough evidence here to justify breaking
> existing applications, which is what introducing => would do.
> When and if there's a ratified standard using =>, it'll be time
> to break stuff. In the meantime we can do somethin
Hey folks,
West is upon us shortly. Get those talks in:
http://www.postgresqlconference.org/2009/west
Joshua D. Drake
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, ser
Tom Lane wrote:
> If you roll back a truncate, do you get the expected state?
I did a number of variations on the test below, with and without "on drop
commit",
and similar tests where the "create table" is done before the "begin". After
the
checkpoint, the number of files in the database d
Pierre,
> I added a field in PageHeader which contains :
> - 0 to indicate a non-compressed page
> - length of compressed data if compressed
>
> If compression gains nothing (ie gains less than 4K), the page is
> stored raw.
>
> It seems that only pages having a PageHeader ar
Sam Mason writes:
> Sorry, I'm struggling to parse that. I think it's all the double
> negatives. Are you saying that HYPOT() should really return zero when
> it's currently giving back would be FPzero?
No, I'm worried about code that supposes that it can divide by (x - y)
after testing that FP
On Fri, Aug 7, 2009 at 10:10, Todd A. Cook wrote:
> Alex Hunsaker wrote:
>> With double the number of files maybe something
>>
>> simple like turning on dir_index if you are ext3 will help?
>
> Thanks for the tip. Doing "tune2fs -O +dir_index" didn't seem to make
> a difference, which is kinda ex
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
> Sam Mason writes:
> > I would agree with Paul that EPSILON is a hack and probably should be
> > removed.
>
> It's a hack but it's dealing with an extremely real problem, namely
> the built-in inaccuracy of floating-point arithmetic. You
"Todd A. Cook" writes:
> Tom Lane wrote:
>> The attached prototype patch does this
>> and seems to fix the speed problem nicely. It's not tremendously
>> well tested, but perhaps you'd like to test? Should work in 8.4.
> With the patch applied, the test only took 35 seconds, and the commit
> wa
On Fri, Aug 07, 2009 at 10:39:19AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Yes, all that sounds as though you've got it.
>
> Thanks. I read through it carefully a few times, but I was still only
> 80% confident that I had it more-or-less right. ;-)
And which method did you use to
Alex Hunsaker wrote:
FYI, on my 8.2.13 system, the test created 30001 files which were all
deleted during the commit. Â On my 8.4.0 system, the test created 60001
files, of which 3 were deleted at commit and 30001 disappeared
later (presumably during a checkpoint?).
Smells like fsm?
Yes
Boszormenyi Zoltan wrote:
> Michael Meskes írta:
> > Did you take care of the copyright/licensing issue with sqlda?
>
> I added notice about the PostgreSQL license. Is it ok?
> Or should I resend without indicating the authors?
I think we're normally OK with mentioning the authors, i.e. "Author:
Tom Lane wrote:
Actually, this is easier than I thought, because there is already
bookkeeping being done that (in effect) tracks whether a table has
already been truncated in the current transaction. So we can rely
on that, and with only a very few lines of code added, ensure that
a situation l
Robert Haas writes:
> Stepping back a bit, are we sure this is a feature we even want to
> support? It was already pointed out in the thread on "Parser's hook
> based on funccall" that SQL:201x may standardize => for this purpose.
Absolutely no evidence has been presented that the SQL committee
On Fri, Aug 7, 2009 at 11:35 AM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On Monday 03 August 2009 21:07:00 David Fetter wrote:
>> > We require that people supply docs with their changes, and it is
>> > totally unreasonable to let them send in catalog changes which do not
>> > include need
On Fri, Aug 07, 2009 at 10:29:27AM -0500, Kenneth Marshall wrote:
> On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
> > points in PG [..] don't
> > arbitrarily go jumping off millions of miles away or being annihilated
> > by their anti-particle just because it's possible.
> It was defi
On Thu, Aug 6, 2009 at 10:46 PM, Robert Haas wrote:
>
> I am not sure whether this has been formally reviewed by anyone yet;
> do we think it's "Ready for Committer"?
>
i was trying to make some review of this but besides that it compiles
fine and passes regression tests doesn't know how to test i
Sam Mason writes:
> I would agree with Paul that EPSILON is a hack and probably should be
> removed.
It's a hack but it's dealing with an extremely real problem, namely
the built-in inaccuracy of floating-point arithmetic. You can't just
close your eyes to that and hope that everything will be o
Sam Mason wrote:
> Yes, all that sounds as though you've got it.
Thanks. I read through it carefully a few times, but I was still only
80% confident that I had it more-or-less right. ;-)
That does seem like a good test, with the advantage of being
relatively easy to calculate. Thanks aga
Peter Eisentraut wrote:
> On Monday 03 August 2009 21:07:00 David Fetter wrote:
> > We require that people supply docs with their changes, and it is
> > totally unreasonable to let them send in catalog changes which do not
> > include need migration changes. That's how it works in every other
> >
On Fri, Aug 07, 2009 at 10:19:20AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
>
> > What do people do when testing this? I think I'd look to something
> > like Student's t-test to check for statistical significance. My
> > working would go something like:
> >
> > I assume the variance
On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
> On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
> > On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
> > > On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
> > > > We have two points with a
Sam Mason wrote:
> What do people do when testing this? I think I'd look to something
> like Student's t-test to check for statistical significance. My
> working would go something like:
>
> I assume the variance is the same because it's being tested on the
> same machine.
>
> samples
On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
> On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
> > On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
> > > We have two points with a finite separation in the x axis.
> > > Postgres thinks they are no
Hi
Description:
=
Inconsistency in dependency.c file's object_classes array elements and
dependency.h file's enum ObjectClass elements. Following elements in
object_classes array were missing.
ForeignDataWrapperRelationId for OCLASS_FDW
ForeignServerRelationId
Muhammad Aqeel writes:
> Inconsistency in dependency.c file's object_classes array elements and
> dependency.h file's enum ObjectClass elements. Following elements in
> object_classes array were missing.
Good catch --- seems to have been some sloppiness in the SQL/MED patch.
Will fix, thanks.
On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
> On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
> > Let us consider the ordering of real numbers in postgres. As you can see
> > from
> > the results below it has clearly returned the correct results.
> >
> > sele
Magnus Hagander writes:
> On Fri, Aug 7, 2009 at 05:04, Itagaki
> Takahiro wrote:
>> I found include/commands/version.h is empty and not included from any files.
>> What is the purpose of the file?
>> From what I can tell, it hasn't been used since back in the Berkeley
> days, but it did contain
On Fri, Aug 07, 2009 at 04:17:18PM +0200, Pierre Frrrdddric Caillaud wrote:
> I'm answering my own question : at the beginning of the run, postgres
> creates a 800MB temporary file, then it fills the table, then deletes the
> temp file.
> Is this because I use generate_series to fill the test t
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> That might be a bit excessive. As I understand it, arrays of built-in types
>> (e.g., int[]) should work fine. I suspect the majority of uses of arrays
>> will
>> be with built-in types, so allowing that would help a significant portion of
>> i
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 11:48:33AM +0200, Boszormenyi Zoltan wrote:
>
>> Which isn't exactly a good programming habit.
>>
>
> I couldn't agree more.
>
:-)
>> In the above code local, in-scope variables are also replaced
>> with ECPG_informix_set_var() and _get_va
Fujii Masao writes:
> Takahiro wrote:
>> Can we change the behavior that "fast" overwrites "smart" mode?
> +1. This behavior was supported in 8.2 or before, but broken in 8.3.
> Here is the patch. This should be backported to 8.3 and 8.4.
I think this was my fault :-(. Thanks for the fix.
Greg Stark wrote:
> On Fri, Aug 7, 2009 at 1:56 AM, Bruce Momjian wrote:
> > ? ? ? ? ? ? ? ?o ?data type 'name' and is not the first column
> >
>
> What was that about?
We changed the alignment of the 'name' column:
/*
* v8_3_check_for_name_data_type_usage()
*
On Fri, 07 Aug 2009 15:42:35 +0200, Kevin Grittner
wrote:
Pierre Frédéric Caillaud wrote:
tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
but it does it too if I put the tablespace and data on the same
volume.
it starts out relatively fast :
si sobibo in
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
> Let us consider the ordering of real numbers in postgres. As you can see
> from
> the results below it has clearly returned the correct results.
>
> select( 1. = 1.0002 ); => f
> select( 1.
Peter Eisentraut writes:
> Is there a good reason for $subject, other than that the code is entangled
> with other ALTER TABLE code?
I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of sub
Dne 6.08.09 04:29, Tom Lane napsal(a):
Andrew Dunstan writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and p
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 01:05:33PM +0200, Boszormenyi Zoltan wrote:
>
>> Hey, thanks. Did you only commit this, or all of
>> those in the patchset? Exluding the nonfix for
>> the struct problem of course.
>>
>
> So far only this. So there are three more left to go. :-
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?
The new SET DISTINCT might be equally affected.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
Pierre Frédéric Caillaud wrote:
> tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
> but it does it too if I put the tablespace and data on the same
> volume.
> it starts out relatively fast :
>
> si sobibo in csus sy id wa
> 00 0 43680 2796 1
Dne 7.08.09 00:13, Tom Lane napsal(a):
Zdenek Kotala writes:
It seems to me that editline never distributed history.h file and
HAVE_EDITLINE_HISTORY_H is nonsense. But I'm not sure.
I wouldn't count on that, in part because there are so many versions of
editline. On an OS X machine I see
$
On Fri, Aug 07, 2009 at 03:29:44PM +0200, Pierre Frrrdddric Caillaud wrote:
> vmstat output :
Sorry, I don't know enough of PGs internals to suggest anything here,
but iostat may give you more details as to what's going on.
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list
Let us consider the ordering of real numbers in postgres. As you can see
from
the results below it has clearly returned the correct results.
select( 1. = 1.0002 ); => f
select( 1. < 1.0002 ); => t
select( 1. > 1.
Not strictly related to compression, but I've noticed something really
strange...
pg 8.4 (vanilla) is doing it, and my compressed version is doing it too.
tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
but it does it too if I put the tablespace and data on the same volume.
T
For reference what I'm picturing is this:
When a table is compressed it's marked read-only which bars any new
tuples from being inserted or existing tuples being deleted. Then it's
frozen and any pages which contain tuples wich can't be frozen are
waited on until they can be. When it's finished e
1 - 100 of 123 matches
Mail list logo
