"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I'm not sure whether we can allow int8 columns in system tables, for
>> portability reasons.
> Someone will have to tell me if this is really a problem,
Depending on int8 to actually work is right out.
I'd go with fl
Peter Eisentraut wrote:
> Matthew T. O'Connor wrote:
> > As before, to apply this patch:
> > 1) Move pg_autovacuum.c and .h get from contrib to
> > src/backend/postmaster and src/include/postmaster respectively.
>
> Trivial comment: maybe we can drop the pg_ prefix on the file names.
>
> > 2) Pla
Matthew T. O'Connor wrote:
> Peter Eisentraut wrote:
>
> > Matthew T. O'Connor wrote:
> >
> >>As before, to apply this patch:
> >>1) Move pg_autovacuum.c and .h get from contrib to
> >>src/backend/postmaster and src/include/postmaster respectively.
> >
> > Trivial comment: maybe we can drop the
Peter Eisentraut wrote:
Matthew T. O'Connor wrote:
As before, to apply this patch:
1) Move pg_autovacuum.c and .h get from contrib to
src/backend/postmaster and src/include/postmaster respectively.
Trivial comment: maybe we can drop the pg_ prefix on the file names.
Ok, that's not a problem. Bruce
Matthew T. O'Connor wrote:
> As before, to apply this patch:
> 1) Move pg_autovacuum.c and .h get from contrib to
> src/backend/postmaster and src/include/postmaster respectively.
Trivial comment: maybe we can drop the pg_ prefix on the file names.
> 2) Place the attached pg_autovacuum.h in src/i
Andreas didn't ask for a full file API. I suggested it because we were
already going to have some of the functionality. If rename/unlink are
new problems, we can skip them and just add what Andreas needs right
now.
---
And
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
On Fri, 23 Jul 2004, Andreas Pflug wrote:
What I'd like is
SELECT pg_file_unlink('postgresql.conf.bak');
SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm pretty much against allowing configuration editing from remote
> >> altogether.
>
> > Why can't they just use COPY to replace the contents of pg_hba.conf now?
>
> If you've write-protected it, that doesn't wo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> As for the analogy to COPY, the addition of unlink/rename to a hacker's
>> tool set renders the situation far more dangerous than if he only has
>> write. Write will not allow him to hack write-protected files, but he
>> might be able
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> As for the analogy to COPY, the addition of unlink/rename to a hacker's
> >> tool set renders the situation far more dangerous than if he only has
> >> write. Write will not allow him to hack write-protected files
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm pretty much against allowing configuration editing from remote
>> altogether.
> Why can't they just use COPY to replace the contents of pg_hba.conf now?
If you've write-protected it, that doesn't work.
Also, COPY insists on an ab
Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 23 Jul 2004, Andreas Pflug wrote:
> >> What I'd like is
> >>
> >> SELECT pg_file_unlink('postgresql.conf.bak');
> >> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
> >> SELECT pg_file_rename('postgresql.c
>However, there certainly wasn't any reason that the syslog-vs-stderr
>switch couldn't be flipped on the fly; the only reason it's even
>PGC_SIGHUP was we wanted to enforce that all backends are doing the
>same thing at any given time.
Right.
>I was just wondering if the log_destination change ha
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 23 Jul 2004, Andreas Pflug wrote:
>> What I'd like is
>>
>> SELECT pg_file_unlink('postgresql.conf.bak');
>> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
>> SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.conf',
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Also, while I'm aware that a superuser can persuade the backend to write
> >> on anything, it doesn't follow that we should invent pg_file_write(),
> >> pg_file_rename(), or pg_file_unlink().
>
> > I think the ana
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, while I'm aware that a superuser can persuade the backend to write
>> on anything, it doesn't follow that we should invent pg_file_write(),
>> pg_file_rename(), or pg_file_unlink().
> I think the analogy is locking one door but l
On Fri, 23 Jul 2004, Andreas Pflug wrote:
> > What we probably want instead is a separate
> > redirect_stderr_to_files boolean (I'm sure a better name could be
> > thought of).
> >
> > Also, while I'm aware that a superuser can persuade the backend to write
> > on anything, it doesn't follow that
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> I just noticed that this patch seems to have replaced a PGC_SIGHUP
>> config item (the syslog flag) with a PGC_POSTMASTER config item
>> (log_destination). What was the reason for the downgrade in
>> flexibility? If it was discussed before, I've fo
>> Remove 'syslog' GUC variable, and add more logical 'log_destination'
>> variable to control logoutput location on Unix and Win32.
>
>I just noticed that this patch seems to have replaced a PGC_SIGHUP
>config item (the syslog flag) with a PGC_POSTMASTER config item
>(log_destination). What was t
Tom Lane wrote:
> Also, while I'm aware that a superuser can persuade the backend to write
> on anything, it doesn't follow that we should invent pg_file_write(),
> pg_file_rename(), or pg_file_unlink(). Those are not needed for the
> originally intended purpose of this patch and I think that they
Tom Lane wrote:
Bruce Momjian wrote:
Are we done?
Nope, the syslogger part of this is still a mess. I don't want any
pg_logfile_rotate() function in there at all: its presence is a hangover
from a different design philosophy.
No. As I mentioned earlier, there might be cases when a superuser wants
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Remove 'syslog' GUC variable, and add more logical 'log_destination'
> variable to control logoutput location on Unix and Win32.
I just noticed that this patch seems to have replaced a PGC_SIGHUP
config item (the syslog flag) with a PGC_POSTMASTER co
Bruce Momjian wrote:
> Are we done?
Nope, the syslogger part of this is still a mess. I don't want any
pg_logfile_rotate() function in there at all: its presence is a hangover
from a different design philosophy. Nor pg_reload_conf(); where did
that come from? (Hint: if you can edit postgresql.c
Bruce Momjian wrote:
Are we done? Seems pg_file_stat() works fine. Do we need other
adjustments?
Here are the documentation changes.
Regards,
Andreas
Index: catalogs.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ca
> > > Ok, here is another one.
> > >
> > > Doc patches coming up if/when this one is approved.
> >
> > I think this warning is seriously going to annoy me. Can we do
> > without it?
>
> What if we skip the warning if the user specifically asks for
> 'trust'?
> Would that help?
Uh. That's how
> Magnus Hagander wrote:
> > Just for reference, what features are we losing without
> readline. Tab
> > completion, but what more?
>
> Command history, customizable key bindings, cut and paste,
> cursor keys come to mind.
Command history, cut-and-paste and cursor keys definitly work in my
bui
26 matches
Mail list logo
