Tom Lane wrote:
This is a non-issue in PL/Java. An integer parameter is never passed by
reference and there's no way the PL/Java user can get direct access to
backend memory.
So what exactly does happen when the user deliberately specifies wrong
typlen/typbyval/typalign info when creati
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?
Two or three reasons w
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> True enough but perhaps that is a problem in itself. IMO, we should be
> encouraging people to never touch the postgres binary.
I don't buy that at all. pg_ctl is useful for some people and not so
useful for others; in particular, from the perspect
Hi,
Included are the latest WITH RECURSIVE patches against CVS HEAD.
The main differences from previous patches include:
- Allow multiple query names (mutual recursion is not still allowed)
These are some examples from the regression test:
WITH RECURSIVE
x(id) AS (SELECT * FROM y UNION AL
On Saturday 02 August 2008 13:36:40 Magnus Hagander wrote:
> Josh Berkus wrote:
> > Tom,
> >
> >> Seems a lot better to me to just train people to run the check-config
> >> code by hand before pulling the trigger to load the settings for real.
> >
> > Or just have pg_ctl --check-first as an option.
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>> The problem with pg_ctl is that it's indirectly calling postgres, and it
>> doesn't have a lot of a way to know what happened after calling it;
>> consider the mess we have with pg_ctl -w.
>
> True enough but perhaps that is a problem in itself. IM
On Fri, 1 Aug 2008, Alvaro Herrera wrote:
Sounds like the thing to do would be to pass CheckpointStats into the
DONE probe.
I thought it would be more useful to demarcate where the two phases of the
checkpoint process were at clearly--the actual times themselves are
helpful but dtrace can do
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 is expected to be too expensive.
You clearly have far more faith in the cost estimat
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Doesn't it seem reasonable that it should be pg_ctl? You should never
run postgres directly unless it is for DR.
What on earth is DR?
Disaster Recovery.
The problem with pg_ctl is that it's indirectly calling postgres, and i
Joshua D. Drake wrote:
> Tom Lane wrote:
>> I'd go for just
>>
>> postgres --check-config -D $PGDATA
>>
>> (In a reload scenario, you'd edit the files in-place and then do this
>> before issuing SIGHUP.)
Sounds good.
> Doesn't it seem reasonable that it should be pg_ctl? You should never
On Sat, Aug 02, 2008 at 12:33:38AM -0400, Tom Lane wrote:
> grammar. Right now the situation is that Michael Meskes makes a manual
> cleanup pass every so often :-(. I would like to see that get automated
> sooner rather than later, but in the near term it is not the
I received a very promising
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 is expected to be too expensive.
> You clearly have far more faith in the cost estimates than I do.
Wasn't this exact proposa
On Sat, Aug 02, 2008 at 12:35:55AM +0100, Andrew Gierth wrote:
> One more oversight: the patch isn't updating the ECPG preproc.y other
> than trivially, so WITH queries aren't working in ecpg:
I'll take care of this as soon as the patch settles down enough, gets
included into our CVS or into its o
Hans-Jürgen Schönig wrote:
hello ...
i picked up csaba nagy's idea and implemented a very simple yet very
useful extension.
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
the advantage over statement_timeout is th
hello ...
i picked up csaba nagy's idea and implemented a very simple yet very
useful extension.
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
the advantage over statement_timeout is that we are actually able to
Josh Berkus wrote:
> Tom,
>
>> Seems a lot better to me to just train people to run the check-config
>> code by hand before pulling the trigger to load the settings for real.
>
> Or just have pg_ctl --check-first as an option. Cautious DBAs would use
> that. In 2-3 versions, we can make --check
Tom,
Seems a lot better to me to just train people to run the check-config
code by hand before pulling the trigger to load the settings for real.
Or just have pg_ctl --check-first as an option. Cautious DBAs would use
that. In 2-3 versions, we can make --check-first the default, and
requir
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Idle thought: maybe what would really make sense here is a "lint"
for PG config files,
I like this idea.
postgres --check-hba-file /path/to/hba.conf
postgres --check-conf-file /path/to/postgresql.conf
(I think i
Alvaro Herrera wrote:
Tom Lane wrote:
Idle thought: maybe what would really make sense here is a "lint"
for PG config files, which you'd run as a standalone program and
which would look for not only clear errors but questionable things
to warn about. For instance it might notice multiple pg_hb
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 clearly useful, it'd still
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Idle thought: maybe what would really make sense here is a "lint"
>> for PG config files,
> I like this idea.
> postgres --check-hba-file /path/to/hba.conf
> postgres --check-conf-file /path/to/postgresql.conf
> (I think it's better
Josh Berkus wrote:
> Magnus,
>
>> However it would be nice to throw an error or at least a warning when
>> parsing
>> the file instead of pretending everything's ok. Perhaps authentication
>> methods
>> should have a function to check whether the method is supported which is
>> called when the fil
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Is there any actual gain by not doing the parsing in the postmaster,
>
> Define "parsing". There's quite a lot of possible errors in pg_hba
> that it would be totally unreasonable for the postmaster to detect.
Parsing as in turning
Magnus,
However it would be nice to throw an error or at least a warning when parsing
the file instead of pretending everything's ok. Perhaps authentication methods
should have a function to check whether the method is supported which is
called when the file is parsed.
The good way to solve t
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The problem that we've seen in the past shows up when the user lies in
>> the CREATE TYPE command, specifying type representation properties that
>> are different from what the underlying functions expect.
> This is a non-issue in PL
Sorry for the delay. Here is the patch with FragmentDelimiter option.
It requires an extra option in HeadlineParsedText and uses that option
during generateHeadline.
Implementing notion of fragments in HeadlineParsedText and a separate
function to join them seems more complicated. So for the time
Tom Lane wrote:
> Idle thought: maybe what would really make sense here is a "lint"
> for PG config files, which you'd run as a standalone program and
> which would look for not only clear errors but questionable things
> to warn about. For instance it might notice multiple pg_hba.conf
> entries
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Is there any actual gain by not doing the parsing in the postmaster,
Define "parsing". There's quite a lot of possible errors in pg_hba
that it would be totally unreasonable for the postmaster to detect.
We could catch some simple problems at file loa
Simon Riggs wrote:
Well, this is a strange conclusion, leaving me slightly bemused.
The discussion between Andrew and I at PGcon concluded that we would
* document which other tools to use
* remove the delay
Now we have rejected the patch which does that, but then re-requested
the exact same
On Sat, Aug 02, 2008 at 03:39:18PM +0200, Radek Strnad wrote:
> > I also think that the clauses you have attached to your CREATE
> > COLLATION statement (case-insensitive, accent-insensitive) are an
> > oversimplification of reality. I suggest you look up the Unicode
> > collation algorithm to le
Hello,
the main reason why I've submitted the patch was to start a discussion and
know other people's opinion on this problem.
On Tue, Jul 29, 2008 at 10:41 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>
> Where are the collations going to come from?
There will be two new catalogs - pg_coll
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I've also noticed that authentication methods error out in different
> ways when they are not supported. For example, if I try to use Kerberos
> without having it compiled in, I get an error when a client tries to
> connect (because we compile in stu
The way pg_hba.conf is set up to be loaded/parsed now, we have:
postmaster: open and tokenize file (load_hba(), tokenize_file()).
backend: parse lines (parse_hba) and check for matches
(check_hba/hba_getauthmethod)
This means that the code in the postmaster is very simple, and it's
shared with t
On Thu, 2008-07-31 at 12:32 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Martin Zaun wrote:
> >> With these avenues to be explored, can the pg_standby patch on the
> >> CommitFest wiki be moved to the "Returned with Feedback" section?
>
> > Yes, I think we can con
On Thu, 2008-07-31 at 09:39 +0100, Andrew Sullivan wrote:
> On Wed, Jul 30, 2008 at 06:07:53PM -0400, Alvaro Herrera wrote:
>
> > I do agree that creating base types should require a superuser though.
> > It too seems dangerous just on principle, even if today there's no
> > actual hole (that we
35 matches
Mail list logo
