Tom Lane wrote:
Attached is a draft patch for the WAL-and-freezing issues we've been
discussing. This incorporates Heikki and Simon's work on providing
WAL-logging for tuple freezing actions and pg_clog truncation
respectively, and adds on several other things:
Looks good. Just a few notes:
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
Heikki Linnakangas [EMAIL PROTECTED] writes:
The patch seems to make VACUUM FULL FREEZE combination valid again,
which should be note in the docs.
Right, I haven't gotten around to fixing the VACUUM ref page yet but
this change is needed. This is really fallout from Alvaro's previous
changes
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Looking back in the archives, I note that one of the arguments for
making the server use relative paths everywhere was so that it'd be
robust against things like DBAs moving directories that contain live
On Sun, 2006-11-05 at 11:10 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
Looking back in the archives, I note that one of the arguments for
making the server use relative paths everywhere was so that it'd be
robust against
Simon Riggs [EMAIL PROTECTED] writes:
I'm pretty sure most people don't move live postmasters very frequently,
plus it isn't clear to me why we should support the people that want
that to do that, yet not the people who want the absolute-path option.
As already discussed upthread, anyone who
On Sun, 2006-11-05 at 11:49 -0500, Tom Lane wrote:
I don't see why we should go out of our way to
provide a bad substitute for pwd.
That argument is conclusive. Agreed.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of
I have made some progress with what I think is needed to have two
interpreters for plperl. This is a lot harder than the pltcl case for
two reasons: 1. there are no restrictions on having 2 tcl interpreters,
and 2. tcl does not need to save and restore context as we have to do
with perl. I
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
I think we're probably better off to just forcibly remove the init file
during post-recovery cleanup. The easiest place to do this might be
BuildFlatFiles, which has to scan pg_database anyway ...
Patch enclosed.
Clean apply to HEAD, make
I wrote:
I have made some progress with what I think is needed to have two
interpreters for plperl. This is a lot harder than the pltcl case for
two reasons: 1. there are no restrictions on having 2 tcl
interpreters, and 2. tcl does not need to save and restore context as
we have to do
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
I think we're probably better off to just forcibly remove the init file
during post-recovery cleanup. The easiest place to do this might be
BuildFlatFiles, which has to scan pg_database anyway ...
Patch
On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
Perhaps use a PG_TRY construct?
At least for the existing code, this doesn't work well: the function
exits early via ereport(LOG) and then return STATUS_ERROR;, so AFAICS
there isn't an easy way to simplify the existing error handling logic
via
Neil Conway [EMAIL PROTECTED] writes:
On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
Perhaps use a PG_TRY construct?
At least for the existing code, this doesn't work well: the function
exits early via ereport(LOG) and then return STATUS_ERROR;, so AFAICS
there isn't an easy way to
I wrote:
... Not sure that
this is actually a net win though, as a PANIC might well be considered a
worse problem than a one-time leak of some LDAP state.
Come to think of it: either elog(ERROR) or a failure return from
CheckLDAPAuth is going to lead directly to backend exit, so the
whole
On Sun, 2006-11-05 at 19:28 -0500, Tom Lane wrote:
Come to think of it: either elog(ERROR) or a failure return from
CheckLDAPAuth is going to lead directly to backend exit, so the
whole thing is pretty much a cosmetic issue anyway.
Thanks for the feedback. Patch applied, with an additional
On 10/13/06, Guillaume Lelarge [EMAIL PROTECTED] wrote:
Peter Eisentraut a écrit :
There is an inconsistency here: 'IYYY' is the four-digit ISO year, 'IW'
is the two-digit ISO week, but 'ID' would be the one-digit ISO
day-of-the-week. I'm not sure we can fix that, but I wanted to point
it
16 matches
Mail list logo