Joe Conway wrote:
> Bruce Momjian wrote:
> > Christopher Kings-Lynne wrote:
> >>Well, I note (and I'm not being unkind or anything here) that a lot of
> >>the high level committers we have haven't been so active this release.
> >>Peter and Joe haven't been around much and Jan has been busy with S
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Well, I note (and I'm not being unkind or anything here) that a lot of
the high level committers we have haven't been so active this release.
Peter and Joe haven't been around much and Jan has been busy with Slony.
I think this is (in part at l
Oliver Elphick <[EMAIL PROTECTED]> writes:
> ...
> The point of this explanation is that as Debian maintainer I would have
> to disable any procedures that attempt to edit these conffiles, or at
> least ensure that their operation is under package control and produce
> only the effects that I desir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 13 July 2004 7:33 pm, Christopher Kings-Lynne wrote:
>
> PHP's the same. Absolutely dreadful. They put all sorts of new
> features mixed in with security and bug fixes in their minor releases.
> The NUMBER OF TIMES I've upgraded PHP to fix
Can you give us some suggestions of what kind of stuff to test? Is
there a way we can artificially kill the backend in all sorts of nasty
spots to see if recovery works? Does kill -9 simulate a 'power off'?
Chris
Simon Riggs wrote:
PITR Patch v5_1 just posted has Point in Time Recovery working
Marc G. Fournier wrote:
As Jan points out, its the 'small features that are done' that we've
been griping about having to wait for, not the big ones which we know
aren't done ...
Hmmm... so we do things slightly differently than previously...
This upcoming version could be PG version 8.0,
We co
The thoughts behind the process might be good, but do we have examples
where it has worked out well? The 2.4 series seems to have been
particularly bad for new major issues in their stable releases.
PHP's the same. Absolutely dreadful. They put all sorts of new
features mixed in with security an
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I think you guys just need to learn to become comf
God, we still have clients using 7.2 servers, cause they've had no
reason yet to upgrade to the latest ... "it works, why upgrade?" is
generally the opinion ...
Because there's shocking failure-to-restart bugs in 7.2...and if you
upgrade to 7.4 you're forced to get new features as well.
Chris
-
On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented tho
> However, looking at how the Linux community handles it, I think we can
> borrow a lot of concepts from them.
I was thinking quite the opposite. The Linux community doesn't exactly
have a great track-record for their stable releases.
The thoughts behind the process might be good, but do we have
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Regarding the encoding/locale matching issue, here's another test
> routine I would like you to run if you want to see your operating
> system supported.
Oh, disregard previous complaint then...
On HPUX 10.20 I get
--snip--
SJIS
arabic8
big5
ccdc
e
On Monday 12 July 2004 17:10, Merlin Moncure wrote:
> IMO, forcing su password at initdb time (allowing blank password with a
> very stern warning) and bumping localhost to auth is the right way to
> go. As far as RPM's, etc. I don't think RPM considerations should be
> driving security concerns.
On Tue, 13 Jul 2004, Bruce Momjian wrote:
The nice thing about doing something lke that is those small features
would get a degree of testing happening in a live environment ...
Of course that last sentence is the downside too --- people don't want
to have to retest their setups after a minor relea
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> >> The nice thing about doing something lke that is those small features
> >> would get a degree of testing happening in a live environment ...
> >
> > Of course that last sentence is the downside too --- people don't want
> >
On Tue, 2004-07-13 at 13:03 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't
On Tue, 13 Jul 2004, Bruce Momjian wrote:
We have always recommended upgrading to the most recent minor release,
at least as a project policy for support. Also, the upgrade is only
stop/install/restart so it is quite easy to do, and folks like the fact
they don't have to test for new functional
On Wed, 2004-07-14 at 00:01, Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > So the situation is:
> > > - You must only stop recovery at a point in time (in the logs) after the
> > > backup had completed.
> >
> > Right.
> >
> > > No way to enforce that cu
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > I was thinking of something much simpler where Jan would create an ARC
> > patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> > ftp servers, or on a web site. I could create a mechanism so SELECT
>
Simon Riggs wrote:
> On Tue, 2004-07-13 at 22:19, Tom Lane wrote:
>
> > To have a consistent recovery at all, you must replay the log starting
> > from a checkpoint before the backup began and extending to the time that
> > the backup finished. You only get to decide where to stop after that
> >
PITR Patch v5_1 just posted has Point in Time Recovery working
Still some rough edgesbut we really need some testers now to give
this a try and let me know what you think.
Klaus Naumann and Mark Wong are the only [non-committers] to have tried
to run the code (and let me know about it), s
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've worked out a scheme that should adequately detect encoding
> mismatches in initdb. Please comment on the following behavior.
The behavioral description sounds fine, but I was eagerly awaiting your
description of exactly how you'd test for compa
On Tue, 13 Jul 2004, Lamar Owen wrote:
But Tom's assertion is true. We have enough trouble getting patches
rolled out; adding parallel branches is just begging for trouble, due to
our relatively small resource size. Although, we probably have enough
developers at this point to make it happen.
On Tue, 13 Jul 2004, Bruce Momjian wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I thi
On Wed, 14 Jul 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
Nobody would be required to upgrade to a new minor release either ...
nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. W
On Tue, 13 Jul 2004, Tom Lane wrote:
We could certainly do something along that line if we had a few people
willing to be "gatekeepers". We'd have to work harder at making the
release generation process open and documented though. Right now there
are plenty of steps that only you, Bruce, or La
On Wed, 2004-07-14 at 00:28, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, but procedurally, how do you correlate the start/stop time of the
> > tar backup with the WAL numeric file names?
>
> Ideally the procedure for making a backup would go something like:
>
> 1. Inquire
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, but procedurally, how do you correlate the start/stop time of the
> tar backup with the WAL numeric file names?
Ideally the procedure for making a backup would go something like:
1. Inquire of the server its current time and the WAL position of the
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So the situation is:
> > - You must only stop recovery at a point in time (in the logs) after the
> > backup had completed.
>
> Right.
>
> > No way to enforce that currently, apart from procedurally. Not exactly
> > frequent, so I thi
Robert Treat wrote:
> > Woh, I didn't think we agreed that the default would change from
> > 'trust', only that we would now emit a warning and allow other
> > authentication methods to be specified at initdb time.
> >
>
> I sure hope not (and that was my understanding as well)
>
> Incidentally
On Tue, 2004-07-13 at 23:42, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Tue, 2004-07-13 at 22:19, Tom Lane wrote:
> >
> > > To have a consistent recovery at all, you must replay the log starting
> > > from a checkpoint before the backup began and extending to the time that
> > > the backup f
On Tue, 2004-07-13 at 17:44, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > not to mention the
> > >more basic problem that the comments will now be wrong.
> >
> > That, however, it is correct :-( Sloppy.
> >
> > How about a text along the line of:
> > CAUTION: Configuring the system for "tr
Simon Riggs <[EMAIL PROTECTED]> writes:
> So the situation is:
> - You must only stop recovery at a point in time (in the logs) after the
> backup had completed.
Right.
> No way to enforce that currently, apart from procedurally. Not exactly
> frequent, so I think I just document that and move o
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > We have always recommended upgrading to the most recent minor release,
> > at least as a project policy for support. Also, the upgrade is only
> > stop/install/restart so it is quite easy to do, and folks like the fact
>
Tom Lane wrote:
> The behavioral description sounds fine, but I was eagerly awaiting
> your description of exactly how you'd test for compatibility or
> search for a compatible encoding ... without that algorithm the whole
> thing's moot.
It's just an explicit list of things that spell similarly.
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> But Tom's assertion is true. We have enough trouble getting patches
>> rolled out; adding parallel branches is just begging for trouble, due to
>> our relatively small resource size. Although, we probably
On Tue, 2004-07-13 at 22:27, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think --ident would be very helpful, and we know with OS's support
> > ident too.
>
> If we're going to be doing sed-like substitutions on pg_hba.conf.sample,
> then we really really wanna discourage dis
Marc G. Fournier wrote:
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. When there are bug fix updates, you use
On Tue, 2004-07-13 at 22:19, Tom Lane wrote:
> To have a consistent recovery at all, you must replay the log starting
> from a checkpoint before the backup began and extending to the time that
> the backup finished. You only get to decide where to stop after that
> point.
>
So the situation is:
On Tuesday 13 July 2004 08:52 am, Jan Wieck wrote:
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>
Take my opinion with a g
Magnus Hagander wrote:
> > not to mention the
> >more basic problem that the comments will now be wrong.
>
> That, however, it is correct :-( Sloppy.
>
> How about a text along the line of:
> CAUTION: Configuring the system for "trust" authentication allows any
> local user to connect using any P
Magnus Hagander wrote:
> >>> The only part of this discussion that I'd really be prepared=20
> >>> to buy into
> >>> is the part about *if* you use -W or --pwfile, then set up
> >pg_hba.conf
> >>> with MD5 as the default auth (because that's probably what the user
> >>> wants anyway).
> >
> >> Ok.
On Tuesday 13 July 2004 17:12, Marc G. Fournier wrote:
> ... there is alot of stuff that doesn't require a reload of the database
> (or initdb) that could very easily be backpatched ...
> As Jan points out, its the 'small features that are done' that we've been
> griping about having to wait for,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Might still be worth adding "--ident" as a parameter anyway, but in that
>> case only to help the distros that need it. Or not, because they already
>> have a way to deal with it.
> I think --ident would be very helpful, and we
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm getting carried away with the improbablebut this is the rather
> strange, but possible scenario I foresee:
> A sequence of times...
> 1. We start archiving xlogs
> 2. We take a checkpoint
> 3. we commit an important transaction
> 4. We take a backu
>>> The only part of this discussion that I'd really be prepared=20
>>> to buy into
>>> is the part about *if* you use -W or --pwfile, then set up
>pg_hba.conf
>>> with MD5 as the default auth (because that's probably what the user
>>> wants anyway).
>
>> Ok. Here is a patch that does this.
>
>...
should be fixed now ... please let me know if it isn't working (or if you
notice any other problems) ... upgrade to 1.11.17 of CVS is complete ...
On Tue, 13 Jul 2004, Simon Riggs wrote:
On Tue, 2004-07-13 at 02:44, Marc G. Fournier wrote:
temporarily while I figure out what I screwed up that all
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> The only part of this discussion that I'd really be prepared=20
>> to buy into
>> is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
>> with MD5 as the default auth (because that's probably what the user
>> wants anyway).
> Ok. H
Marc G. Fournier wrote:
>
> Note that I'm all for a long (2 year? or even 'indefinite') development
> cycle for a major release if we continue on with what has been happening
> more often lately, where stuff is back patched to the last stable release
> ... there is alot of stuff that doesn't re
Note that I'm all for a long (2 year? or even 'indefinite') development
cycle for a major release if we continue on with what has been happening
more often lately, where stuff is back patched to the last stable release
... there is alot of stuff that doesn't require a reload of the database
(or
I've been thinking about what to do with cursors in subtransactions.
The problem really includes both cursors (created with DECLARE CURSOR)
and portals (created with the V3-protocol Bind message) since they are
the same kind of animal internally, namely a Portal. In previous
discussion I think eve
Magnus Hagander wrote:
> >The only part of this discussion that I'd really be prepared
> >to buy into
> >is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
> >with MD5 as the default auth (because that's probably what the user
> >wants anyway). But otherwise I think we should
On Tue, 2004-07-13 at 15:29, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Please tell me that we can ignore the state of the clog,
>
> We can.
>
In general, you are of course correct.
> The reason that keeping track of timelines is interesting for xlog is
> simply to take pity
Regarding the encoding/locale matching issue, here's another test
routine I would like you to run if you want to see your operating
system supported. It reflects more accurately the actual
implementation I'm working on.
Compile the attached test program and then run
for x in `locale -a`; do L
>The only part of this discussion that I'd really be prepared
>to buy into
>is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
>with MD5 as the default auth (because that's probably what the user
>wants anyway). But otherwise I think we should leave initdb's behavior
>alone.
I've worked out a scheme that should adequately detect encoding
mismatches in initdb. Please comment on the following behavior.
The locale is still taken from the environment or the command line; no
change.
If the locale is C or POSIX, then we set the encoding to SQL_ASCII or
whatever was spe
Josh Berkus wrote:
> ( This is
> probably why many American corporations end their fiscal year in
> midsummer; nothing is going to get done anyway, might as well clean
> up. )
And that is also the time when volunteers will have the most time to
spare.
--
Peter Eisentraut
http://developer.postgr
Dennsnippetssklund wrote:
> On Fri, 9 Jul 2004, Mike Rylander wrote:
>
>> Nested transactions and savepoints serve two different purposes. They
>> have some overlap, but for the most part solve two distinct problems.
>
> Then show some examples that illustrait the difference. So far all
> exa
Dennis Bjorklund wrote:
> On Sat, 10 Jul 2004, Mike Rylander wrote:
>
>> They do, if only to make particular constructs easier to write. This is
>> an opinion, but for example an EXCEPTION framework for plpgsql would be
>> easier to implement and use if it used the nested transactions rather
>
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> On Sat, Jul 10, 2004 at 09:18:28PM -0700, elein wrote:
>>> The new plperl returns sets by having
>>> the function return an array.
>
>> I think RETURN NEXT does the same thing anyway ... they just store
>> tuples in a Tuplestore an
Marc G. Fournier wrote:
Damn ... I'll have to look at it ... we had a hacker get in through the
way anoncvs was setup, so I set a passwd on in /etc/passwd (but didn't
touch the anoncvs setup itself) ... will play with it tonight and see if
I can figure out how to do a more secure anon-cvs ;( I
On Tue, 13 Jul 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Tue, 13 Jul 2004, Bruce Momjian wrote:
True, but northern-hemisphere summer is only 6 weeks old, and we have
had these issues for many months --- it isn't a new problem. Alvaro
didn't get the feedback he needed in March either.
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > True, but northern-hemisphere summer is only 6 weeks old, and we have
> > had these issues for many months --- it isn't a new problem. Alvaro
> > didn't get the feedback he needed in March either. :-(
>
> This is true,
On Tue, 13 Jul 2004, Bruce Momjian wrote:
True, but northern-hemisphere summer is only 6 weeks old, and we have
had these issues for many months --- it isn't a new problem. Alvaro
didn't get the feedback he needed in March either. :-(
This is true, but Josh does have a point ... you took a much
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Of course this all ties into the pain of having to dump/reload large
> >> databases, and maybe if we had working pg_upgrade the adoption rate
> >> would be faster, but I'm not at all sure of that. We're playing in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Of course this all ties into the pain of having to dump/reload large
>> databases, and maybe if we had working pg_upgrade the adoption rate
>> would be faster, but I'm not at all sure of that. We're playing in
>> a different league now
Bruce Momjian wrote:
> > The result is that we chronically have less manpower when just when we need
> > everybody. And some of us end up spending 11 hours a day in front of the
> > screen when we should be outside soaking up Vitamin D.
> >
> > Therefore, I propose that the next version either
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The issue as I see it is not reviewing patches, but defining features.
> Someone sets out to develop "nested transactions", and three days after
> feature freeze we have the first large discussion about what nested
> transactions really are, what t
Josh Berkus wrote:
> Chris, all:
>
> > Well, I note (and I'm not being unkind or anything here) that a lot of
> > the high level committers we have haven't been so active this release.
> > Peter and Joe haven't been around much and Jan has been busy with Slony.
> > We also lost Thomas Lockhart.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't be that big of a deal to release mo
Chris, all:
> Well, I note (and I'm not being unkind or anything here) that a lot of
> the high level committers we have haven't been so active this release.
> Peter and Joe haven't been around much and Jan has been busy with Slony.
> We also lost Thomas Lockhart. Neil's also away on holidays.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> I think in the future we have to force all large features, those that
>> probably need more than 6 months of development time, to be properly
>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
> Alvaro starte
At this stage, I would be happy adding --ident to enable only ident, and
-W/--pwfile to enable only MD5, and allow initdb to default to full
local access (with a warning printed that package builders would at
least see).
---
Robert Treat <[EMAIL PROTECTED]> writes:
> I am sure Chris would back me up on saying that the inability to
> authenticate a database connection is the #1 support problem on the
> phppgadmin mailing lists and you want to make this harder for
> people??
The other thing that bothers me about t
Bruce Momjian wrote:
> I am not sure what can be done to solve this in the future. There
> are only a limited number of us who have the experience and time to
> review and comment on very complex patches.
The issue as I see it is not reviewing patches, but defining features.
Someone sets out to
On Jul 13, 2004, at 17:02, Bruce Momjian wrote:
One failing that has appeared during the 7.5 development cycle is that
we as a community haven't been able to provide timely feedback to
developers working on large feature additions.
I am particularly thinking of Alvaro (nested transactions) and Simo
On 7/11/2004 12:22 AM, Alvaro Herrera wrote:
There is not a lot of difference. This was allowed in nested
transactions because we wanted the nesting be to OK when using it in a
possibly aborted transaction block, so the user would not commit a
transaction that could not have been created. In save
On 7/10/2004 6:55 PM, Josh Berkus wrote:
Bruce,
It seems anonymous savepoints really don't buy us anything. They don't
match the Oracle behavior, and don't do anything more than nested
transactions. I agree we want them, but I don't see the value they add
value right now.
Anonymous Savepoints == N
On 7/10/2004 11:02 PM, Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Marc isn't the only one who didn't like waiting for more features going
into 7.5 two mont
Jan Wieck wrote:
> On 7/10/2004 11:02 PM, Bruce Momjian wrote:
>
> > If you get full control of PostgreSQL, you can dictate what will happen.
> > Until then, I will follow the community consensus, which may or may not
> > match your opinion.
>
> Marc isn't the only one who didn't like waiting for
On Tue, 2004-07-13 at 11:03, Magnus Hagander wrote:
> > >> This isn't happening for a number of reasons, the most
> > obvious being
> > >> that we cannot require initdb to be run interactively.
> > (That stern
> > >> warning will not impress /dev/null.)
> >
> > > This is the very reason --pwf
Christopher Kings-Lynne wrote:
> > One failing that has appeared during the 7.5 development cycle is that
> > we as a community haven't been able to provide timely feedback to
> > developers working on large feature additions.
> >
> > I am particularly thinking of Alvaro (nested transactions) and
> >> This isn't happening for a number of reasons, the most
> obvious being
> >> that we cannot require initdb to be run interactively.
> (That stern
> >> warning will not impress /dev/null.)
>
> > This is the very reason --pwfile was added.
>
> No, that does not address the objection in the
Simon Riggs <[EMAIL PROTECTED]> writes:
> Please tell me that we can ignore the state of the clog,
We can.
The reason that keeping track of timelines is interesting for xlog is
simply to take pity on the poor DBA who needs to distinguish the various
archived xlog files he's got laying about, and
One failing that has appeared during the 7.5 development cycle is that
we as a community haven't been able to provide timely feedback to
developers working on large feature additions.
I am particularly thinking of Alvaro (nested transactions) and Simon
(PITR), where we haven't been able to give the
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> This isn't happening for a number of reasons, the most
>> obvious being that we cannot require initdb to be run
>> interactively. (That stern warning will not impress /dev/null.)
> This is the very reason --pwfile was added.
No, that does not ad
One failing that has appeared during the 7.5 development cycle is that
we as a community haven't been able to provide timely feedback to
developers working on large feature additions.
I am particularly thinking of Alvaro (nested transactions) and Simon
(PITR), where we haven't been able to give th
Josh Berkus wrote:
> Robert, Bruce,
>
> > > > If anybody still has access to that page, the project has moved to
> > > > gborg specifically over to
> > > >
> > > > http://gborg.postgresql.org/project/mysql2psql/projdisplay.php
> > > >
> > > > where a new version of the perl conversion script is lo
On Tue, 2004-07-13 at 13:18, Zeugswetter Andreas SB SD wrote:
> > The starting a new timeline thought works for xlogs, but not for clogs.
> > No matter how far you go into the future, there is a small (yet
> > vanishing) possibility that there is a yet undiscovered committed
> > transaction in the
> The starting a new timeline thought works for xlogs, but not for clogs.
> No matter how far you go into the future, there is a small (yet
> vanishing) possibility that there is a yet undiscovered committed
> transaction in the future. (Because transactions are ordered in the clog
> because xids
On Tue, 2004-07-06 at 22:40, Simon Riggs wrote:
> On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > > - when we stop, keep reading records until EOF, just don't apply them.
> > > When we write a checkpoint at end of recovery, the unapplied
> > > transac
On Tue, 2004-07-13 at 02:44, Marc G. Fournier wrote:
> temporarily while I figure out what I screwed up that allowed a hacker to
> make use of he anoncvs account :( and, no, anoncvs doesn't have access to
> the core cvsroot ...
>
> On Tue, 13 Jul 2004, Christopher Kings-Lynne wrote:
>
> > -bas
Magnus Hagander wrote:
> This is the very reason --pwfile was added. It's not just a win32
> fix, it's a "any packager that needs to run without interactivity"
> fix. Yes, you can stick a blank password in there, but again, this is
> a choice and not a default in that case.
No, that's not what it
> It has probably be said before, but new users need to be able
> to get up and running on their *development* system quickly.
> Throwing new users for a loop with the password configuration
> issues would be a problem.
This is exactly the argument that was thrown out when people wanted to
be
> > IMO, forcing su password at initdb time (allowing blank
> password with
> > a very stern warning) and bumping localhost to auth is the
> right way
> > to go.
>
> This isn't happening for a number of reasons, the most
> obvious being that we cannot require initdb to be run
> interactively
So what are we going to do about this problem?
The pg_settings view does not have enough information to determine it
generically. (It only says 'string', not 'list'...)
I propose that we modify pg_dumpall to hard-code the set of list-type
GUC variables for each backend version.
The current (CV
> >>No, but none of the others are better. See previous discussions in
> >>the archives. I don't think the situation has changed any
> since the
> >>last time we hashed this out.
> >
> > If they supply a password to initdb, shouldn't we then require a
> > password in pg_hba.conf.
>
> This i
As part of my testing, I noticed this bug. My database has a
search_path set in the database vars. It dumps lik ethis:
DROP DATABASE usa;
CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
'LATIN1';
ALTER DATABASE usa SET search_path TO 'public, contrib';
Notice the sing
If you ALTER USER the cluster owner (eg. 'postgres') to set a user GUC
variable, it is not dumped in any way.
I see that we're really trying to avoid referring to the cluster owner
by name, but shall I just go ahead and fix it by making it output an
ALTER USER for the cluster owner in this case
99 matches
Mail list logo
