Simon Riggs wrote:
Fix minor bug in pg_standby, noted by Ferenc Felhoffer
Applied, thanks.
I couldn't find a bug report from Ferenc in the archives. Did he contact
you personally?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (p
Fix minor bug in pg_standby, noted by Ferenc Felhoffer
Request immediate apply to CVS HEAD and 8.3
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: contrib/pg_standby/pg_standby.c
===
R
Gregory Stark <[EMAIL PROTECTED]> writes:
> There's a bug in datetime.c when it handles errors converting text into
> various date formats. It tries to avoid palloc'ing a cstring copy of the in=
> put
> by storing it in a stack variable instead but that means it can't handle
> inputs over MAXDATELE
There's a bug in datetime.c when it handles errors converting text into
various date formats. It tries to avoid palloc'ing a cstring copy of the input
by storing it in a stack variable instead but that means it can't handle
inputs over MAXDATELEN. So it throws an error but passes the varlena strin
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Code comments now discuss relative paths also.
> Patch containing just the minor cleanup of docs and code comments.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TI
On Tue, Nov 07, 2006 at 02:31:57PM +, Peter Harris wrote:
> Attached is a patch to make ECPGconnect call ECPGclear_auto_mem,
> as ECPGdo already does.
Thanks. I applied the patch to CVS HEAD, 8.1 and 8.0.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (D
On Tue, Nov 07, 2006 at 07:11:35PM -0600, Bruno Wolff III wrote:
> On Sun, Nov 05, 2006 at 11:49:36 -0500,
> Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > As already discussed upthread, anyone who wants the path can get it from
> > `pwd` or local equivalent --- and that mechanism is robust (as lon
On Sun, Nov 05, 2006 at 11:49:36 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> As already discussed upthread, anyone who wants the path can get it from
> `pwd` or local equivalent --- and that mechanism is robust (as long as
> the directory move doesn't happen while any particular instance of t
Hi
Attached is a patch to make ECPGconnect call ECPGclear_auto_mem,
as ECPGdo already does.
Peter Harris
Concept Systems Ltd
This email and any files transmitted with it are confidential and are intended
solely for the use of the individual or entity to whom they are addressed. If
you are not
On Sun, 2006-11-05 at 15:02 +, Simon Riggs wrote:
> Code comments now discuss relative paths also.
Patch containing just the minor cleanup of docs and code comments.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/backup.sgml
=
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 broadcast
"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
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
> >>
"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 cont
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 i
"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
>>> with Bernd's suggestion to change the doc
> > > 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 with Bernd's suggestion to change the docs
> to match
> > > the code, but does anyone have a contrary opinion?
>
> > In Unix you c
Simon Riggs wrote:
> On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
>> 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
On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
> 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
> > with Bernd's sugges
Tom Lane wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
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
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary opi
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
> with Bernd's suggestion to change the docs to match the code, but does
> anyone have a contr
Bernd Helmle <[EMAIL PROTECTED]> writes:
> Our WAL backup documentation says in some parts of it:
> ..."%p is replaced by the absolute path of the file to archive..." [1]
> I think this is (at least for 8.1 and upcoming 8.2 releases) wrong, since
> the archiver replaces this with pg_xlog/ only,
Our WAL backup documentation says in some parts of it:
..."%p is replaced by the absolute path of the file to archive..." [1]
I think this is (at least for 8.1 and upcoming 8.2 releases) wrong, since
the archiver
replaces this with pg_xlog/ only, so that the archive command
is invoked with the
[EMAIL PROTECTED] (Tom Lane) writes:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Tom Lane) writes:
>>> No you don't --- see recent warthog complaint. We have to filter LIBS
>>> down to just the minimum.
>
>> I'm at a loss, then.
>
>> - If LIBS is being filtered to the minimum,
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Tom Lane) writes:
>> No you don't --- see recent warthog complaint. We have to filter LIBS
>> down to just the minimum.
> I'm at a loss, then.
> - If LIBS is being filtered to the minimum, then shouldn't it be
> appropriate to add i
[EMAIL PROTECTED] (Tom Lane) writes:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> I still need the following, on AIX:
>
>> -SHLIB_LINK = $(libpq)
>> +SHLIB_LINK = $(libpq) $(LIBS)
>
> No you don't --- see recent warthog complaint. We have to filter LIBS
> down to just the minimum.
I'm at a loss,
Chris Browne <[EMAIL PROTECTED]> writes:
> I still need the following, on AIX:
> -SHLIB_LINK = $(libpq)
> +SHLIB_LINK = $(libpq) $(LIBS)
No you don't --- see recent warthog complaint. We have to filter LIBS
down to just the minimum.
regards, tom lane
---
The change Tom made to contrib/sshinfo/Makefile to support Darwin,
adding in $(LIBS), fixed my problem with that contrib module on AIX.
I still need the following, on AIX:
===
RCS file: /projects/cvsroot/pgsql/contrib/dblink/Makefile
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Am Mittwoch, 30. August 2006 22:57 schrieb Chris Browne:
>> I also seem to recall, in past discussions about "library matters,"
>> that AIX is more sticky about requiring that libraries be named
>> expressly.
>
> ecpglib has
>
> SHLIB_LINK = -L../pgtyp
Stephen Frost <[EMAIL PROTECTED]> writes:
> Perhaps I'm missing something obvious (and if so, I'm sorry) but
> couldn't we just build up the character array in PQsetdbLogin to be
> passed in to connectOptions1?
That's a possibility too, though by the time you've finished building
that string (with
* Tom Lane ([EMAIL PROTECTED]) wrote:
> This is probably not a good idea --- changing the API behavior in
> pursuit of saving a few cycles is just going to get people mad at us.
Fair enough.
> I think we'd have to refactor the code so that PQsetdbLogin gets a
> PQconninfoOption array, overrides v
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Right offhand I like the idea of pushing it into connectOptions2 --- can
>> you experiment with that? Seems like there is no reason to call
>> Kerberos if the user supplies the name to connect as.
> Patch attache
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Right offhand I like the idea of pushing it into connectOptions2 --- can
> you experiment with that? Seems like there is no reason to call
> Kerberos if the user supplies the name to connect as.
Patch attached. After looking through the code around this I
Good patch. You are right that the original code did not consider that
AUTOCOMMIT would change the transaction state seen by the
ON_ERROR_ROLLBACK check.
Fixed in CVS. ON_ERROR_ROLLBACK was not in 8.0.X so no need to backpatch.
---
There is a bug in psql for the new ON_ERROR_ROLLBACK feature. In AUTOCOMMIT
off mode it does not work correctly for the first statement.
This is how it works usually:
postgres=# \set AUTOCOMMIT off
postgres=# \set ON_ERROR_ROLLBACK interactive
postgres=# SELE
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 29 August 2005 20:15
> To: Dave Page
> Cc: PostgreSQL-patches
> Subject: Re: [PATCHES] Bug in file access functions
>
> "Dave Page" writes:
> > 1) Stop them rejecting pa
"Dave Page" writes:
> 1) Stop them rejecting paths that use Windows backslash directory
> seperators.
Hmm, seems like it should be using is_absolute_path(). Will fix.
> 2) Allow absolute paths to files into the data dir, as we already do for
> the log dir.
Seems reasonable, given that we expos
The attached patch fixes a couple of minor issues in the file access
functions added for 8.1. These seem to have been introduced in recent
changes following the original patch.
1) Stop them rejecting paths that use Windows backslash directory
seperators.
2) Allow absolute paths to files into the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Looks like a bug to me, at least -- opclasses are registered using the
> opclass Oid, not the access method Oid, right?
Yup, definitely wrong. Patch applied --- thanks!
[ digs around ... ] The other calls of changeDependencyOnOwner seem
OK; I guess t
Looks like a bug to me, at least -- opclasses are registered using the
opclass Oid, not the access method Oid, right?
--
Alvaro Herrera ()
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)
Index: opclasscmds.c
=
Bruce Momjian writes:
> In my first attempt, I counted the number of ".." groups, then went up
> to remove each "..", and them remove a regular directory for each "..".
> And then you have this case:
> /usr/local/../bin/../..
> Here you hit the first ".." as you are going up. It just seem
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, here is a version that errors out that I just applied and reversed
> > out when I saw your email. Feel free to use it or discard it.
>
> Sorry about that --- should have tried to mail you a bit sooner.
>
> BTW, what's with the postmaster.c change?
Bruce Momjian writes:
> OK, here is a version that errors out that I just applied and reversed
> out when I saw your email. Feel free to use it or discard it.
Sorry about that --- should have tried to mail you a bit sooner.
BTW, what's with the postmaster.c change? Seems mistaken.
I wrote:
> Uh, that hardly meets the API contract that I mentioned. I think
> we really have to throw an error if the path tries to ".." above
> the starting point.
After rereading all the callers of canonicalize_path, I've concluded
that none of them actually depend on not having a terminating "
Tom Lane wrote:
> I wrote:
> > Uh, that hardly meets the API contract that I mentioned. I think
> > we really have to throw an error if the path tries to ".." above
> > the starting point.
>
> After rereading all the callers of canonicalize_path, I've concluded
> that none of them actually depend
Bruce Momjian writes:
> Tom Lane wrote:
>> Uh, that hardly meets the API contract that I mentioned. I think
>> we really have to throw an error if the path tries to ".." above
>> the starting point.
> OK, so how do you want to error out? exit()? There are no ereport
> calls in that file.
Yeah
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> ... it's part of the API contract of canonicalize_path() that it
> >> will not return something with trailing "." or "..".
>
> > OK, new patch which I think handles all cases.
>
> > + if (pending_strips > 0)
> > + {
> > +
Bruce Momjian writes:
> Tom Lane wrote:
>> ... it's part of the API contract of canonicalize_path() that it
>> will not return something with trailing "." or "..".
> OK, new patch which I think handles all cases.
> + if (pending_strips > 0)
> + {
> + for (; pending_strips > 0
Tom Lane wrote:
> Bruce Momjian writes:
> > I figured it would be best to leave it alone if we can't process it, but
> > if you think it is more imporant to trim in cases like ../.., go ahead.
>
> My recollection of this patch:
>
> 2004-08-09 16:20 tgl
>
> * src/: port/exec.c, port/path.
Bruce Momjian writes:
> I figured it would be best to leave it alone if we can't process it, but
> if you think it is more imporant to trim in cases like ../.., go ahead.
My recollection of this patch:
2004-08-09 16:20 tgl
* src/: port/exec.c, port/path.c, bin/initdb/initdb.c:
m: "Bruce Momjian"
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "William ZHANG" <[EMAIL PROTECTED]>;
Sent: Friday, August 12, 2005 11:15 AM
Subject: Re: [PATCHES] Bug in canonicalize_path()
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > But
Tom Lane wrote:
> Bruce Momjian writes:
> > But what about "usr/local/../../.."?
>
> What about it? The case of /usr/local/../../.. is handled correctly,
> and the case where it's an underspecified relative path doesn't seem
> that interesting to me --- certainly that is not so important that we
Bruce Momjian writes:
> But what about "usr/local/../../.."?
What about it? The case of /usr/local/../../.. is handled correctly,
and the case where it's an underspecified relative path doesn't seem
that interesting to me --- certainly that is not so important that we
should get the wrong answer
Tom Lane wrote:
> Bruce Momjian writes:
> > And then you have this case:
>
> > /usr/local/../bin/../..
>
> AFAICS, the patch I just proposed handles this.
>
> If I recall the code properly, we do not have to make canonicalize_path
> remove embedded "." or ".." --- that is, we do not have to
Bruce Momjian writes:
> And then you have this case:
> /usr/local/../bin/../..
AFAICS, the patch I just proposed handles this.
If I recall the code properly, we do not have to make canonicalize_path
remove embedded "." or ".." --- that is, we do not have to simplify
/usr/local/..
I wrote:
> I didn't much like the patch as-is; we should think a little harder
> about fixing the logic properly.
Like, say, this. (Very poorly tested but I think it's right.)
regards, tom lane
*** src/port/path.c.origThu Aug 11 21:39:22 2005
--- src/port/path.c
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Bruce Momjian"
Cc: "William ZHANG" <[EMAIL PROTECTED]>;
Sent: Friday, August 12, 2005 10:31 AM
Subject: Re: [PATCHES] Bug in canonicalize_path()
> Bruce Momjian writes:
>
Tom Lane wrote:
> Bruce Momjian writes:
> > Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
> > it. Any objections?
>
> I think he's suggesting that we depend on GetFullPathName(), which seems
> a bit pointless considering we have to write the code anyway for other
> platf
Bruce Momjian writes:
> Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
> it. Any objections?
I think he's suggesting that we depend on GetFullPathName(), which seems
a bit pointless considering we have to write the code anyway for other
platforms.
I didn't much like the
Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
it. Any objections?
---
William ZHANG wrote:
>
> What if we let the trailing "." or ".." as it is?
>
> On Windows, GetFullPathName() can canonicalize
What if we let the trailing "." or ".." as it is?
On Windows, GetFullPathName() can canonicalize a given path.
$ uname -a
MINGW32_NT-5.0 DEV 1.0.10(0.46/3/2) 2003-10-11 10:14 i686 unknown
$ cat path.c
#include
int
main(void)
{
CHAR Buf[1024];
GetFullPathName("C:\\Temp", 1024
AgentM <[EMAIL PROTECTED]> writes:
> Attached is a patch which corrects the behavior. I verified that the
> patch does not interfere with normal operation (using psql) but
> unfortunately the code path is virtually impossible to test without a
> really slow connection to a postgresql server [
I found that in port/path.c::canonicalize_path, that if the path was
supplied as "/usr/local/bin/../.." we would return /usr/local/bin. The
problem is then when we saw a trailing ".." we stripped it off and the
previous directory, but we never checked if the previous directory was
itself "..".
Pa
Tom Lane wrote:
> AgentM <[EMAIL PROTECTED]> writes:
> > Attached is a patch which corrects the behavior. I verified that the
> > patch does not interfere with normal operation (using psql) but
> > unfortunately the code path is virtually impossible to test without a
> > really slow connectio
AgentM said:
> Attached is a patch which corrects the behavior. I verified that the
> patch does not interfere with normal operation (using psql) but
> unfortunately the code path is virtually impossible to test without a
> really slow connection to a postgresql server [which I thankfully
> don't h
AgentM <[EMAIL PROTECTED]> writes:
> Attached is a patch which corrects the behavior. I verified that the
> patch does not interfere with normal operation (using psql) but
> unfortunately the code path is virtually impossible to test without a
> really slow connection to a postgresql server [
Attached is a patch which corrects the behavior. I verified that the
patch does not interfere with normal operation (using psql) but
unfortunately the code path is virtually impossible to test without a
really slow connection to a postgresql server [which I thankfully
don't have]. To test t
Neil Conway said:
>
> BTW, in future it would be good to specify the consequences of the bug
> (i.e. beyond "it is horrible"), so committers who don't use pl/perl can
> judge the urgency of the bug.
Yes, sorry. In fact, fortuitously the effects are not disastrous in most
circumstances. Once we t
Andrew Dunstan wrote:
While building some better plperl tests today I discovered a horrid bug
(which I regret to say is my fault), present in both 8.0 and HEAD
branches
BTW, in future it would be good to specify the consequences of the bug
(i.e. beyond "it is horrible"), so committers who don
While building some better plperl tests today I discovered a horrid bug
(which I regret to say is my fault), present in both 8.0 and HEAD
branches, The attached patch needs to be applied urgently to both
branches, please.
cheers
andrew
Index: plperl.c
=
Patch applied by Tom. Thanks.
Backpatched to 8.0.X.
---
Magnus Hagander wrote:
> There is special code in the send_message_to_server_log
> >>>
> >>>function to make
> >>>
> sure it's written directly to the file.
Previous version of patch removed from queue.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
-
There is special code in the send_message_to_server_log
>>>
>>>function to make
>>>
sure it's written directly to the file.
>>>
>>>If the logger is complaining, it's quite possibly because it's
>>>unable to
>>>write to its file. Now that you mention it, doesn't this
>code go into
>>>inf
Backpatched to 7.4.X.
---
Christopher Kings-Lynne wrote:
> No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
> dump 7.0.x database backends correctly.
>
> I submitted a fix for 7.5 dumping 7.0 previousl
Patch applied. Thanks.
---
Christopher Kings-Lynne wrote:
> No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
> dump 7.0.x database backends correctly.
>
> I submitted a fix for 7.5 dumping 7.0 previo
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Christopher Kings-Lynne wrote:
> No, the
It's not a problem, since that code path is only ever executed when
dumping a 7.0 backend. It's in the MyFormatType function in pg_dump.c
that is used whenever the backend doesn't have its own format_type function.
Right. The patch looked dangerous to me too, until I understood the
context. As
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Do we know that is always true? What is the issue that 7.0 needs this
>> and newer released don't, and how are we sure this will not break some
>> strange cases in post-7.0 releases?
> It's not a problem, since that code path is only ever exe
Duh, sorry. Got confused. I though you weren't the submitter, for some
strange reason. Anyway, I see this in the code:
+ /* Handle array types */
+ if (typname[0] == '_')
+ {
+ isarray = true;
+ typname++;
+ }
Do we know that is always true? What is th
Christopher Kings-Lynne wrote:
> >>I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
>
> That previous fix was for a different issue...
>
> > Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
> > would even work. :-)
>
> Yes, it works fine. We still sup
I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
That previous fix was for a different issue...
Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
would even work. :-)
Yes, it works fine. We still support pg_dumping all 7.x databases.
Anyway, you say the f
Christopher Kings-Lynne wrote:
> No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
> dump 7.0.x database backends correctly.
>
> I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
would e
No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
dump 7.0.x database backends correctly.
I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
Chris
Bruce Momjian wrote:
Uh, not sure anyone would even see a 7.0.X release if we made it, and I
question how man
Uh, not sure anyone would even see a 7.0.X release if we made it, and I
question how many are using varying[]. Your patch is now in the
archives, and we can point folks to it if they ask.
---
Christopher Kings-Lynne wrote:
Hi,
I know 7.0.x is pretty old, but I'm wondering if we should fix this to
make it better for people upgrading.
If you create a table like this in 7.0.x:
CREATE TABLE address (
first_name character varying(50) DEFAULT 'asdf' NOT NULL,
last_name character varying(50) NOT NULL,
address
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the proble
[EMAIL PROTECTED] writes:
> I patched it, here my diff -c pg_ctl pg_ctl_fixed:
I think you probably broke it rather than fixed it. Checking whether
the kill worked isn't a bad idea, but you can't just plow ahead if it
failed.
regards, tom lane
---
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem
4 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCHES] Bug in fd.c (FreeFile)
>
>
>
> I believe FreeFile has an "off by one" type error. Apart from possibly
> accessing past the end of the array, when combined with the
> while loop call
> from CleanupTempFiles, it co
I believe FreeFile has an "off by one" type error. Apart from possibly
accessing past the end of the array, when combined with the while loop call
from CleanupTempFiles, it contrives to fail to fclose a number of files [at
a guess, floor((numAllocatedFiles-1)/2)] when CleanupTempFiles is called
(u
Patch applied.
---
Bruce Momjian wrote:
> I found a bug in the pg_restore code. It shows up only using the tar
> format, and only on Windows XP (not Win2000 or BSD/OS). However, the
> bug exists on all platforms that don't
I found a bug in the pg_restore code. It shows up only using the tar
format, and only on Windows XP (not Win2000 or BSD/OS). However, the
bug exists on all platforms that don't return zero'ed memory from
malloc, which is basically everyone. We have gotten away with this
because malloc memory is
Patch applied. Thanks.
---
Joe Conway wrote:
> I discovered that TupleDescGetAttInMetadata and BuildTupleFromCStrings
> don't deal well with tuples having dropped columns. The attached fixes
> the issue. Please apply.
>
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Joe Conway wrote:
> I discovered that Tup
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Do we need a 'AND NOT a.attisdropped' in there anywhere as well?
Hm, probably a good idea, although in the current state of the code
it theoretically shouldn't matter. (DROP COLUMN zeroes atttypid,
so that part of the join won't succeed. But
Do we need a 'AND NOT a.attisdropped' in there anywhere as well?
Chris
On Tue, 23 Sep 2003, Irina Sourikova wrote:
>
> Hi,
>
> I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
> work
> for me until I added one line:
>
> strcat(buf, " AND c.relname <> 'vacuum_l'")
Irina Sourikova <[EMAIL PROTECTED]> writes:
> I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
> work
> for me until I added one line:
> strcat(buf, " AND c.relname <> 'vacuum_l'");
Hmm. This bug was patched last year in CVS tip, but apparently not in
the 7.3 bra
Hi,
I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
work
for me until I added one line:
strcat(buf, " AND c.relname <> 'vacuum_l'");
after strcat(buf, "SELECT c.relname, a.attname ");
strcat(buf, "FROM pg_class c, pg_attribute a, pg_type t ");
strcat(buf
Hi There's a bug in the clusterdb script where it looks like the arguments
to the psql command are being passed in the wrong order, so it fails when
you run it on a database that is not on localhost.
Here's the output from the command:
133 anands-Computer:bin/scripts> clusterdb -h wooster -U rr gr
I discovered that TupleDescGetAttInMetadata and BuildTupleFromCStrings
don't deal well with tuples having dropped columns. The attached fixes
the issue. Please apply.
Thanks,
Joe
Index: src/backend/executor/execTuples.c
===
RCS fil
100 matches
Mail list logo
