On Wednesday 25 March 2009 23:55:06 Tom Lane wrote:
> Alvaro Herrera writes:
> > Josh Berkus wrote:
> >> That was 6 months ago. I doubt anyone remembers it. Make another
> >> announcement, so that when people get the "unsubscribed" announcement,
> >> they're not confused.
> >
> > Done.
>
> BTW,
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
wrote:
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
wrote:
I find it hard to imagine a use case for the existing default
behavior.
I thought a bit about it and I think it can be useful when your
priority is the availabili
Please clarify what you want done on the majordomo side ... I saw one
comment about unsub'ng everyone ... for archive purposes, this makes
sense, I just want to make sure before I blow them all away (and I will
unsubscribe them without having a blast of emails go out to them)
I will als
Josh Berkus writes:
> Yes, although Bruce *has* asked for help in cleaning up the open-items list.
I spent several hours on that on Saturday, and more or less got the bird
in response... the way Bruce has that page set up, only he can do any
actual item removal, the rest of us can only comment.
All,
In any case, the release notes aren't normally a bottleneck. I still
think that Bruce had his priorities out of whack in not cleaning up
his open-items list before doing this. If he had done so, nobody
would have noticed how long the notes took.
Yes, although Bruce *has* asked for help
Robert Haas writes:
> OK, I am all wet. I now understand why the editing is the
> time-consuming part of this job. On the plus side it is probably
> possible to parallelize it to some degree by splitting the list into N
> pieces after the "remove insignificant items" step.
The advantage of havi
OK, I am all wet. I now understand why the editing is the
time-consuming part of this job. On the plus side it is probably
possible to parallelize it to some degree by splitting the list into N
pieces after the "remove insignificant items" step.
With respect to this item:
Disable appending of th
Hi,
> Set the maximum number of times to retry the copy or link command
maxretries option of pg_standby is documented as above, but actually
indicates the maximum number of times to *try* the copy or link command.
So, if "-r 0" is specified, pg_standby always fails.
Attached is the patch which a
Peter Eisentraut wrote:
> I found an old patch on my disk to enable SSL over Unix-domain sockets.
>
> Remember, about a year ago it was discussed that there might also be
> man-in-the-middle or fake-server attacks using Unix-domain sockets,
> because usually anyone can start a server in /tmp. A
David E. Wheeler wrote:
> On Mar 24, 2009, at 9:41 AM, Bruce Momjian wrote:
>
> > So far taking the CVS logs and making a list of only the items we want
> > for the release notes took one day; researching and rewording the
> > items
> > so they are ready for the release notes took five days; g
On Mar 25, 2009, at 2:39 PM, Josh Berkus wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
God, could someone do the module thing? :->
I'd be hap
Hi,
On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
wrote:
> On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
> wrote:
>> I find it hard to imagine a use case for the existing default
>> behavior.
>
> I thought a bit about it and I think it can be useful when your
> priority is the availability
Tom Lane wrote:
> Robert Haas writes:
> > 2009/3/24 Tom Lane :
> >> catversion bumped because of change in GIN's pg_am entry, and because
> >> the format of GIN indexes changed on-disk (there's a metapage now,
> >> and possibly a pending list).
>
> > Will this break pg_migrator?
>
> No worse tha
On Wed, Mar 25, 2009 at 7:50 PM, Tom Lane wrote:
> And you thought it'd never happen ...
>
> We still have a few loose ends before we can go beta, but we're getting
> there.
Awesome!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
And you thought it'd never happen ...
We still have a few loose ends before we can go beta, but we're getting
there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Teodor Sigaev writes:
> [ btree_gin 0.12 ]
Committed with some editorializations. There are still a few loose
ends:
* the question about zero-key queries that I mentioned before
* After this new look at the code I think that matchPartialInPendingList
is completely broken. Surely it's an infin
Michael Toews escreveu:
> This feature request is for PG to support -infinity and infinity for date
> types.
>
This was done for 8.4. Look at TODO [1].
[1] http://wiki.postgresql.org/wiki/Todo
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (
Hi,
I hope I found the right list for this request. I am aware that timestamp
with[out] time zone data types have -infinity and infinity key values; see
http://www.postgresql.org/docs/current/interactive/datatype-datetime.html
However, there is no equivalent for date types, and expressions like
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> BTW ... while I'm thinking about it: it seems to me to be a
> Tom> serious error that the consistent() function isn't given nkeys
> Tom> so that it can know the length of the arrays it's being handed.
> I ran into exactly this problem i
> "Tom" == Tom Lane writes:
Tom> BTW ... while I'm thinking about it: it seems to me to be a
Tom> serious error that the consistent() function isn't given nkeys
Tom> so that it can know the length of the arrays it's being handed.
Tom> I suppose it's possible for it to re-deduce nkeys by e
Alvaro Herrera writes:
> Josh Berkus wrote:
>> That was 6 months ago. I doubt anyone remembers it. Make another
>> announcement, so that when people get the "unsubscribed" announcement,
>> they're not confused.
> Done.
BTW, what was the reason we didn't pull the trigger before, when we
ret
Josh Berkus wrote:
> On 3/25/09 12:17 PM, Alvaro Herrera wrote:
>> http://archives.postgresql.org/pgsql-interfaces/2008-07/msg2.php
>
> That was 6 months ago. I doubt anyone remembers it. Make another
> announcement, so that when people get the "unsubscribed" announcement,
> they're not
On 3/25/09 8:11 AM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
It does look like -interfaces is dying: almost no traffic, and what
questions it does get are off-topic more often than not. Partly this
is because the -jdbc, -odbc, and -php lists suck away all the traffic
about
All,
Due to budget constraints, Google needed to cut 50 projects from the
Summer of Code this year. We were one of the projects cut (although we
can re-apply next year).
However, that doesn't mean we won't be working with students this year.
1) Portland State University has generously offer
On Wed, Mar 25, 2009 at 05:56:02PM +, Sam Mason wrote:
> On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote:
> > On Wed, Mar 25, 2009 at 03:58:06PM +, Sam Mason wrote:
> > > #!/bin/bash
> > > nclients=$1
> > > ittrs=$2
> > > function gensql {
> > > echo "INSERT
Josh Berkus wrote:
> On 3/25/09 8:11 AM, Alvaro Herrera wrote:
>> As for actually shutting it down in Majordomo, Marc is the man.
>>
>
> Might want to make an announcement on that list first.
http://archives.postgresql.org/pgsql-interfaces/2008-07/msg2.php
--
Alvaro Herrera
On 3/25/09 12:17 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
On 3/25/09 8:11 AM, Alvaro Herrera wrote:
As for actually shutting it down in Majordomo, Marc is the man.
Might want to make an announcement on that list first.
http://archives.postgresql.org/pgsql-interfaces/2008-07/msg2.p
On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote:
> On Wed, Mar 25, 2009 at 03:58:06PM +, Sam Mason wrote:
> > #!/bin/bash
> > nclients=$1
> > ittrs=$2
> > function gensql {
> > echo "INSERT INTO bm (c,v) VALUES ('$1','0');"
> > for (( i = 1; i < $ittrs; i++
Our fine manual sayeth (in section 52.5)
When extractQuery returns zero keys, GIN will emit an error. Depending
on the operator, a void query might match all, some, or none of the
indexed values (for example, every array contains the empty array, but
does not overlap the empty array), and
Tom Lane wrote:
Andrew Dunstan writes:
I thought we had fixed this in 8.3:
I think that behavior is intentional: plancache.c can deal with the plan
changing internally, but it doesn't expect that its callers could
survive the plan's argument datatypes changing underneath them.
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
wrote:
> I would love to get it, but when I suggested it some time in the past
> Tom shot it down as bad idea.
>
> http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com
I agree with Tom here. I tracked a lot of idle i
On Wed, Mar 25, 2009 at 03:58:06PM +, Sam Mason wrote:
> On Wed, Mar 25, 2009 at 02:38:45PM +, Greg Stark wrote:
> > Sam Mason writes:
> > > Why does it top out so much though? It goes up nicely to around ten
> > > clients (I tested with 8 and 12) and then tops out and levels off. The
>
Peter Willis wrote:
I am aware of PostGIS and already use it. My question was regarding
the entry format of PostgreSQL polygon data. There is a void
in the PostgreSQL documentation regarding this.
Incidentally, PostGIS uses PostgreSQL polygon, point, and path
data types.
Errr... no it doesn't
Andrew Dunstan writes:
> I thought we had fixed this in 8.3:
I think that behavior is intentional: plancache.c can deal with the plan
changing internally, but it doesn't expect that its callers could
survive the plan's argument datatypes changing underneath them.
regards,
BTW ... while I'm thinking about it: it seems to me to be a serious
error that the consistent() function isn't given nkeys so that it can
know the length of the arrays it's being handed. I suppose it's
possible for it to re-deduce nkeys by examining the query datum, but
that could be quite expensi
On Wed, Mar 25, 2009 at 06:08:43PM +0900, Tatsuhito Kasahara wrote:
> So, I sometimes want to know what query (main cause) was done before
> transaction which have been practiced for a long time.
> Thoughts?
I would love to get it, but when I suggested it some time in the past
Tom shot it down as
I thought we had fixed this in 8.3:
cap=# create table t1 (t varchar(40));
CREATE TABLE
cap=# create table t2 (t varchar(40));
CREATE TABLE
cap=# create function t1trig() returns trigger language plpgsql as
$$ begin insert into t2 values(new.t); return null; end; $$;
CREATE
[ back to this patch... ]
Teodor Sigaev writes:
>> Looked at this a bit ... do you think it's really a good idea to remove
>> the strategy number argument of comparePartial? The argument given in
>> the docs for it is that it might be needed to determine when to end the
>> scan, and that still s
On Wed, Mar 25, 2009 at 02:38:45PM +, Greg Stark wrote:
> Sam Mason writes:
> > Why does it top out so much though? It goes up nicely to around ten
> > clients (I tested with 8 and 12) and then tops out and levels off. The
> > log is chugging along at around 2MB/s which is well above where t
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
wrote:
> I find it hard to imagine a use case for the existing default
> behavior.
I thought a bit about it and I think it can be useful when your
priority is the availability of the service and you don't consider a
data loss that important: even if
Greg Stark writes:
> What happens is that the first backend comes along, finds nobody else waiting
> and does an fsync for its own work. While that fsync is happening the rest of
> the crowd -- N-1 backends -- comes along and blocks waiting on the lock. The
> first backend to get the lock fsyncs t
Peter Eisentraut wrote:
> Tom Lane wrote:
>> It does look like -interfaces is dying: almost no traffic, and what
>> questions it does get are off-topic more often than not. Partly this
>> is because the -jdbc, -odbc, and -php lists suck away all the traffic
>> about those interfaces, leaving not m
Sam Mason writes:
>> You can see this
>> most easily by doing inserts into a system that's limited by a slow fsync,
>> like a single disk without write cache where you're bound by RPM speed.
>
> Yes, I did a test like this and wasn't getting the scaling I was
> expecting--hence my post. I though
Peter Eisentraut writes:
> Joshua D. Drake wrote:
> Do we want to give a more informative error message, like "not supported
> on this platform?"
> The trick will be to fit this into the GUC framework.
You could do it by enforcing the limit in an assign hook, but I'm
not convinced it's worth the
>>> Guillaume Smet wrote:
> On Wed, Mar 25, 2009 at 9:44 AM, Fujii Masao
wrote:
>> Yeah, I agree... but there may be scripts for warm-standby based on
>> the existing default behavior. So, I didn't make a new trigger the
default.
>
> I don't use pg_standby personnaly but I admit I'm quite surpr
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>>> I imagine for example, we could invent an additional sslmode of the sort
>>> prefer-but-not-if-local-socket, which could be the default.
>>
>> That parameter is already pretty complex, not sure it's a great idea to
>> make it even more so :(
>
>
Magnus Hagander wrote:
I imagine for example, we could invent an additional sslmode of the sort
prefer-but-not-if-local-socket, which could be the default.
That parameter is already pretty complex, not sure it's a great idea to
make it even more so :(
I think there is a firm difference betwee
Peter Eisentraut wrote:
> I found an old patch on my disk to enable SSL over Unix-domain sockets.
>
> Remember, about a year ago it was discussed that there might also be
> man-in-the-middle or fake-server attacks using Unix-domain sockets,
> because usually anyone can start a server in /tmp. Aft
Dne 24.03.09 22:31, Robert Lor napsal(a):
I think the is-enabled test will address the issues you encountered. I
see a few alternative to fixing this:
1) Only use if (foo_ENABLED()) test for probes with expensive function
call/computation in arguments. This will keep the code clean, and we c
On Wed, Mar 25, 2009 at 12:58:46AM -0700, Scara Maccai wrote:
> I've altready asked this some months ago, but I've never seen any answers:
>
> why do multidimensional arrays have to have matching extents for each
> dimension?
Because the dimensions define the rectangular bounds of the array in
n-
I found an old patch on my disk to enable SSL over Unix-domain sockets.
Remember, about a year ago it was discussed that there might also be
man-in-the-middle or fake-server attacks using Unix-domain sockets,
because usually anyone can start a server in /tmp. After an extensive
discussion (ma
[ I'm arbitrarily replying to Greg as his was the most verbose ]
On Tue, Mar 24, 2009 at 11:23:36PM -0400, Greg Smith wrote:
> On Tue, 24 Mar 2009, Sam Mason wrote:
> >The conceptual idea is to have at most one outstanding flush for the
> >log going through the filesystem at any one time.
>
> Qu
Robert Haas wrote:
I think the key to getting this done is
to keep the design as simple as possible and to avoid entanglements
with other features that may need to be designed independently and
first.
I think the key to getting this done is to define project purpose and
requirements before doi
Tom Lane wrote:
It does look like -interfaces is dying: almost no traffic, and what
questions it does get are off-topic more often than not. Partly this
is because the -jdbc, -odbc, and -php lists suck away all the traffic
about those interfaces, leaving not much. So we could kill -interfaces
w
This sure is a desirable feature. I have seen quite a few instances, where
the app is in 'IDLE in Transaction' state, and we are left with the only
choice of killing such processes from OS. (Remember pg_cancel_backend() does
not work for sessions in IDLE or IDLE in transaction state)
Also, it shou
Joshua D. Drake wrote:
On Mon, 2009-03-23 at 16:21 -0400, Bruce Momjian wrote:
If a platform doesn't have posix_fadvise(), we don't allow
effective_io_concurrency to be set to anything but zero:
test=> set effective_io_concurrency = 1;
ERROR: 1 is outside the valid range for p
Hi,
On Wed, Mar 25, 2009 at 5:55 PM, Guillaume Smet
wrote:
> On Wed, Mar 25, 2009 at 9:44 AM, Fujii Masao wrote:
>> Yeah, I agree... but there may be scripts for warm-standby based on
>> the existing default behavior. So, I didn't make a new trigger the default.
>
> I don't use pg_standby person
Hi.
Now, we can check the running query string by pg_stat_activity.current_query.
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
Long-transaction is a trouble, because it prevents defragmentation of HOT and
VACUUM.
And lo
On Wed, Mar 25, 2009 at 9:44 AM, Fujii Masao wrote:
> Yeah, I agree... but there may be scripts for warm-standby based on
> the existing default behavior. So, I didn't make a new trigger the default.
I don't use pg_standby personnaly but I admit I'm quite surprised by
the current behaviour. I'm p
Hi,
Thanks for the comment.
On Wed, Mar 25, 2009 at 3:50 PM, Guillaume Smet
wrote:
> On Wed, Mar 25, 2009 at 7:29 AM, Fujii Masao wrote:
>> Attached patch fixes the above problem by adding a new trigger option
>> to pg_standby; the presence of this new trigger file causes recovery to
>> end aft
Hi,
nobody answered on the regular mailing list, hope someone can answer here
Thank you
Original Message
Subject:[GENERAL] Matching dimensions in arrays
Date: Mon, 9 Mar 2009 01:14:57 -0700 (PDT)
From: Scara Maccai
To: pgsql-general
I've altready asked
61 matches
Mail list logo
