Since this is the first release supporting Windows natively, and
Windows people tend to not have any development environment by default,
should there be a windows binary version of some sort into the beta
directory, or is that something that will come along later with
setup.exe type packaging or so
Tom Lane writes:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > The plpgsql regression test for Win32 fails; appears to not obey the
> > statement timeout. Might be a known problem.
>
> [ rolls eyes... ] That's been like that for some time. Hasn't anyone
> been testing on Windows?
I've cert
According to the docs and my 8.0beta build, there is no way to move a schema
to a new tablespace? We have this functionality for tables, is there a
reason not to have it for schemas or was it just oversight ?
--
Robert Treat
Build A Better Lamp :: Linux Apache {middleware} PostgreSQL
Didn't get any Oracle hits in a quick google, but I did find out that
MySQL spells it USING:
You guys can go to otn.oracle.com and register for free to get access to
all the documentation they've ever written. I've got an account there.
I do get the odd oracle magazine sent to me though...
Thi
Robert Treat <[EMAIL PROTECTED]> writes:
> Well, as yall have pointed out, the feature is not sql spec (for some
> reason I thought it had been put in) so since the update syntax seems
> quite similar to oracles, perhaps they can provide a pointer on delete
> syntax as well? I can't seem to find m
On Sunday 08 August 2004 23:16, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Hmmm. What would that look like?
> >
> > DELETE FROM table
> > {FROM | WITH | USING | ?? }
> > WHERE ...
> >
> > I think we don't have this mainly because, what word do we use?
>
> Yup, eggzackle. The im
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Not a whole lot we can do about that, unless you want to invent a new
>> category of "integer variables we display in octal". Doesn't really
>> seem worth it.
> I suppose so. I'll want to document the discrepancy though.
[ dept. of second thoughts ]
Tom,
> > 1) TimeZone and DateStyle are mixed case in SHOW ALL. Is there a reason
> > for this? Appears to be the same in 7.4.
>
> That's been the traditional spelling of those variable names since
> before I got here. Do we need to change it?
Well, if we've had it for 5 years, then I guess an
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Maybe you guys should keep a list of all places that need updating and
> all jobs that need to be done before a release, so we don't forget
> anything :)
src/tools/RELEASE_CHANGES ... but it didn't occur to me to consult that
while relabeling
Drat. I grepped for '7.5' and '705', but not for '7, 5' :-(
I am not sure how that file is used but it might require us to repackage
beta1.
Nah, not worth the trouble. Good thing you noticed it before final though.
Maybe you guys should keep a list of all places that need updating and
all job
Dumped by what? It's a PGC_POSTMASTER variable, there ain't gonna be
nobody putting it in ALTER DATABASE or ALTER USER.
Oh yeah, sorry wasn't thinking. Same reason I don't bother handling
preload_libraries and friends in pg_dumpall...
The problem is there's no way to know if they're list type g
According to the docs, even the 8.0 developer docs
(http://developer.postgresql.org/docs/postgres/install-win32.html),
"Tip: If you are using Windows 98 or newer you can build and use all of
PostgreSQL "the Unix way" if you install the Cygwin toolkit first. In
that case see Chapter 14."
I don't
Claudio Natoli <[EMAIL PROTECTED]> writes:
> The plpgsql regression test for Win32 fails; appears to not obey the
> statement timeout. Might be a known problem.
[ rolls eyes... ] That's been like that for some time. Hasn't anyone
been testing on Windows?
regards, tom lan
Josh Berkus <[EMAIL PROTECTED]> writes:
> 1) TimeZone and DateStyle are mixed case in SHOW ALL. Is there a reason for
> this? Appears to be the same in 7.4.
That's been the traditional spelling of those variable names since
before I got here. Do we need to change it?
> 2) for unix_socket_per
Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Hmmm. What would that look like?
>
> > DELETE FROM table
> > {FROM | WITH | USING | ?? }
> > WHERE ...
>
> > I think we don't have this mainly because, what word do we use?
>
> Yup, eggzackle. The implementation would really be triv
'k, building ... and I'm goin to bed now :)
On Sun, 8 Aug 2004, Bruce Momjian wrote:
Claudio Natoli wrote:
Just a quick heads-up.
The plpgsql regression test for Win32 fails; appears to not obey the
statement timeout. Might be a known problem.
Open items has:
o query cancel in psql (?)
Not s
Josh Berkus <[EMAIL PROTECTED]> writes:
> Hmmm. What would that look like?
> DELETE FROM table
> {FROM | WITH | USING | ?? }
> WHERE ...
> I think we don't have this mainly because, what word do we use?
Yup, eggzackle. The implementation would really be trivial, but
previous discussion hung up
Claudio Natoli wrote:
> Just a quick heads-up.
>
> The plpgsql regression test for Win32 fails; appears to not obey the
> statement timeout. Might be a known problem.
Open items has:
o query cancel in psql (?)
Not sure if that is the same one or not.
> Lines 395-6 of exec.c need to hav
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see in configure.in:
> *** If you are going to modify the grammar files or build from CVS, the
> installed
> *** version of Bison is too old. Bison version 1.875 or later is required.])
> Looks documented to me.
Also, installation.sgml s
Josh Berkus wrote:
Aha. Yeah, blew past me too fast to read. Hmmm ... does that mean that this
error won't happen in the release version?
You shoouldn't need bison at all with a release tarball -- the
preprocessed grammar file is distributed with it.
Joe
---(end of bro
Just a quick heads-up.
The plpgsql regression test for Win32 fails; appears to not obey the
statement timeout. Might be a known problem.
Lines 395-6 of exec.c need to have the operator changed from equality to
assignment (busted fix for pg_dumpall on win32).
Cheers,
Claudio
-Original Messa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
Drat. I grepped for '7.5' and '705', but not for '7, 5' :-(
> I am not sure how that file is used but it might require us to repackage
> beta1.
Nah, not worth the trouble. Good
Folks,
Here's some things I'd like to check on before submitting a bug patch on the
.conf stuff:
1) TimeZone and DateStyle are mixed case in SHOW ALL. Is there a reason for
this? Appears to be the same in 7.4.
2) for unix_socket_permissions the value in the .conf file is octal (0777),
whi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> If you've just made this a GUC_LIST_INPUT variable, then you will need
> to update the nasty bit of hackiness in pg_dumpall to allow it to be
> dumped without error :(
Dumped by what? It's a PGC_POSTMASTER variable, there ain't gonna be
nobo
Robert, Tom,
> I think you're wrong on both counts --- we do support UPDATE FROM, and
> it's not in the spec.
I can verify that it's not in SQL92. Unless you've got a place they added a
different syntax in 99 or 2003, Robert?
> What we don't have is an equivalent syntax for DELETE, and you're
Josh Berkus wrote:
> Bruce,
>
> > *** If you are going to modify the grammar files or build from CVS, the
> > installed *** version of Bison is too old. Bison version 1.875 or later is
> > required.]) fi
> > fi
>
> Aha. Yeah, blew past me too fast to read. Hmmm ... does that mean that
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> listen_addresses is currently defined as a space-separated list of IP
> >> addresses or names. It would be more consistent with the other
> >> list-type GUC parameters to make it a comma-separated list. Any
> >>
Bruce,
> *** If you are going to modify the grammar files or build from CVS, the
> installed *** version of Bison is too old. Bison version 1.875 or later is
> required.]) fi
> fi
Aha. Yeah, blew past me too fast to read. Hmmm ... does that mean that this
error won't happen in the
Robert Treat <[EMAIL PROTECTED]> writes:
> AFAIR this is still the only way to do updates on joined tables, a feature
> that IIRC is in the sql spec (and certianly in other rdbms') that we do not
> support.
I think you're wrong on both counts --- we do support UPDATE FROM, and
it's not in the sp
Josh Berkus <[EMAIL PROTECTED]> writes:
>> I don't see anything in the current docs warning that such a change is
>> afoot. We have insisted on one release cycle's warning for smaller
>> things than this ...
> Ok. Can we put a warning in, then? Where should we put it?
In the description of add
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> listen_addresses is currently defined as a space-separated list of IP
>> addresses or names. It would be more consistent with the other
>> list-type GUC parameters to make it a comma-separated list. Any
>> objections?
> Agreed. Just
re-tag'd and building new bundle now to include the change *just in case*
On Sun, 8 Aug 2004, Bruce Momjian wrote:
I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
I am not sure how that file is used but it might require us to repackage
beta1.
Patch attached and applied.
--
On Sunday 08 August 2004 21:44, Josh Berkus wrote:
> Tom,
>
> > I don't see anything in the current docs warning that such a change is
> > afoot. We have insisted on one release cycle's warning for smaller
> > things than this ...
>
> Ok. Can we put a warning in, then? Where should we put it?
A
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 8 Aug 2004, Tom Lane wrote:
>> Yeah, sure wish we could generate those man pages automatically :-(
> Is there a reason why we can't?
Peter tried, but I don't know what the problems were.
regards, tom lane
-
On Mon, Aug 09, 2004 at 11:56:17AM +1000, fastpgs wrote:
> On Sun, 8 Aug 2004 08:19, Alvaro Herrera wrote:
>
> > If the change is global, what should happen on other sessions that have
> > a deferred event from that trigger concurrently with the one that
> > modifies it? Should the answer be diff
Hey Tom,
If you've just made this a GUC_LIST_INPUT variable, then you will need
to update the nasty bit of hackiness in pg_dumpall to allow it to be
dumped without error :(
It's line 782 of pg_dumpall.c. I wonder if you will like that code once
you look at it :P
The problem is there's no way
On Sunday 08 August 2004 05:05, Erwin Moller wrote:
> >> But how can I get a listing of all used triggers on a certain table?
> >
> > \d
> >
> Thanks for your response, but this is what I get:
>
> column, Type, and Modifiers
> +
> Indexes and foreign key contraints.
> No triggers.
>
> The triggers
Josh Berkus wrote:
> Folks,
>
> Update on this: Just tried it with:
> SuSE 9.1, GCC 3.3.3, Bison 1.875
> and don't get the error.
>
> So it looks like the requirement for Bison 1.85+ is now a "hard" requirement?
> We'll need to document this, since SuSE 9.0 is less than a year old, and I'm
>
I just found that libpq.rc wasn't updated to mark 8.0 and still had 7.5.
I am not sure how that file is used but it might require us to repackage
beta1.
Patch attached and applied.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359
listen_addresses is currently defined as a space-separated list of IP
addresses or names. It would be more consistent with the other
list-type GUC parameters to make it a comma-separated list. Any
objections?
Nope.
---(end of broadcast)---
TIP 3: if
Another interesting think I noticed in pg_dump is dumping of LOBs. It
seems to declare a cursor that fetches the blobs and then issues a fetch
1000 to get the first 1000 lobs. It never seems to execute any further
fetches.
Huh? That's inside a do-loop.
Errr, yeah. Don't know what made me not n
On Sun, 8 Aug 2004 08:19, Alvaro Herrera wrote:
> If the change is global, what should happen on other sessions that have
> a deferred event from that trigger concurrently with the one that
> modifies it? Should the answer be different depending on the isolation
> mode of the transaction?
This w
Folks,
Got the following bomb trying to build from current CVS (August 8th):
make[4]: Leaving directory `/usr/src/postgresql-8.0b/src/interfaces/ecpg/
compatlib'
make -C preproc all
make[4]: Entering directory `/usr/src/postgresql-8.0b/src/interfaces/ecpg/
preproc'
make -C ../../../../src/port al
Thanks for your response, but this is what I get:
column, Type, and Modifiers
+
Indexes and foreign key contraints.
No triggers.
It lists triggers. Trust me, I wrote it.
The triggers are responsible for checking FK-contraints in other tables,
that use the table I want to list as refering key.
OK
Tom,
> I don't see anything in the current docs warning that such a change is
> afoot. We have insisted on one release cycle's warning for smaller
> things than this ...
Ok. Can we put a warning in, then? Where should we put it?
--
Josh Berkus
Aglio Database Solutions
San Francisco
Tom Lane wrote:
> listen_addresses is currently defined as a space-separated list of IP
> addresses or names. It would be more consistent with the other
> list-type GUC parameters to make it a comma-separated list. Any
> objections?
Agreed. Just mark it as an incompatibility in the release note
Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
> > 1. You use a do {...} while(0) construct to wrap the whole thing. This
> > actually makes it impossible to write code that does a try/catch within
> > a loop that contains code surrounding it since a continue or break will
> > the
On Sun, 8 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Will do a short announce tomorrow, but if anyone wants to look it over,
make sure that I didn't miss anything?
Tarball looks good from here.
the only thing in the build that needs to be fixed is:
cp /var/spool/ftp/pu
Josh Berkus <[EMAIL PROTECTED]> writes:
> Going over the .conf, I just noticed that add_missing_from is still set to
> True in postgresql.conf.sample.By my memory of our discussion, this
> option was introduced in 7.4 and was to be set to False by default in 8.0.
> Can we switch it to Fals
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Will do a short announce tomorrow, but if anyone wants to look it over,
> make sure that I didn't miss anything?
Tarball looks good from here.
> the only thing in the build that needs to be fixed is:
> cp /var/spool/ftp/pub/dev/doc/man-7.4.tar.gz
Will do a short announce tomorrow, but if anyone wants to look it over,
make sure that I didn't miss anything? the files are available at
ftp://ftp.postgresql.org/pub/source/v8.0.0beta1 ... both gz and bz2 files
are available ...
the only thing in the build that needs to be fixed is:
cp /var/s
Folks,
Update on this: Just tried it with:
SuSE 9.1, GCC 3.3.3, Bison 1.875
and don't get the error.
So it looks like the requirement for Bison 1.85+ is now a "hard" requirement?
We'll need to document this, since SuSE 9.0 is less than a year old, and I'm
sure some other distros are still usi
Tom, Et Al:
Going over the .conf, I just noticed that add_missing_from is still set to
True in postgresql.conf.sample.By my memory of our discussion, this
option was introduced in 7.4 and was to be set to False by default in 8.0.
Can we switch it to False?
BTW, the reason for setting it
[EMAIL PROTECTED] (Ned Lilly) wrote in message news:<[EMAIL PROTECTED]>...
> Jonathan,
>
> This is exactly how my company has built a very robust ERP application. See
> www.openmfg.com.
>
Hi Mr. Lilly:
I not sure who to address this question to at your company.
I'm a valued added reseller wh
Tom Lane wrote:
I'm not sure that we had such an agreement, but in any case we've got
to understand how to distinguish empty-string from NULL.
I realized that in my followup post regarding nested arrays. In any
case, since will not 8.0 support either NULL elements nor nested arrays,
can we agree
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
select '{{},{}}'::text[];
ERROR: malformed array literal: "{{},{}}"
Hm. This seems like it would be a legitimate representation of a 2x0
array. Why would you allow '{}' and reject this?
I just reread your comment and thought about it more.
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [ random griping ]
> Well, '{}' is a special case representing an empty array.
Hmm ... good point ... it is not obvious whether that is an empty array
(0x0) or a 1x1 array containing a single zero-length string. I guess
if we want to ma
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
select '{{},{}}'::text[];
ERROR: malformed array literal: "{{},{}}"
Hm. This seems like it would be a legitimate representation of a 2x0
array. Why would you allow '{}' and reject this?
Well, '{}' is a special case representing an empty arr
Christopher Kings-Lynne wrote:
>> futhermore:
>> \dt lists tables
>> \ds lists sequences
>> \d tablename lists that table.
>>
>> etc. etc.
>>
>> But how can I get a listing of all used triggers on a certain table?
>
> \d
>
> Chris
>
Hi Chris,
Thanks for your response, but this is what I ge
Andreas Pflug <[EMAIL PROTECTED]> 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 a
"Scott Marlowe" <[EMAIL PROTECTED]> 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, to
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> 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
On Sun, 2004-08-08 at 09:58, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 en
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 ce
Tom Lane wrote:
Perhaps, but what about everyone's editors' autoindent logic?
I'd have preferred not to have the "();" decoration too, but it is
really not worth the pain.
I guess you have a point. Ok, I'll live with it.
Regards,
Thomas Hallgren
---(end of broadcast)
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 origi
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This isn't really open for debate, because if we don't put that there,
>> pg_indent will go nuts.
>>
> I'm not familiar with pg_indent but my guess is that the first and
> foremost motivation for its existence is code readability an
Tom Lane wrote:
A continue or break exiting the construct would do the wrong thing
anyway, so I don't see that removing the do{} is very helpful. The
point of having it is to make sure that a try/end try block is
syntactically like a statement, rather than like a { ... } construct.
Yes, a continue
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,
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Maybe we could avoid removing it until the next checkpoint? Or is that
> > not enough. Maybe it could stay there forever :/
>
> Part of the problem here is that this code has to serve several
> purposes. We have differen
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> 1. You use a do {...} while(0) construct to wrap the whole thing. This
> actually makes it impossible to write code that does a try/catch within
> a loop that contains code surrounding it since a continue or break will
> then end up in the wrong plac
Will be fixed later on this evening ...
On Sun, 8 Aug 2004, Serguei A. Mokhov wrote:
On the developer's page:
http://developer.postgresql.org/
CVSWeb link points to:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server
which is incorrect. The same for interfaces...
--
Serguei A.
Mike G <[EMAIL PROTECTED]> writes:
> Hello,
>
> I will bring it up with the postgresql hackers.
>
> PS - Sorry for the new posting. I read these via digest.
Neither the Cygwin nor the (beta) Windows-native version of Postgresql
is supported in any way on Windows 9x/ME AFIAK. Anyone trying to ru
listen_addresses is currently defined as a space-separated list of IP
addresses or names. It would be more consistent with the other
list-type GUC parameters to make it a comma-separated list. Any
objections?
regards, tom lane
---(end of broadcast
Hello,
I will bring it up with the postgresql hackers.
PS - Sorry for the new posting. I read these via digest.
Mike
* From: Jason Tishler
* To: cygwin at cygwin dot com
* Date: Sun, 8 Aug 2004 11:07:56 -0400
* Subject: Re: Initdb FATAL error shmat - Win98 Cygwin 1.5.1
On the developer's page:
http://developer.postgresql.org/
CVSWeb link points to:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server
which is incorrect. The same for interfaces...
--
Serguei A. Mokhov| /~\The ASCII
Computer Science Department | \ / Ribbo
As I was integrating the new PG_TRY/PG_CATCH/PG_END_TRY macros I
discovered a couple of minor issues.
1. You use a do {...} while(0) construct to wrap the whole thing. This
actually makes it impossible to write code that does a try/catch within
a loop that contains code surrounding it since a c
On Sun, Aug 08, 2004 at 01:18:02AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > Maybe a better SCM could help with this, but I doubt it.
>
> I haven't seen any particular reason why we should adopt another SCM.
> Perhaps BitKeeper or SubVersion would be better for our
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> 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
> > announ
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.
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Andreas Pflug wrote:
>> Tom Lane wrote:
>>> Do we have a TODO for allowing users to
>>> force switching to a new WAL file segment?
>>
>> Together with PITR, this might make sense?
> I thought about this, and it would perhaps help, but it would bloat the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
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
Bruce Momjian <[EMAIL PROTECTED]> 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.
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 alwa
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >Do we have a TODO for allowing users to
> > force switching to a new WAL file segment?
>
> Together with PITR, this might make sense?
I thought about this, and it would perhaps help, but it would bloat the
archive location if used repeatedly, perhaps e
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
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?
> >
> >
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
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Another interesting think I noticed in pg_dump is dumping of LOBs. It
> seems to declare a cursor that fetches the blobs and then issues a fetch
> 1000 to get the first 1000 lobs. It never seems to execute any further
> fetches.
Huh? That's
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 y
'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 :)
Marc G. Fournier
On Sun, Aug 08, 2004 at 12:50:43PM +0800, Christopher Kings-Lynne wrote:
> Also, given this and your previous operator commutator problem, I
> strongly suspect that someone has taken an axe to the system catalogs on
> your installation and they are very screwy.
System catalogs screws are possib
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > OK, I can do this, but I don't think I'll have time for the first beta.
>
> No problem.
Another interesting think I noticed in pg_dump is dumping of LOBs. It
seems to declare a cursor that fetches the blobs and then issues a fetch
1000 to
Tom Lane wrote:
Do we have a TODO for allowing users to
force switching to a new WAL file segment?
Together with PITR, this might make sense?
Regards,
Andreas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriat
Tom Lane wrote:
Give me a use case that requires that, and is sufficiently interesting
to justify even a marginal decrease in the reliability of the log
process.
Frankly, I do not believe that database users should have anything to do
with the log rotation process.
The (super)user will sometimes pu
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom, you didn't like Andreas' idea of allowing the user to rotate the
log files on demand.
Give me a use case that requires that, and is sufficiently interesting
to justify even a marginal decrease in the reliability of the log
process.
- D
OK, I fixed the Win32 pgport build problem with Claudio's help.
I also fixed pg_dumpall on Win32 at the same time.
I might be out most of the day tomorrow.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life
1 - 100 of 101 matches
Mail list logo
