On Thu, 11 Dec 2003, Alvaro Herrera Munoz wrote:
> On Thu, Dec 11, 2003 at 06:03:05PM -0400, Peter Eisentraut - PostgreSQL wrote:
>
> > Modified files:
> > src/bin/initdb : nls.mk
> > Added files:
> > src/bin/initdb/po: it.po
>
> Are you going to keep managing these things? I received you
On Thu, Dec 11, 2003 at 06:03:05PM -0400, Peter Eisentraut - PostgreSQL wrote:
> Modified files:
> src/bin/initdb : nls.mk
> Added files:
> src/bin/initdb/po: it.po
Are you going to keep managing these things? I received your email about a
CVS write account so I could handle them f
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut - PostgreSQL wrote:
> >> Cleanup on --help-config: Now called --describe-config, no further options,
> >> machine readable, without headers, not sorted.
>
> > Don't we need to document this? I don't see any SGML comm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut - PostgreSQL wrote:
>> Cleanup on --help-config: Now called --describe-config, no further options,
>> machine readable, without headers, not sorted.
> Don't we need to document this? I don't see any SGML commits above.
It wasn't docume
Peter Eisentraut - PostgreSQL wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 03/10/18 19:59:09
>
> Modified files:
> src/backend/main: main.c
> src/backend/tcop: postgres.c
> src/backend/utils/misc: guc.c help_config.c
>
[EMAIL PROTECTED] (Peter Eisentraut - PostgreSQL) writes:
> Log message:
> Information schema fixes:
Now that that's done, are we going to force initdb to ensure the changes
take effect?
regards, tom lane
---(end of broadcast)
On Fri, 10 Oct 2003 12:45 am, Bruce Momjian wrote:
> My gcc 2.95.3 manual says:
>
>-pipe Use pipes rather than temporary files for communi-
> [snip]
> so it looks like we can't use it on all platforms without testing. I
> will enable it for linux. Do people want to test other platforms?
Philip Yarra wrote:
> On Fri, 10 Oct 2003 12:45 am, Bruce Momjian wrote:
> > My gcc 2.95.3 manual says:
> >
> >-pipe Use pipes rather than temporary files for communi-
> > [snip]
> > so it looks like we can't use it on all platforms without testing. I
> > will enable it for linux. Do pe
Neil Conway wrote:
> On Thu, 2003-10-09 at 09:35, Bruce Momjian wrote:
> > I only put back what was already there --- not sure why others don't use
> > it. You want it enabled on Linux?
>
> Well, why do we have it enabled at all? If it's to speed compilation, we
> may as well enable it on other p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> But I wonder how this squares with the SQL spec...
> The root of this problem is that revoking privileges from the owner
> doesn't square with the SQL spec in the first place. Allowing having a
> grant option without the privilege
Tom Lane writes:
> So an owner can never revoke his own grant options? That seems
> reasonable offhand, and compatible with our previous notion that
> the owner's ability to GRANT was inherent and nonrevocable.
>
> But I wonder how this squares with the SQL spec...
The root of this problem is th
[EMAIL PROTECTED] (Peter Eisentraut - PostgreSQL) writes:
> When revoking privileges from the owner, don't revoke the grant options,
> to avoid recursively revoking everything from everyone.
So an owner can never revoke his own grant options? That seems
reasonable offhand, and compati
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
> "Marc G. Fournier" wrote:
> >
> > On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
> >
> > > He also ignored my question about "2 phase commit" in pgsql-hackers, for
> > > example.
> >
> > Actually, I've been following that thread pretty closely, and I believ
"Marc G. Fournier" wrote:
>
> On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
>
> > He also ignored my question about "2 phase commit" in pgsql-hackers, for
> > example.
>
> Actually, I've been following that thread pretty closely, and I believe I
> missed your question :(
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> tlist_matches_tupdesc() needs to defend itself against dropped columns.
> Tom, does this duplicate a patch in the patch queue, or is it separate?
No, it was not from the patch queue. Joe's patch addresses some other
issues.
Tom Lane wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 03/09/25 16:41:49
>
> Modified files:
> src/backend/executor: execScan.c
>
> Log message:
> tlist_matches_tupdesc() needs to defend itself against dropped columns.
Tom, does
Tom Lane wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 02/12/13 15:35:57
>
> Modified files:
> src/test/regress: resultmap
> Added files:
> src/test/regress/expected: geometry_1.out
> Removed files:
> src/test/regress/expect
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I found an HP whitepaper on the large file support and it seems they don't
> have the problem of missing declarations.
> http://docs.hp.com/hpux/onlinedocs/os/lgfiles4.pdf
> Note the example in section 6.4.1. On page 37 they grep the preprocessed
> s
Tom Lane writes:
> What I'm currently thinking we should do is default largefile support to
> off in HPUX < 11.0; is there a convenient way to accomplish that in
> autoconf?
Something like this maybe (before AC_SYS_LARGEFILE):
case $host_os in hpuxZYX*)
if test "${enable_largefile+set}" != set;
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Sorry to hear that this is the way it turned out. It is a bad precedent
> imho, and I see no way forward on my interest in this area. Hopefully
> someone else will pick it up; perhaps one of those so vehemently against
> the details of this?
I said I
Yes, perhaps a bad precedent. I have very rarely done this. I do have
the patch here if anyone wants to use it. My guess is if someone
implements it, it will be done only in initdb, and use symlinks, which
you and Marc don't like, so we may be best leaving it undone for 7.3 and
returning with
> OK, with two people now asking to have the patch removed, and with no
> comment from Thomas, I have removed the patch. This removes XLogDir
> environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
> I have also removed the code that dynamically sized xlogdir.
... Back in town...
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, with two people now asking to have the patch removed, and with no
> > comment from Thomas, I have removed the patch. This removes XLogDir
> > environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
>
> I thought we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, with two people now asking to have the patch removed, and with no
> comment from Thomas, I have removed the patch. This removes XLogDir
> environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I thought we intended to keep the -X swit
OK, with two people now asking to have the patch removed, and with no
comment from Thomas, I have removed the patch. This removes XLogDir
environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I have also removed the code that dynamically sized xlogdir.
I will post the patch to p
Curt Sampson wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
>
> > I would like to know how to move this item forward.
>
> Right now (i.e., in 7.2), the only two options we have for moving the
> log file to a different spindle are mounting it on pg_xlog and using a
> symlink. I doubt many peo
On Thu, 15 Aug 2002, Bruce Momjian wrote:
> I would like to know how to move this item forward.
Right now (i.e., in 7.2), the only two options we have for moving the
log file to a different spindle are mounting it on pg_xlog and using a
symlink. I doubt many people do the the former, and if they
I would like to know how to move this item forward.
---
Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > ... just for the record I'm with the "don't
> > use an environment variable" crowd here, too. It's way,
Curt Sampson <[EMAIL PROTECTED]> writes:
> ... just for the record I'm with the "don't
> use an environment variable" crowd here, too. It's way, way to easy
> to start up with the wrong setting in your environment.
What he said ...
> Oh, and yes, it does need to be changable after an initdb. Say
On Tue, 13 Aug 2002, scott.marlowe wrote:
> My non-coding vote goes with Tom Lane on this. initdb can set pg_xlog,
> and if you need to change it, use symlinks.
I've not been following this thread, and thus I suppose I missed
my opportunity to vote, but just for the record I'm with the "don't
u
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> If you move pg_xlog, you have to create a symlink in /data that points
> to the new location. Initdb would do that automatically, but if you
> move it after initdb, you would have to create the symlink yourself.
> With Thomas's current code, you would
Sounds good to me, but I have proven very unreliable in guessing others
opinions on this issue.
---
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > That does not change my opinion about the -X/PGXLOG switch though ---
> >
Tom Lane writes:
> That does not change my opinion about the -X/PGXLOG switch though ---
> having a backup safety check is not an excuse for having a fundamentally
> insecure set of startup options.
OK, so:
1. Leave -X option in initdb. Remove all other -X options.
2. Remove all uses of PGXLO
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > I think Tom is on to something here. I meant to ask but never got
> > > around to it. Why would anyone need to move the XLOG after you've
> > > inited the db?
> >
> > I just determined that disk I/O is terrible, so want t
On Mon, 12 Aug 2002, Thomas Lockhart wrote:
> > If you move pg_xlog, you have to create a symlink in /data that points
> > to the new location. Initdb would do that automatically, but if you
> > move it after initdb, you would have to create the symlink yourself.
> > With Thomas's current code,
Yea, the problem with postgresql.conf is that we don't have any
automatic modifications of that file, and I don't think we want to start
just to avoid symlinks.
I personally like symlinks too. I use them all the time. What is the
problem with them, exactly? Can someone show me some commands t
Oliver Elphick <[EMAIL PROTECTED]> writes:
>> Marc's idea of matching signature files would be a better
>> safety-checking mechanism than just making the data directory's xlog
>> link hard to get at.
> I would like to have Marc's safeguards as well.
Yeah, I was lukewarm about that at first, but
On Tue, 2002-08-13 at 15:00, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Could you not store the location of the xlog directory as an entry in
> > $PGDATA/global/pg_control?
>
> We could do that *only* if we were to produce an xlog-moving program
> immediately; otherwise we'v
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 14:24, Tom Lane wrote:
>> But there's more than one way to record the xlog location in the data
>> directory. If you don't like a symlink, what of putting it in
>> postgresql.conf as a postmaster-start-time-only config option?
>
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Could you not store the location of the xlog directory as an entry in
> $PGDATA/global/pg_control?
We could do that *only* if we were to produce an xlog-moving program
immediately; otherwise we've regressed in functionality compared to
prior releases.
On Tue, 2002-08-13 at 14:24, Tom Lane wrote:
...
> But there's more than one way to record the xlog location in the data
> directory. If you don't like a symlink, what of putting it in
> postgresql.conf as a postmaster-start-time-only config option?
Please don't!
The Debian package at least pro
Rod Taylor <[EMAIL PROTECTED]> writes:
> Symlinks seem to break all over the place (windows, novell, os/2),
The portability argument carries little weight with me. Recent versions
of Windows have symlinks. If anyone wants to run a PG installation on
a symlink-less platform, okay; they just won'
On Tue, 2002-08-13 at 14:15, Tom Lane wrote:
> 4. ln -s new xlog directory to $PGDATA/xlog
> With the patch it's almost the same, but you can instead of (4) substitute
>
> (4a) Change PGXLOG environment variable or -X argument in start script.
>
> That is *not* materially easier than an "ln" i
On Tue, 2002-08-13 at 08:15, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> I think Tom is on to something here. I meant to ask but never got
> >> around to it. Why would anyone need to move the XLOG after you've
> >> inited the db?
>
> > I just determined that disk I/O i
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> One thought at the back of my mind is why not have something like a
> 'PG_VERSION' for XLOG? Maybe something so simple as a text file in both
> the data and xlog directory that just contains a timestamp from the
> initdb? then, when you startup p
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> In the spirit of gratutious overstatement, I'll point out again:
> symlinks are evil.
Please justify that claim. They work really nicely in my experience...
and I don't know of any modern Unix system that doesn't rely on them
*heavily*.
Possibly mor
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> I think Tom is on to something here. I meant to ask but never got
>> around to it. Why would anyone need to move the XLOG after you've
>> inited the db?
> I just determined that disk I/O is terrible, so want to move the XLOG over
> to a differen
> But I really seriously feel that this feature is a bad idea as presently
> implemented. If necessary, I'll volunteer to change it the way I think
> it should be (viz, initdb can set up a symlink to a specified xlog
> directory; no change from previous behavior anywhere else).
Neither solution
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We will? It looks to me like Thomas lost the vote 2-to-1.
> Well, you didn't vote again in my follow up email,
I thought my vote was obvious already ...
> Can two guys override another guy if he is doing the work? I usually
> like
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We will? It looks to me like Thomas lost the vote 2-to-1.
>
> Unless there are mo
> If you move pg_xlog, you have to create a symlink in /data that points
> to the new location. Initdb would do that automatically, but if you
> move it after initdb, you would have to create the symlink yourself.
> With Thomas's current code, you would add/change PGXLOG instead to point
> to the
On Tue, 2002-08-13 at 00:16, Marc G. Fournier wrote:
>
> Myself, if I'm going to move something around, it will be after the server
> has been running for a while and I've added in more drive space in order
> to correct a problem i didn't anticipate (namely, disk I/O) ... at that
> point, I reall
Marc G. Fournier wrote:
> > I think Tom is on to something here. I meant to ask but never got
> > around to it. Why would anyone need to move the XLOG after you've
> > inited the db?
>
> I just determined that disk I/O is terrible, so want to move the XLOG over
> to a different file system that
Marc G. Fournier wrote:
> > Well, you didn't vote again in my follow up email, so I thought you
> > didn't care anymore, and Thomas didn't reply to my email either. I am
> > clearly concerned, as you are, but Thomas isn't, and no one else seems
> > to care.
>
> k, why are you concerned? see my
Marc G. Fournier wrote:
> On Tue, 13 Aug 2002, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recognized by initdb, postm
On 13 Aug 2002, Greg Copeland wrote:
> On Mon, 2002-08-12 at 23:09, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recogniz
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recognized by initdb, postmaster
On Mon, 2002-08-12 at 23:09, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
On Tue, 13 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We will? It looks to me
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, seeing as no one voted, and only Tom and I objected originally, we
> will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> recognized by initdb, postmaster, postgres, and pg_ctl.
We will? It looks to me like Thomas lost the vote 2
OK, seeing as no one voted, and only Tom and I objected originally, we
will keep the code as Thomas has applied it, namely that PGXLOG/-X is
recognized by initdb, postmaster, postgres, and pg_ctl. There is no
symlink from the /data directory to the WAL location.
Thomas, you mentioned implement
On Fri, Aug 09, 2002 at 06:54:44PM -0700, Thomas Lockhart wrote:
> I had thought to extend the capabilities to allow resource allocation
> for individual tables and indices, which has *long* been identified as a
> desired capability by folks who are managing large systems.
Without wishing to po
Thomas Lockhart wrote:
> > Thomas, would you remind me of the concusions because I thought everyone
> > involved felt that it should be an initdb-only option, but I still see
> > it in CVS.
>
> ?? "Concussions" as in brain bruises? ;)
Uh, conclusions. Sorry. New keyboard desk in new house. :-)
> Thomas, would you remind me of the concusions because I thought everyone
> involved felt that it should be an initdb-only option, but I still see
> it in CVS.
?? "Concussions" as in brain bruises? ;)
I'm not sure I understand the question. I assume that we are talking
about the WAL log locatio
Thomas, would you remind me of the concusions because I thought everyone
involved felt that it should be an initdb-only option, but I still see
it in CVS.
---
Thomas Lockhart wrote:
> > Thomas, have you commented on the obj
Florian Weimer <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
>> Thomas can correct me if I'm mistaken, but I believe these changes apply
>> to the new integer datetime code
>
> No, it's possible to crash the backend in 7.2, too.
And 7.2.1, of course.
Let me ask again:
[EMAIL PROTECTED] (Thomas Lockhart) writes:
> Log message:
> Add guard code to protect from buffer overruns on long date/time input
> strings. Should go back in and look at doing this a bit more elegantly
> and (hopefully) cheaper. Probably not too bad anyway, but it seems a
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Thomas Lockhart wrote:
>> Implement WAL log location control using "-X" or PGXLOG.
> Woh, I didn't think we had agreement on this. This populates the 'X'
> all over the system (postgres, postmaster, initdb, pg_ctl), while the
> simple solution would b
Thomas Lockhart wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 02/08/04 02:26:38
>
> Modified files:
> src/backend/tcop: postgres.c
> src/backend/bootstrap: bootstrap.c
> src/backend/postmaster: postmaster.c
> src/bin/in
70 matches
Mail list logo
