Simon Riggs writes:
> On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
>> I've concluded that that's too large a change to undertake for 9.0
> The purpose of this was to make the big changes in 9.0. If we aren't
> going to do that it seems like we shouldn't bother at all.
No, the purpose of th
On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
> I've concluded that that's too large a change to undertake for 9.0
The purpose of this was to make the big changes in 9.0. If we aren't
going to do that it seems like we shouldn't bother at all.
So why not flip back to the easier approach of m
Tom Lane wrote:
> I've been playing around with different alternatives for solving the
> problem of toast-pointer OIDs, but I keep coming back to the above as
> being the least invasive and most robust answer. There are two basic
> ways that we could do it: pass the OID to use to the toast logic,
I wrote:
> * We can not change the toast rel OID of a shared catalog -- there's no
> way to propagate that into the other copies of pg_class. So we need to
> rejigger the logic for heap rewriting a little bit. Toast rel swapping
> has to be handled by swapping their relfilenodes not their OIDs.
I wrote:
> The design I sketched doesn't require such an assumption anyway. Once
> the map file is written, the relocation is effective, commit or no.
> As long as we restrict relocations to maintenance operations such as
> VACUUM FULL, which have no transactionally significant results, this
> doe
On Mon, 2010-02-01 at 10:27 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
> >> the assumption that the file is less than one disk block,
> >> it should be just as atomic as pg_control updates are.
>
> > IIRC there were 173 relations affected b
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The other problem with what you sketch is that it'd require holding the
>> mapfile write lock across commit, because we still have to have strict
>> serialization of updates.
> Why is the strict serialization of updates needed? To avoid overwriting
Tom Lane wrote:
> That seems too fragile to me, as I don't find it a stretch at all to
> think that writing the map file might fail --- just think Windows
> antivirus code :-(. Now, once we have written the WAL record for
> the mapfile change, we can't really afford a failure in my approach
> eith
Simon Riggs writes:
> On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
>> the assumption that the file is less than one disk block,
>> it should be just as atomic as pg_control updates are.
> IIRC there were 173 relations affected by this. 4 bytes each we would
> have more than 512 bytes.
Wher
On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
> the assumption that the file is less than one disk block,
> it should be just as atomic as pg_control updates are.
IIRC there were 173 relations affected by this. 4 bytes each we would
have more than 512 bytes.
ISTM you need to treat some of t
Greg Stark writes:
> On Mon, Feb 1, 2010 at 8:54 AM, Simon Riggs wrote:
>>> Disallow catalog relocation inside subtransactions, to avoid having
>>> to handle subxact abort effects on the local-map-changes state.
>>> This could be implemented if desired, but doesn't seem worth it
>>> at least in f
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Once the updated map file is moved into place, the relocation is effectively
>> committed even if we subsequently abort the transaction. We can make that
>> window pretty narrow but not remove it completely.
> We could include the instructions to u
On Mon, Feb 1, 2010 at 8:54 AM, Simon Riggs wrote:
>> Disallow catalog relocation inside subtransactions, to avoid having
>> to handle subxact abort effects on the local-map-changes state.
>> This could be implemented if desired, but doesn't seem worth it
>> at least in first pass.
>
> Agreed, not
On Sun, 2010-01-31 at 22:49 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I'll do a little work towards step (1) just so we can take a more
> > informed view once you've had a better look at just what (2) involves.
>
> I spent a couple of hours reading code and believe that I've identified
> a
Tom Lane wrote:
> Hm ... do we want an LWLock per map file, or is one lock to rule them all
> sufficient? LWLock per database seems problematic. With an HW lock there
> wouldn't be a problem with that. HW lock would allow concurrent updates of
> the map files of different DBs, but is that worth
FYI, getting rid of VACUUM FULL in a .0 release does make more sense
than doing it in a .1 release.
---
Tom Lane wrote:
> Simon Riggs writes:
> > I'll do a little work towards step (1) just so we can take a more
> > informe
Simon Riggs writes:
> I'll do a little work towards step (1) just so we can take a more
> informed view once you've had a better look at just what (2) involves.
I spent a couple of hours reading code and believe that I've identified
all the pain points for allowing relocation of system catalogs (
On Sun, 2010-01-31 at 15:14 -0500, Tom Lane wrote:
> If the only benefit of getting rid of VACUUM FULL were simplifying
> Hot Standby, I'd agree with you. But there are numerous other benefits.
> The double-commit hack you mention is something we need to get rid of
> for general system stability
On Sun, 2010-01-31 at 15:14 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote:
> >> Anyway, it's still not apparent to me exactly what the connection is
> >> between VACUUM FULL and Hot Standby. I remember that we said HS didn't
> >> work with VACU
Simon Riggs writes:
> On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote:
>> Anyway, it's still not apparent to me exactly what the connection is
>> between VACUUM FULL and Hot Standby. I remember that we said HS didn't
>> work with VACUUM FULL (INPLACE) but I don't recall why that is, and the
[
On Sun, 2010-01-31 at 14:44 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Having said that I now realise a few things I didn't before:
>
> > * Approach (2) effects the core of Postgres, even if you don't use Hot
> > Standby.
> > * I've had to remove 7 sanity checks to get the first few VACUUMs
On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> The options to do this were and still are:
> >>> (1) Add WAL messages for non-transactional relcache invalidations
> >>> (2) Allow system
Simon Riggs writes:
> Having said that I now realise a few things I didn't before:
> * Approach (2) effects the core of Postgres, even if you don't use Hot
> Standby.
> * I've had to remove 7 sanity checks to get the first few VACUUMs
> working. ISTM that removing various basic checks in the code
Simon Riggs writes:
> On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>>> The options to do this were and still are:
>>> (1) Add WAL messages for non-transactional relcache invalidations
>>> (2) Allow system relations to be cluster-ed/vacuum full-ed.
>> Refresh my memor
On Sun, 2010-01-31 at 21:00 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> The last item on my list before close is making VACUUM FULL and Hot
> >>> Standby play nicely together.
> >>> The options to do th
Simon Riggs wrote:
> On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>>> The last item on my list before close is making VACUUM FULL and Hot
>>> Standby play nicely together.
>>> The options to do this were and still are:
>>> (1) Add WAL messages for non-transactional rel
On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > The last item on my list before close is making VACUUM FULL and Hot
> > Standby play nicely together.
>
> > The options to do this were and still are:
>
> > (1) Add WAL messages for non-transactional relcache invalidati
Simon Riggs writes:
> The last item on my list before close is making VACUUM FULL and Hot
> Standby play nicely together.
> The options to do this were and still are:
> (1) Add WAL messages for non-transactional relcache invalidations
> (2) Allow system relations to be cluster-ed/vacuum full-ed.
The last item on my list before close is making VACUUM FULL and Hot
Standby play nicely together.
The options to do this were and still are:
(1) Add WAL messages for non-transactional relcache invalidations
(2) Allow system relations to be cluster-ed/vacuum full-ed.
(1) was how we did it origin
29 matches
Mail list logo
