Ready for Beta ... ?

Marc G. Fournier wrote:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Speak now, or forever hold your piece :)

The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.

---------------------------------------------------------------------------

P O S T G R E S Q L

8 . 0 O P E N I T E M S

Current version at ftp://momjian.postgresql.org/pub/postgresql/open_items.

Changes
-------
* Win32
o binary version stamps
o signal safe socket handler
o query cancel in psql (?)
o Report correct errno codes from native Windows system calls
o Shorten timezone for %t log_line_prefix
o start pg_autovacuum easily
o fix pitr file copy syntax
* fix dbsize and oid2name for tablespaces
* allow libpq to check parameterized data types
* make pgxs install the default
* add xid to log_line_prefix for PITR
* add psql tab completion for tablespaces
* cleanup FRONTEND use in /port, malloc, elog
* disable vacuum delay?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgman wrote:

Marc G. Fournier wrote:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Speak now, or forever hold your piece :)

The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.

OK, I think Jan agreed not to have vacuum delay enabled by default so I
backed out his patch to it is now disabled.

Patch attached and applied.

I think this means we are ready for beta1.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andreas Pflug wrote:

Bruce Momjian wrote:

Marc G. Fournier wrote:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Speak now, or forever hold your piece :)

Well, there's the logfile rotation issue...

With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.

The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.

I hereby report Win32 as building good :-)
The former confusion was caused by me, doing the bloody "failed to make
distclean" mistake.

No problem. I disabled vacuum delay so we are ready to go!

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The only open issue I see for beta1 is perhaps disabling vacuum delay.

Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.

regards, tom lane

Andreas Pflug wrote:

Bruce Momjian wrote:

Well, there's the logfile rotation issue...

With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.

How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.

Adding a function will require a system catalog change. If we are
already doing one we might be able to get it in, but I doubt it greatly.

We already do more than rotatelogs by specifying a size. That seems
enough to me for now.

Basically I think you will need a vote to expand this in 8.1.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The only open issue I see for beta1 is perhaps disabling vacuum delay.

Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.

Done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

"Marc G. Fournier" <scrappy@postgresql.org> writes:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Looks good from here. I plan to spend the afternoon doing docs work,
not touching any code unless some last-minute bug report shows up.

regards, tom lane

Tom Lane wrote:

"Marc G. Fournier" <scrappy@postgresql.org> writes:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Looks good from here. I plan to spend the afternoon doing docs work,
not touching any code unless some last-minute bug report shows up.

Good. I am heading out. My cell is 610-742-9657 if anyone wants me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Marc G. Fournier wrote:

'k, saw Bruce's commit for the pgport stuff under Win32 ... is anyone
sitting on that 'one last thing' that should be fixed/corrected before
Beta proceeds, or am I clear for doing the bundle up tonight for an
announce tomorrow?

Speak now, or forever hold your piece :)

Well, there's the logfile rotation issue...

The only open issue I see for beta1 is perhaps disabling vacuum delay.
And I would like to have a good Win32 build report from Andreas.

I hereby report Win32 as building good :-)
The former confusion was caused by me, doing the bloody "failed to make
distclean" mistake.

Regards,
Andreas

Bruce Momjian wrote:

Well, there's the logfile rotation issue...

With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.

How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.

You can always find a program that doesn't support a specific feature.
And pgsql is probably more comparable to MSSQL, which has it, than to
Apache's rotatelogs, which doesn't even support size triggering.

Omitting the handler will not even leave a chance to implement an add-on
function.

Regards,
Andreas

Bruce Momjian wrote:

How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.

Adding a function will require a system catalog change.

Not necessarily. pg_logdir_ls is not included either, so pgadmin already
needs an additional module to handle the logfiles. Handling
pg_logfile_rotate the same isn't a problem. But if the logger is
autistic and unable to handle a signal, no chance.

If you say "we won't change the system catalog just for these two
functions", I can live with that, hoping they slip in following
something's wake.

Regards,
Andreas

On Sun, 8 Aug 2004, Bruce Momjian wrote:

Andreas Pflug wrote:

Bruce Momjian wrote:

Well, there's the logfile rotation issue...

With rotatelogs not supporting it, it is hard to argue we should,
especially this close to beta. We can revisit it in 8.1.

How about 8.0Beta2? I consider this as a bug, after all postings for
logfiles did support it.

Adding a function will require a system catalog change. If we are
already doing one we might be able to get it in, but I doubt it greatly.

We already do more than rotatelogs by specifying a size. That seems
enough to me for now.

Basically I think you will need a vote to expand this in 8.1.

Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Sun, 8 Aug 2004, Andreas Pflug wrote:

Marc G. Fournier wrote:

Basically I think you will need a vote to expand this in 8.1.

Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(

Summary:

The patch I originally posted (in June) implemented a log rotation, which was
triggered by call to a function, not automatically (subject to a
to-be-written surveillance process), and implemented inside elog.c (more or
less). Tom had many objections, and this emerged to the current
implementation of a subprocess that will do rotation automatically dependent
on size and/or age limits and seems valuable.

'k, for me, as long as it has these two, I'm happy ... that falls in line
with all the ones that I'm used to ...

My postings also included manual triggering of logfile switching,
catching SIGUSR1 (from SendPostmasterSignal) and setting the flag which
otherwise is set by exceeding of configured size/age limit or a
postgresql.conf settings change (SIGHUP triggered).

The only 'server' that I've ever seen this in was aolserver ... and I wish
they'd implement per-size/age ones instead :(

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(

The question is whether the new syslogger subprocess has enough features
or not ;-). What it's got is two parameters: switch to a new log file
at least every N minutes, and at least every N kilobytes of log output.
Bruce and I think that's enough. Andreas wants database users to be
able to force it to switch to a new log file on demand.

I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.

regards, tom lane

On Sun, 2004-08-08 at 09:58, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The only open issue I see for beta1 is perhaps disabling vacuum delay.

Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convince more people.

Does this mean the feature wont be in 8.0, or that it will be set to 0
page delay by default?

"Scott Marlowe" <smarlowe@qwest.net> writes:

Does this mean the feature wont be in 8.0, or that it will be set to 0
page delay by default?

It will have zero delay by default (pending some more convincing
arguments that is). No one has suggested removing it.

regards, tom lane

Andreas Pflug <pgadmin@pse-consulting.de> writes:

Tom Lane wrote:

I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.

This is a bit contradictionary. pgsql allows any superuser to shoot
himself into his foot (citation: TGL) in many places, e.g. "delete from
pg_class".

There's some significant differences there. In the first place, the
system catalogs are inherently something that is properly manipulated at
the SQL level. In the second place, we have years of experience showing
that it is useful to be able to manipulate them from SQL, see eg
http://developer.postgresql.org/docs/postgres/release-7-4-2.html.
Which is why the occasional proposals about forbidding superusers from
mucking with the catalogs for safety's sake have always been shot down.

The postmaster log isn't an SQL object, so shouldn't really be
manipulated from SQL; and there is zero field experience to suggest that
the time-and-size rotation parameters aren't sufficient for it.

We can always add something later if experience with 8.0 shows that it's
actually needed. But taking out useless features after they've been in
for a release or two is much more painful.

regards, tom lane

Marc G. Fournier wrote:

Basically I think you will need a vote to expand this in 8.1.

Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(

Summary:

The patch I originally posted (in June) implemented a log rotation,
which was triggered by call to a function, not automatically (subject to
a to-be-written surveillance process), and implemented inside elog.c
(more or less). Tom had many objections, and this emerged to the current
implementation of a subprocess that will do rotation automatically
dependent on size and/or age limits and seems valuable.
My postings also included manual triggering of logfile switching,
catching SIGUSR1 (from SendPostmasterSignal) and setting the flag which
otherwise is set by exceeding of configured size/age limit or a
postgresql.conf settings change (SIGHUP triggered).
Signal handling is not a big deal, but can't be coded with a contrib module.

Tom believes nobody needs that, and fears decreased reliability.

Regards,
Andreas

Tom Lane wrote:

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Hate to ask, but can someone summarize what it is that is being
"discussed" here? Andreas' post about 'size triggering' is what drew my
eye, but I think I missed the central point :(

Andreas wants database users to be
able to force it to switch to a new log file on demand.

superuser only, of course.

I don't think the latter is a particularly good idea for a number of
reasons, but probably the main one is that I don't think users should be
directly fooling with the server logs.

This is a bit contradictionary. pgsql allows any superuser to shoot
himself into his foot (citation: TGL) in many places, e.g. "delete from
pg_class". He may delete logfiles while in use, but not trigger the
rotation in an official way, which doesn't seem particularly harmful
(fooling with log_rotation_age and sighup would be a dubious workaround).

Regards,
Andreas