"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> That was with a mind to performance. Checking every INSERT,
>> UPDATE and DELETE statement to see if they are being done
>> against a frozen table seems like a waste.
> I'd think we would have relminxid in the relcache, so I don't buy t
> > > Suggest that we prevent write operations on Frozen tables by
> > > revoking
> > all INSERT, UPDATE or DELETE rights held, then enforcing a check
> > during GRANT to prevent them being re-enabled. Superusers would need
> > to check every time. If we dont do this, then we will have two
> >
On Tue, 2006-06-27 at 10:04 +0200, Zeugswetter Andreas DCP SD wrote:
> Simon wrote:
> > Suggest that we prevent write operations on Frozen tables by revoking
> all INSERT, UPDATE or DELETE rights held, then enforcing a check during
> GRANT to prevent them being re-enabled. Superusers would need to
Very nice explanation, thanks Alvaro.
> 2. Mark frozen databases specially somehow.
>To mark databases frozen, we need a way to mark tables as frozen.
>How do we do that? As I explain below, this allows some nice
>optimizations, but it's a very tiny can full of a huge amount of
>
On Mon, 2006-06-26 at 16:54 -0400, Alvaro Herrera wrote:
> > > Another optimization: if we are sure that unfreezing works, we can
> even
> > > mark a table as frozen in a postmaster environment, as long as we
> take
> > > an ExclusiveLock on the table. Thus we know that the vacuum is
> the sole
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm after is not freezing for read-only media, nor archive, nor
> read-only tables. What I'm after is removing the requirement that all
> databases must be vacuumed wholly every 2 billion transactions.
Well, if that's the only goal then I hardly t
Simon Riggs wrote:
> On Mon, 2006-06-26 at 13:58 -0400, Alvaro Herrera wrote:
> > The relminxid Patch
> > ===
> >
> > What I'm after is not freezing for read-only media, nor archive, nor
> > read-only tables.
>
> OK, but I am... but I'm happy to not to confuse the discussion.
O
On Mon, 2006-06-26 at 13:58 -0400, Alvaro Herrera wrote:
> Ok, let's step back to discuss this again. Sorry for the length -- this
> is a description of the problem I'm trying to solve, the issues I found,
> and how I tried to solve them.
Thanks. This is good.
> The relminxid Patch
> ===
[Resending: apparently the previous one to the list was eaten by spam
filters or something. Changing SMTP relay again ... ]
Ok, let's step back to discuss this again. Sorry for the length -- this
is a description of the problem I'm trying to solve, the issues I found,
and how I tried to solve t
Ok, let's step back to discuss this again. Sorry for the length -- this
is a description of the problem I'm trying to solve, the issues I found,
and how I tried to solve them.
The relminxid Patch
===
What I'm after is not freezing for read-only media, nor archive, nor
read-only
On Tue, 2006-06-13 at 10:02 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Elsewhere, it has been discussed that we might hold the number of blocks
> > in a relation in shared memory. Does that idea now fall down, or is it
> > complementary to this?
>
> It's been the case for
Simon Riggs <[EMAIL PROTECTED]> writes:
> Elsewhere, it has been discussed that we might hold the number of blocks
> in a relation in shared memory. Does that idea now fall down, or is it
> complementary to this?
It's been the case for some time that the planner uses
RelationGetNumberOfBlocks() to
On Mon, 2006-06-12 at 19:15 -0400, Tom Lane wrote:
> [ moving to -hackers to get some more eyeballs on the question ]
>
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sun, 2006-06-11 at 17:53 -0400, Alvaro Herrera wrote:
> >> Here I repost the patch to implement non-transactional catalogs, the
>
[ moving to -hackers to get some more eyeballs on the question ]
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sun, 2006-06-11 at 17:53 -0400, Alvaro Herrera wrote:
>> Here I repost the patch to implement non-transactional catalogs, the
>> first of which is pg_ntclass, intended to hold the non-tran
14 matches
Mail list logo
