Simon Riggs wrote:
On Tue, 2009-01-06 at 15:48 +0200, Heikki Linnakangas wrote:
How about simply:
OK
Committed and backpatched all the way back to 7.4 stable.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Tue, 2009-01-06 at 15:48 +0200, Heikki Linnakangas wrote:
> How about simply:
OK
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
Simon Riggs wrote:
On Wed, 2008-12-31 at 21:45 +0200, Heikki Linnakangas wrote:
Can I fix?
Yes please.
Fix attached.
--- 183,192
* number of pages. Otherwise, the time taken isn't worth it.
*/
possibly_freeable = vacrelstats->rel_pages -
vacrelstats->nonemp
On Mon, 2009-01-05 at 18:24 +0100, Zeugswetter Andreas OSB sIT wrote:
> > Logically, "xmin horizon" conflicts could be flexible/soft.
> > That is, if we implemented the idea to store a lastCleanedLSN for each
> > buffer then
> > "xmin horizon" conflicts would be able to continue executing until
> Logically, "xmin horizon" conflicts could be flexible/soft.
> That is, if we implemented the idea to store a lastCleanedLSN for each buffer
> then
> "xmin horizon" conflicts would be able to continue executing until they
> see a buffer with buffer.lastCleanedLSN > conflictLSN.
I think the tro
On Sun, 2009-01-04 at 13:01 +0200, Heikki Linnakangas wrote:
> Why does an AccessExclusiveLock lead to cancelled queries
> >> or pausing WAL application? I thought it'd just block other queries
> >> trying to acquire a conflicting lock in the standby, just like holding
> >> an AccessExclusiveLo
Simon Riggs wrote:
On Thu, 2009-01-01 at 12:00 +0200, Heikki Linnakangas wrote:
Greg Stark wrote:
On 31 Dec 2008, at 13:21, Simon Riggs wrote:
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this
On Thu, 2009-01-01 at 12:00 +0200, Heikki Linnakangas wrote:
> Greg Stark wrote:
> >
> > On 31 Dec 2008, at 13:21, Simon Riggs wrote:
> >>
> >> Both of these bugs are minor, but the effect of either/both of them is
> >> to cause more AccessExclusiveLocks than we might expect.
> >>
> >> For Hot S
On Wed, 2008-12-31 at 21:45 +0200, Heikki Linnakangas wrote:
> > Can I fix?
>
> Yes please.
Fix attached.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/commands/vacuumlazy.c
==
On Wed, 2008-12-31 at 14:45 -0500, Greg Stark wrote:
> On 31 Dec 2008, at 13:21, Simon Riggs wrote:
> >
> > Both of these bugs are minor, but the effect of either/both of them is
> > to cause more AccessExclusiveLocks than we might expect.
> >
> > For Hot Standby this means that many VACUUMs take
Greg Stark wrote:
On 31 Dec 2008, at 13:21, Simon Riggs wrote:
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
on relations, which would pote
On 31 Dec 2008, at 13:21, Simon Riggs wrote:
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
on relations, which would potentially lead to hav
Simon Riggs wrote:
While watching WAL records float by I noticed some AccessExclusiveLocks
occurring unnecessarily during VACUUMs.
This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c
possibly_freeable = vacrelstats->rel_pages -
vacrelstats
While watching WAL records float by I noticed some AccessExclusiveLocks
occurring unnecessarily during VACUUMs.
This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c
possibly_freeable = vacrelstats->rel_pages -
vacrelstats->nonempty_pages;
if (po
14 matches
Mail list logo
