Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] reloptions - RELOPT_KIND_ALL

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] reloptions - RELOPT_KIND_ALL
Date: 2009-01-24 11:35:44
Message-ID: 1232796944.1385.24.camel@localhost (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane píše v pá 23. 01. 2009 v 10:19 -0500:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> > Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> >> Do you have an example use case for this?
> > I use it in my space reservation patch. I going to send it soon.
> Haven't we been over that ground already?  

Maybe I overlooked something, but IIRC that we discussed only TOAST
chunks which is different problem.

> A user-settable reloption
> is not a reasonable solution to a space-reservation problem.  The
> potential for errors of commission and omission is too great.

Hmm, yeah it could be dangerous, but on other side new columns in
pg_class doesn't protect superuser to set incorrect values. I guess that
put constrains on pg_class are not good idea and wrong values could
cause server crash (when reservedspace will be greater then BLCKSZ).
What about reloptions which can be set only by superuser? Or any other


In response to

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-01-24 11:53:39
Subject: Re: Time to finalize patches for 8.4 beta
Previous:From: Simon RiggsDate: 2009-01-24 11:20:32
Subject: Re: Hot Standby (v9d)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group