On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
> On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >>Hans-Jürgen Schönig wrote:
> >>>i introduced a GUC called statement_cost_limit which can be used to
> >>>error out if a statement i
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> Certainly there isn't any reason to allow a reload of a file that is just
>> going to break things when the first connection happens. For that matter,
>> why would we ever not want to parse it at HUP time rather than connect time?
>
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> The good way to solve this would be to have independant command line
>>> utilities which check pg_hba.conf, pg_ident.conf and postgresql.conf for
>>> errors. Then DBAs could run a check *before* restarting the server.
>
>> While cl
Thanks for the feedback, and sorry for my delay in replying (I was on
holiday).
> Tom Lane wrote:
>
> Comments:
>
> I do not think that you should invent a new elog level for this, and
> especially not one that is designed to send unexpected messages to the
> client. Having to kluge tab completio
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> Certainly there isn't any reason to allow a reload of a file that is just
>> going to break things when the first connection happens. For that matter,
>> why would we ever not want to parse it at HUP time rathe
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> For pg_hba.conf, I don't see that as a very big problem, really. It
> doesn't (and shouldn't) modify any "external" variables, so it should be
> as simple as parsing the new file into a completely separate
> list-of-structs and only if it's all correct
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> For pg_hba.conf, I don't see that as a very big problem, really. It
>> doesn't (and shouldn't) modify any "external" variables, so it should be
>> as simple as parsing the new file into a completely separate
>> list-of-structs a
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> I think it'd be reasonable to refuse starting if the config is *known
> broken* (such as containing lines that are unparseable, or that contain
> completely invalid tokens), whereas you'd start if they just contain
> things that are "probably wrong". B
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > A little extra code in the backend is well worth fixing this foot-gun.
> > The concerns raised so far have been "who will write it?" and "what if
> > it has bugs?". Neither of these are particularly compelling arguments
> > wh
On Sun, 2008-08-03 at 00:44 -0700, daveg wrote:
> On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
> > On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
> >
> > >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > >>Hans-Jürgen Schönig wrote:
> > >>>i introduced a GUC called statement_co
Has any one noticed this?
-Sushant.
On Wed, 2008-07-16 at 23:01 -0400, Sushant Sinha wrote:
> I think there is a slight bug in hlCover function in wparser_def.c
>
> If there is only one query item and that is the first word in the text,
> then hlCover does not returns any cover. This is evident
hello ...
I still support it. Regrettably, many SQL developers introduce product
joins and other unintentional errors. Why let problem queries through?
i think the killer is that we don't have to wait until the query dies
with a statement_timeout.
it is ways more elegant to kill things be
On Tue, 2008-07-29 at 09:03 -0400, Stephen Frost wrote:
> * Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> > Am Tuesday, 29. July 2008 schrieb Stephen Frost:
> > > I'd certainly like to see a truncate permission, I wrote a patch for it
> > > myself back in January of 2006. That thread starts here:
On Sun, 2008-08-03 at 22:09 +0200, Hans-Jürgen Schönig wrote:
> > Another alternative would be to have a plugin that can examine the
> > plan
> > immediately after planner executes, so you can implement this
> > yourself,
> > plus some other possibilities.
> >
> this would be really fancy.
>
I found that _bt_split function calls PageGetTempPage, but next call is
_bt_page_init which clear all contents anyway. Is there any reason to call
PageGetTempPage instead of palloc?
Original code:
00796 leftpage = PageGetTempPage(origpage, sizeof(BTPageOpaqueData));
00797 rightpage = B
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I found that _bt_split function calls PageGetTempPage, but next call is
> _bt_page_init which clear all contents anyway. Is there any reason to call
> PageGetTempPage instead of palloc?
Not violating a perfectly good abstraction?
I agree that PageGetT
Tom,
> Wasn't this exact proposal discussed and rejected awhile back?
We rejected Greenplum's much more invasive resource manager, because it
created a large performance penalty on small queries whether or not it was
turned on. However, I don't remember any rejection of an idea as simple
as a
Thanks for reply, Tom.
Well, just for documenting the process...
Adding new postgres catalog in 2 little steps:
1)Write catalog header file and save it into "src/include/catalog"
directory. Hint: copy format from other catalog headers.
2)Add your header file name to variable POSTGRES_BKI_SRCS in f
On Sunday 03 August 2008 15:12:22 Simon Riggs wrote:
> On Sun, 2008-08-03 at 00:44 -0700, daveg wrote:
> > On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
> > > On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
> > > >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > > >>Hans-Jürgen Sch
"Gustavo Tonini" <[EMAIL PROTECTED]> writes:
> Well, just for documenting the process...
> Adding new postgres catalog in 2 little steps:
> 1)Write catalog header file and save it into "src/include/catalog"
> directory. Hint: copy format from other catalog headers.
> 2)Add your header file name to
On Mon, 2008-08-04 at 00:36 -0300, Euler Taveira de Oliveira wrote:
> Sushant Sinha escreveu:
> > I think there is a slight bug in hlCover function in wparser_def.c
> >
> The bug is not in the hlCover. In prsd_headline, if we didn't find a
> suitable bestlen (i.e. >= 0), than it includes up to do
Josh Berkus wrote:
Tom,
Wasn't this exact proposal discussed and rejected awhile back?
We rejected Greenplum's much more invasive resource manager, because it
created a large performance penalty on small queries whether or not it was
turned on. However, I don't remember any rejecti
22 matches
Mail list logo
