On 14.11.2010 22:55, Tom Lane wrote:
Heikki Linnakangas writes:
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haas writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards. Is that actually safe?
Hmm ... that's a good question.
Robert Haas writes:
> Looking through the code, it appears to me that we'd need to do the
> following (not necessarily in this order):
Don't forget
9. Unload loadable modules that do not exist according to the new
database's catalogs; eg we don't want postgis trying to run when
its supporting ta
Hello
2010/11/15 Itagaki Takahiro :
> On Fri, Nov 12, 2010 at 00:02, Itagaki Takahiro
> wrote:
>> Postgres supports ARRAY data types well, but there are some
>> more array functions in the SQL standard. Also, the standard
>> has MULTISET data type, that is an unordered array.
>
> Here is a WIP pa
Greg Stark writes:
> Fwiw I think he's right that sum(int2) should perhaps be redefined to
> return int8. As it stands all it would take is a 64k rows to
> potentially overflow. It's not super likely but it is plausible and
> the performance penalty to use int8 wouldn't be super big either.
It's
I've spent a few hours pouring over the source code with
coarse-toothed comb, trying to figure out just exactly what might
break if we changed MyDatabaseId after backend startup time, or in
other words, allowed a backend to unbind from the database to which it
was originally bound and rebind to a n
On Mon, Nov 15, 2010 at 12:41, Shigeru HANADA wrote:
> No, SQL/MED would not support indexing foreign tables, at least in
> first version. Because it would be difficult to use common row id for
> various FDWs.
I think the reason is the SQL standard never mention about indexes.
It is not a specif
On Fri, 12 Nov 2010 08:27:54 -0800
Eric Davies wrote:
> Thank you for the time estimate and the interface discussion. It
> sounds like the PostgreSQL SQL/MED code will be very useful when it
> is done. Our product provides read-only access to files, so
> updates/inserts/deletes aren't an issue
On Fri, Nov 12, 2010 at 00:02, Itagaki Takahiro
wrote:
> Postgres supports ARRAY data types well, but there are some
> more array functions in the SQL standard. Also, the standard
> has MULTISET data type, that is an unordered array.
Here is a WIP patch for multiset function supports. Note that m
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
>> * Jan Urbański (wulc...@wulczer.org) wrote:
>>> On 04/11/10 14:09, Robert Haas wrote:
>>> > Hmm, I wonder how useful this is given that restriction.
>>>
>>> As KaiGai mentined, it's more
On Sun, Nov 14, 2010 at 9:16 PM, Greg Stark wrote:
> On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina wrote:
>> SUM(int2) => int4
>> SUM(int4) => int8
>> SUM(int8) => numeric
>>
>> Some weaknesses:
>>
>> SUM, of any precision, assumes that the precision being accumulated
>> into (which is also the
On Fri, Oct 29, 2010 at 2:59 PM, Alexander Korotkov
wrote:
> Gist picksplit method implementation in cube contrib module contains a bug
> in Guttman's split algorithm implementation. It was mentioned before but it
> is still not fixed yet. Current implementation doesn't cause incorrect
> behavior,
This is an update to my earlier patch to add getrusage resource
tracking to EXPLAIN ANALYZE.
With this patch you get something like:
QUERY PLAN
---
On Mon, Nov 15, 2010 at 11:13, Robert Haas wrote:
>> I added an additional cleanup to 'header_mode' in ecpg; I changed the type
>> from bool to char to hold 'h' or 'c'. Do you think it is reasonable?
>
> I looked at this but found that part a bit too clever for its own good.
>
> So committed the r
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina wrote:
> SUM(int2) => int4
> SUM(int4) => int8
> SUM(int8) => numeric
>
> Some weaknesses:
>
> SUM, of any precision, assumes that the precision being accumulated
> into (which is also the return-precision) is enough to avoid overflow.
> This is gene
On Wed, Nov 3, 2010 at 9:45 PM, Itagaki Takahiro
wrote:
> On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes wrote:
>> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>>> There are some "== true" in the codes, but they might not be safe
>>> because all non-zero values are true in C.
On Sun, Nov 14, 2010 at 12:13 PM, Tom Lane wrote:
> I wrote:
>> I still think it's worth looking into whether the bug can be dodged
>> by shortening the eval calls.
>
> In fact, that does seem to work; I'll commit a patch after testing a
> bit more.
>
> We still need someone to add the missing bui
On Sun, Nov 14, 2010 at 7:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> It might be even better to mention that the reason why we couldn't
>> forward the fsync request is that the fsync request queue is full.
>> I'm not sure exactly how to phrase that. I thought about:
>
>> fsync request queue
On Sun, Nov 14, 2010 at 7:19 PM, Greg Smith wrote:
>> But if this is generating a lot of log data or adding a lot of
>> overhead, then you have bigger problems anyway:
>>
>> + elog(DEBUG1, "Unable to forward fsync request, executing
>> directly");
>>
>
> The argument against this log
Marti Raudsepp wrote:
PostgreSQL's default settings change when built with Linux kernel
headers 2.6.33 or newer. As discussed on the pgsql-performance list,
this causes a significant performance regression:
http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php
NB! I am not propos
Despite some jerk submitting three brand new patches at the last minute
by himself, the November CommitFest is now closed for new submissions
and ready for review! Only 7 of the 40 patches that need review have a
reviewer assigned so far. Reviewers, mark down a patch you want to look
at in th
Greg Smith writes:
> The way you've explained it now, I see why it's not worth adding a
> specific regression test for this in the future, and what else I should
> have checked when I ran into my problem (that other system stats views
> were also working or not).
FWIW, I wouldn't object to a t
Robert Haas writes:
> It might be even better to mention that the reason why we couldn't
> forward the fsync request is that the fsync request queue is full.
> I'm not sure exactly how to phrase that. I thought about:
> fsync request queue is full
> But that seems not to answer the "so what" qu
Robert Haas wrote:
I think this one could be removed:
+ if (n > 0)
+ elog(DEBUG1,"Absorbing %d fsync requests",n);
Right; that one is just there to let you know the patch is working, and
how much the background writer does for you per pass, mainly for the
purpose of re
Magnus Hagander wrote:
I think that it's reasonable for the sort of people who turn log_checkpoints
on to also get the sync summary line, thus it being logged at LOG level.
In that case, wouldn't it make more sense to add a couple of more
fields to the existing line? Easier to post-process
Tom Lane wrote:
If the cause was what I suggested, most likely the other stats views
were broken too --- were you able to pass the regression tests in that
state?
I was having a lot of problems with the system that included regression
test issues, and yelped about this one earlier than I no
Final patch in this series for today spreads out the individual
checkpoint fsync calls over time, and was written by myself and Simon
Riggs. Patch is based against a system that's already had the two
patches I sent over earlier today applied, rather than HEAD, as both are
useful for measuring
On Sun, Nov 14, 2010 at 6:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> With those changes, I think this is committable, and will do so,
>> barring objections.
>
> Obey message style guidelines, please, especially if you're going
> to promote any of those to ereports.
The only new message woul
That it's not ready for commit this minute does not mean that it
shouldn't be in the CF this month. Delaying the first review of the
patch until the next CF pretty much ensures that we'll miss 9.1 with
it, so please add to the current CF :)
Cheers,
David.
On Sat, Nov 13, 2010 at 02:15:40PM -0600,
On Sun, Nov 14, 2010 at 11:02:08PM +0100, Yeb Havinga wrote:
> On 2010-11-14 21:06, Marko Tiikkaja wrote:
> >On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
> >>On 2010-11-14 19:35, Robert Haas wrote:
> >>>On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
> >>> wrote:
> In my opinion, all of th
On 11/14/2010 05:15 PM, Tom Lane wrote:
Josh is ignoring the proposal that is on the table and seems actually
workable, which is to consult the visibility map during index-only
scans. For mostly-static tables this would save trips to the heap for
very little extra I/O. The hard part is to mak
Robert Haas writes:
> With those changes, I think this is committable, and will do so,
> barring objections.
Obey message style guidelines, please, especially if you're going
to promote any of those to ereports.
regards, tom lane
--
Sent via pgsql-hackers mailing list (
On Sun, Nov 14, 2010 at 5:07 PM, Greg Smith wrote:
> The patch also adds some logging to the innards involved here, to help with
> understanding problems in this area. I don't think that should be in the
> version committed as is. May want to drop the logging level or make it
> disabled in regul
Daniel Farina writes:
> There are other ways one might be able to attack the performance part
> of the problem, but consider the loss of information about the type
> from int(2|4|8) to numeric when composing a series of sums: we know
> the value produced fits the abstract notion of an Integer, but
Greg Stark writes:
> On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus wrote:
>> For example, imagine if the hint bits were moved to a separate per-table
>> bitmap outside the table instead of being stored with each row, as the
>> current FSM is.
> How many times do we have to keep going around the s
On Sun, Nov 14, 2010 at 22:37, Greg Smith wrote:
> Attached patch adds some logging for each individual fsync call made during
> a checkpoint, along with a summary at the end. You need to have the
> following to see all of the detail:
>
> log_checkpoints=on
> log_min_messages=debug1
>
> And here'
On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas wrote:
> Like Tom, I'm not sure this is really a type-system problem. This
> sounds like a complaint that operations on "numeric" are much slower
> than operations on "int4" and "int8", even for values that could be
> represented by either type. I thi
On tor, 2010-11-11 at 19:35 +0200, Marko Tiikkaja wrote:
> I apologize, I had misunderstood what you are suggesting. But now
> that I do, it seems to be an even worse idea to go your way. Based on
> my research, I'm almost certain that the SQL standard says that the
> execution order is det
The attached patch adds a new field to pg_stat_bgwriter, counting the
number of times backends execute their own fsync calls. Normally, when
a backend needs to fsync data, it passes a request to the background
writer, which then absorbs the call into its own queue of work to do.
However, unde
On 2010-11-14 21:06, Marko Tiikkaja wrote:
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
In my opinion, all of these should have the same effect: DELETE all
rows
from "foo". Any other option me
Robert Haas writes:
> On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga wrote:
>> What if CTE's ever get input parameters?
> Then they'd be functions, which we already have.
If you mean something like
prepare foo(int) as
with x as (delete from tab where id = $1 returning *)
On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus wrote:
> For example, imagine if the hint bits were moved to a separate per-table
> bitmap outside the table instead of being stored with each row, as the
> current FSM is.
How many times do we have to keep going around the same block?
We *already* ha
On Sun, Nov 14, 2010 at 08:07:22PM +0200, Marko Tiikkaja wrote:
> On 2010-11-14 8:01 PM +0200, I wrote:
> >In my opinion, all of these should have the same effect: DELETE all rows
> >from "foo".
>
> Since the example wasn't entirely clear on this one: in my opinion
> the DML should also only be ex
Attached patch adds some logging for each individual fsync call made
during a checkpoint, along with a summary at the end. You need to have
the following to see all of the detail:
log_checkpoints=on
log_min_messages=debug1
And here's a sample:
LOG: checkpoint starting: immediate force wait
Greg Smith writes:
> Tom Lane wrote:
>> Worksforme. You probably need a full recompile and/or initdb
> Yeah, sorry about the noise. This went away after some more intensive
> rebuilding. I think I still want to add some regression testing of this
> view as suggested. If that had been there,
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga wrote:
> On 2010-11-14 19:35, Robert Haas wrote:
>>
>> On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
>> wrote:
>>>
>>> In my opinion, all of these should have the same effect: DELETE all rows
>>> from "foo". Any other option means we're going to ha
On Sun, Nov 14, 2010 at 2:27 PM, Daniel Farina wrote:
> On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane wrote:
>> Daniel Farina writes:
>>> Here are some weaknesses in the SUM aggregate that run up against the
>>> type system. Maybe they'll help crystallize some discussion:
>>
>>> SUM(int2) => int4
>>
Tom Lane wrote:
Worksforme. You probably need a full recompile and/or initdb
Yeah, sorry about the noise. This went away after some more intensive
rebuilding. I think I still want to add some regression testing of this
view as suggested. If that had been there, I'd have been a lot more
c
Greg Smith writes:
> I'm behind on my list mail so maybe this has been mentioned already, but
> when I just tried pg_stat_bgwriter from a build against today's HEAD I
> got this:
> pgbench=# select count(*) FROM pg_stat_bgwriter;
> ERROR: did not find '}' at end of input node
Worksforme. You
Thanks, Jan.
I tested the patch and it looks fine.
Oleg
On Sun, 14 Nov 2010, Jan Urbaski wrote:
On 24/10/10 00:32, Jan UrbaЪЪski wrote:
On 21/10/10 20:48, Alvaro Herrera wrote:
... and presumably somebody can fix the real bug that Jean-Baptiste hit,
too.
AFAICS the error comes from PLy_fun
>> I'd say put it on and mark it with an [E]. We could use some more
>> [E]asy items for that list.
>
> We don't need to add marginally-useful features just because they're
> easy. If it doesn't have a real use-case, the incremental maintenance
> cost of more code is a good reason to reject it.
Heikki Linnakangas writes:
> On 13.11.2010 17:07, Tom Lane wrote:
>> Robert Haas writes:
>>> Come to think of it, I'm not really sure I understand what protects
>>> SetLatch() against memory ordering hazards. Is that actually safe?
>>
>> Hmm ... that's a good question. It certainly *looks* lik
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just be relations with an att
> If we got rid of hint bits, we'd need workarounds for the ensuing
> massive performance loss. There is no reason whatsoever to imagine
> that we'd come out ahead in the end.
Oh, there's no question that we need something which serves the same
purpose as the existing hit bits. But there's a lo
I'm behind on my list mail so maybe this has been mentioned already, but
when I just tried pg_stat_bgwriter from a build against today's HEAD I
got this:
pgbench=# select count(*) FROM pg_stat_bgwriter;
ERROR: did not find '}' at end of input node
Can someone confirm if this broke recently, o
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haas writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards. Is that actually safe?
Hmm ... that's a good question. It certainly *looks* like it could
malfunction on machines with wea
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from "foo". Any other option means we're going to have trouble predicting
h
unblock what you were
looking for more details from me about.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
merge-v203-20101114.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane wrote:
> Daniel Farina writes:
>> Here are some weaknesses in the SUM aggregate that run up against the
>> type system. Maybe they'll help crystallize some discussion:
>
>> SUM(int2) => int4
>> SUM(int4) => int8
>> SUM(int8) => numeric
>
>> Some weaknesse
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from "foo". Any other option means we're going to have trouble predicting
how a query is going to behave.
I think it's clear
On Sun, Nov 14, 2010 at 11:06 AM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> The only real solution seems to me to be to keep a small SysV shared
>> memory segment for the locking and allocate the rest of the shared
>> memory some other way.
>
> Yeah, that's been discussed. It throws al
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
> In my opinion, all of these should have the same effect: DELETE all rows
> from "foo". Any other option means we're going to have trouble predicting
> how a query is going to behave.
I think it's clear that's the only sensible behavior.
-
On 14.11.2010 00:29, Robert Haas wrote:
On Sat, Nov 13, 2010 at 12:13 PM, Tom Lane wrote:
Hannu Krosing writes:
On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
If a table has no indexes, we will always decide that any same-page
update operation is a HOT update, since obviously it isn't mo
On Sun, Oct 24, 2010 at 01:32, Jan Urbański wrote:
> The error handling in plpython is well-known to be a mess, hence the
> confusing error message that OP got. Another annoying thing is that SPI
> calls are not done in a subtransaction, which means you can't trap
> errors with a try/catch Python
On 2010-11-14 8:01 PM +0200, I wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from "foo".
Since the example wasn't entirely clear on this one: in my opinion the
DML should also only be executed once. So:
WITH t AS (INSERT INTO foo VALUES (0) RETURNING *)
SEL
On 2010-11-14 5:28 PM +0200, Hitoshi Harada wrote:
2010/11/14 Marko Tiikkaja:
.. and a wild patch appears.
Could you update wiki on this feature if you think we've reached the consensus?
You're probably referring to
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00660.php
which was
I wrote:
> I still think it's worth looking into whether the bug can be dodged
> by shortening the eval calls.
In fact, that does seem to work; I'll commit a patch after testing a
bit more.
We still need someone to add the missing build dependencies so that
make -j is trustworthy again.
On Nov 14, 2010, at 7:42 AM, Andrew Dunstan wrote:
> It's fairly unscientific and inconclusive, and the discussion seems to have
> died. I think since Tom and I did most of the work on this our voices should
> count a little louder :-) , so I'm going to go with his suggestion of VALUE,
> unless
On 24/10/10 00:32, Jan Urbański wrote:
> On 21/10/10 20:48, Alvaro Herrera wrote:
>> ... and presumably somebody can fix the real bug that Jean-Baptiste hit,
>> too.
>
> AFAICS the error comes from PLy_function_handler disconnecting from SPI
> after calling into the Python code and then going ahea
Robert Haas writes:
> On Nov 14, 2010, at 10:44 AM, Tom Lane wrote:
>> I still think it's worth looking into whether the bug can be dodged
>> by shortening the eval calls. But if not, I think I'd vote for
>> reverting. Maybe we could revisit this in a couple of years.
> +1. The current master
On Nov 14, 2010, at 10:44 AM, Tom Lane wrote:
> I still think it's worth looking into whether the bug can be dodged
> by shortening the eval calls. But if not, I think I'd vote for
> reverting. Maybe we could revisit this in a couple of years.
+1. The current master branch fails to build on my
On 11/14/2010 10:44 AM, Tom Lane wrote:
And on the fourth hand, what we're buying here is pretty marginal for
developers and of no interest whatever for users.
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls. But if not, I think I'd vote for
Martijn van Oosterhout writes:
> The only real solution seems to me to be to keep a small SysV shared
> memory segment for the locking and allocate the rest of the shared
> memory some other way.
Yeah, that's been discussed. It throws all the portability gains out
the window. It might get you o
Daniel Farina writes:
> Here are some weaknesses in the SUM aggregate that run up against the
> type system. Maybe they'll help crystallize some discussion:
> SUM(int2) => int4
> SUM(int4) => int8
> SUM(int8) => numeric
> Some weaknesses:
> SUM, of any precision, assumes that the precision bein
Dave Page writes:
> On Sat, Nov 13, 2010 at 8:13 PM, Peter Eisentraut wrote:
>> Well, it looks like $(eval) is pretty broken in 3.80, so either we
>> require 3.81 or we abandon this line of thought.
> 3.81 might be a problem for Solaris - unless I pay for a support
> contract from Oracle, I'm no
On 10/29/2010 01:47 AM, Pavel Golub wrote:
Hello, Alvaro.
You wrote:
AH> Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
AH> Hah, there are 17 votes as of right
2010/11/14 Marko Tiikkaja :
> On 2010-11-12 8:25 PM +0200, I wrote:
>>
>> I'm going to take some time off this weekend to get a patch with this
>> behaviour to the next commitfest.
>
> .. and a wild patch appears.
>
> This is almost exactly the patch from 2010-02 without
> CommandCounterIncrement()
On Sat, Nov 13, 2010 at 08:07:52PM -0500, Tom Lane wrote:
> "A.M." writes:
> > The goal of this work is to address all of the shortcomings of previous
> > POSIX shared memory patches as pointed out mostly by Tom Lane.
>
> It seems like you've failed to understand the main shortcoming of this
> w
On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis wrote:
> I think the best we'll do is be able to hack on some of the things that
> we actively want and have clear use cases for, such as type interfaces.
> We might have to give up on some of the more ambitious ideas that
> involve propagating interesti
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
> A key component of a good type system is that users can define data types,
> and moreover where possible, system-defined types are defined in the same
> ways as users define types. For example, stuff like temporal types or
> geospatial types
On Sat, Nov 13, 2010 at 8:13 PM, Peter Eisentraut wrote:
> On lör, 2010-11-13 at 20:07 +0200, Peter Eisentraut wrote:
>> On lör, 2010-11-13 at 12:20 -0500, Tom Lane wrote:
>> > Peter Eisentraut writes:
>> > > On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
>> > >> It looks like all the unhappy
80 matches
Mail list logo
