On 22/02/11 19:47, Heikki Linnakangas wrote:
A long query on the same table can block vacuum. Vacuum needs to take
a so-called "cleanup lock" on each page, which means that it has to
wait until no other backend holds a pin on the page. A long-running
query can keep a page pinned for a long ti
On 22.02.2011 05:43, Mark Kirkwood wrote:
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting | current_query
+--
On Mon, Feb 21, 2011 at 10:43 PM, Daniel Farina wrote:
> A medium-length story short, this query returns non-zero:
>
> select count(distinct typnamespace) from pg_type where not exists
> (select 1 from pg_namespace where oid = pg_type.typnamespace);
>
> I did a very brief search in all the releas
A medium-length story short, this query returns non-zero:
select count(distinct typnamespace) from pg_type where not exists
(select 1 from pg_namespace where oid = pg_type.typnamespace);
I did a very brief search in all the release notes for 8.3.5 to
8.3.14, but have not found precisely what I w
On Tue, Feb 22, 2011 at 1:31 PM, Tom Lane wrote:
> I wrote:
> > Ugh. That quick little "ExecRemoveJunk" is a lot more dangerous than it
> > looks. I had actually looked at this before, but concluded it was OK
> > because I couldn't reproduce the problem with a trigger in place.
> > I guess I wa
The following bug has been logged online:
Bug reference: 5896
Logged by: Nacho Mezzadra
Email address: nachomezza...@gmail.com
PostgreSQL version: 8.3.14-1
Operating system: Red Hat 5.3 Enterprise
Description:When server cannot be started, first it says that it
couldn
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting
|
current_query
I wrote:
> Ugh. That quick little "ExecRemoveJunk" is a lot more dangerous than it
> looks. I had actually looked at this before, but concluded it was OK
> because I couldn't reproduce the problem with a trigger in place.
> I guess I wasn't unlucky enough to have the chance pointer equality
> occ
I wrote:
> [ theory about cause of bug #5798 ]
Attached is a proposed patch against HEAD to fix this problem. It's a
bit hard to *prove* that it fixes the problem, since there's no easy way
to force the collision of palloc addresses. But I think it will.
The patch changes the signature of ExecB
Maxim Boguk writes:
> Yes here is one BEFORE UPDATE trigger on relation
> ...
> However that trigger should not fire at all because storable procedure work
> with set local session_replication_role to 'replica';
Would be nice if you'd provided those sorts of details earlier, instead
of us having
Hi
Yes here is one BEFORE UPDATE trigger on relation
(
Triggers:
_billing_main_denyaccess_71 BEFORE INSERT OR DELETE OR UPDATE ON
ctrl_servers FOR EACH ROW EXECUTE PROCEDURE
_billing_main.denyaccess('_billing_main')
)
However that trigger should not fire at all because storable procedure work
11 matches
Mail list logo
