We've occasionally seen problems with VACUUM getting stuck for failure
to acquire a cleanup lock due to, for example, a cursor holding a pin
on the buffer page. In the worst case, this can cause an undetected
deadlock, if the backend holding the buffer pin blocks trying to
acquire a heavyweight lo
On 06/04/2011 08:59 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of sáb jun 04 08:47:02 -0400 2011:
A snippet from the regression test:
select ts_count(to_tsvector('managing managers manage peons managerially'),
to_tsquery('managers | peon'));
Excerpts from Andrew Dunstan's message of sáb jun 04 08:47:02 -0400 2011:
> A snippet from the regression test:
>
>
> select ts_count(to_tsvector('managing managers manage peons
> managerially'),
> to_tsquery('managers | peon'));
> ts_count
> --
>
On Sat, Jun 04, 2011 at 05:49:31PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I could not come up with an actual wrong behavior arising from this usage,
> > so
> > I'll tentatively call it a false positive. reindex_index() could instead
> > unconditionally clear indexInfo->ii_Exclusion* bef
On 06/04/2011 04:51 PM, Oleg Bartunov wrote:
Well, there are several functions available around tsearch2. so I suggest
somebody to collect all of them and create one extension - ts_addon.
For example, these are what I remember:
1. tsvector2array
2. noccurences(tsvector, tsquery) - like your ts_
Noah Misch writes:
> Commit d2f60a3ab055fb61c8e1056a7c5652f1dec85e00 added an assert to indexam.c's
> RELATION_CHECKS to block use of an index while it's being rebuilt. This
> assert trips while rechecking an exclusion constraint after an ALTER TABLE
> rebuild:
> CREATE TABLE t (
>
Well, there are several functions available around tsearch2. so I suggest
somebody to collect all of them and create one extension - ts_addon.
For example, these are what I remember:
1. tsvector2array
2. noccurences(tsvector, tsquery) - like your ts_count
3. nmatches(tsvector, tsquery) - # of matc
Excerpts from Simon Riggs's message of sáb jun 04 09:11:52 -0400 2011:
> On Thu, Jun 2, 2011 at 5:48 PM, Alvaro Herrera
> wrote:
> > Actually, it turns out that NOT VALID foreign keys were already buggy
> > here, and fixing them automatically fixes this case as well, because the
> > fix involves
Andrew Dunstan writes:
> There was some discussion on this about 6 weeks ago, at which time 5.14
> wasn't released, so I didn't want to apply the patch then.
Oh, right, I thought the issue seemed familiar:
http://archives.postgresql.org/message-id/BANLkTi=qrfqppfqto2r5amb_cfsyhdv...@mail.gmail.c
On 06/04/2011 01:05 PM, Andrew Dunstan wrote:
There was some discussion on this about 6 weeks ago, at which time
5.14 wasn't released, so I didn't want to apply the patch then.
I'll look at applying the fix now.
(and apologies for top-replying ;-) )
cheers
andrew
--
Sent via pgsql-h
There was some discussion on this about 6 weeks ago, at which time 5.14
wasn't released, so I didn't want to apply the patch then.
I'll look at applying the fix now.
cheers
andrew
On 06/04/2011 12:30 PM, Tom Lane wrote:
It appears from the buildfarm configure logs that member anchovy was
Heikki Linnakangas wrote:
> On 04.06.2011 19:19, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of
those calls, I'd be happy to receive them.
>>
>>> heap_drop_with_catalog() schedules
Simon Riggs writes:
> The approach looks sound to me. It's a fairly isolated patch and we
> should be considering this for inclusion in 9.1, not wait another
> year.
That suggestion is completely insane. The patch is only WIP and full of
bugs, even according to its author. Even if it were solid
Alvaro Herrera writes:
> What surprises me is that the open references remain after a database
> drop. Surely this means that no backends keep open file descriptors to
> any table in that database, because there are no connections.
bgwriter ...
regards, tom lane
--
Sen
2011/6/4 Simon Riggs :
>
> I like your simple patch and looks like it fixes your concern.
Thanks for your interest. I forgot to mention but this type of query
is quite general in one-to-many entities and likely to be generated by
simple ORMappers.
> Your problem statement ignores the fact that mo
Simon Riggs wrote:
> we should be considering this for inclusion in 9.1, not wait
> another year.
-1
I'm really happy that we're addressing the problems with scaling to
a large number of cores, and this patch sounds great. Adding a new
feature at this point in the release cycle would be hor
It appears from the buildfarm configure logs that member anchovy was
updated yesterday from perl 5.12.3 to 5.14.0. It doesn't like plperl.c
anymore:
ccache cc -flto -march=amdfam10 -fstack-protector -O3 -pipe -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-label
On 04.06.2011 19:19, Tom Lane wrote:
Heikki Linnakangas writes:
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of those
calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the relation for deletion at the end
of trans
Heikki Linnakangas writes:
> On 03.06.2011 21:04, Kevin Grittner wrote:
>> Also, if anyone has comments or hints about the placement of those
>> calls, I'd be happy to receive them.
> heap_drop_with_catalog() schedules the relation for deletion at the end
> of transaction, but it's still possibl
On Thu, Jun 2, 2011 at 5:48 PM, Alvaro Herrera
wrote:
> Excerpts from Alvaro Herrera's message of mié jun 01 20:56:12 -0400 2011:
>> Excerpts from Thom Brown's message of mié jun 01 19:48:44 -0400 2011:
>>
>> > Is this expected?
>> > [ pg_dump fails to preserve not-valid status of constraints ]
>>
On Fri, Jun 3, 2011 at 10:36 PM, Andrew Chernow wrote:
> On 6/3/2011 10:26 PM, Andrew Chernow wrote:
>>
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res->ntups&& !res->tuples[tup_num])
should just become
if (tup_num == res->ntups)
also t
One of our PostgreSQL Experts Inc customers wanted a function to count
all the occurrences of terms in a tsquery in a tsvector. This has been
written as a loadable module function, and initial testing shows it is
working well. With the client's permission we are releasing the code -
it's avai
On 04.06.2011 18:01, Simon Riggs wrote:
It's a fairly isolated patch and we
should be considering this for inclusion in 9.1, not wait another
year.
-1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane Friday 03 of June 2011 16:44:13
> Alvaro Herrera writes:
> > Excerpts from RadosÅaw Smogura's message of jue jun 02 15:26:29 -0400
2011:
> >> So do I understand good should We think about create bettered TOAST to
> >> support larger values then 30-bit length? I like this much more,
> >
On 03.06.2011 14:02, Alexander Korotkov wrote:
Hackers,
WIP patch of fast GiST index build is attached. Code is dirty and comments
are lacking, but it works. Now it is ready for first benchmarks, which
should prove efficiency of selected technique. It's time to compare fast
GiST index build with
On Sat, Jun 4, 2011 at 2:59 PM, Simon Riggs wrote:
>> As you can see, this works out to a bit more than a 4% improvement on
>> this two-core box. I also got access (thanks to Nate Boley) to a
>> 24-core box and ran the same test with scale factor 100 and
>> shared_buffers=8GB. Here are the resu
On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby wrote:
>
> I'm torn between whether the type should store the original time or the
> original time converted to GMT.
This is the wrong way to think about it. We *never* store time
"converted to GMT". When we want to represent a point in time we
represen
2011/6/2 Teodor Sigaev
> Can we figure out some information about index i.e. whet is the height
>> of index tree, how many values are placed in one leaf node and one non
>> leaf level node?
>>
>
> http://www.sigaev.ru/cvsweb/cvsweb.cgi/gevel/
For improving space utilization, When node is split
On Fri, Jun 3, 2011 at 2:17 PM, Robert Haas wrote:
> I've now spent enough time working on this issue now to be convinced
> that the approach has merit, if we can work out the kinks.
Yes, the approach has merits and I'm sure we can work out the kinks.
> As you can see, this works out to a bit m
On Tue, May 24, 2011 at 3:47 AM, Hitoshi Harada wrote:
> That's true. But if the planning cost is an only issue, why not adding
> new GUC for user to choose if they prefer it or not? Of course if we
> have some method to predict which way to go before proving both ways,
> it's great. Do you have
30 matches
Mail list logo
