On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote:
I just wanted to mention that the latest release of OpenBSD i386
(4.0) is still broken too. So the ecpg-check failure would apply to
(at least) to 3.8, 4.0, and likely 3.9.
ok, but then we have some hosts in the buildfarm that run the
Joachim Wieland wrote:
On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote:
I just wanted to mention that the latest release of OpenBSD i386
(4.0) is still broken too. So the ecpg-check failure would apply to
(at least) to 3.8, 4.0, and likely 3.9.
ok, but then we have some hosts in
On Fri, 12 Jan 2007 10:09:34 +0100 Joachim Wieland [EMAIL PROTECTED] wrote:
On Fri, Jan 12, 2007 at 09:29:36AM +0100, Stefan Kaltenbrunner wrote:
ok, but then we have some hosts in the buildfarm that run the updated
versions like zebra and spoonbill. In this case we can't decide on the
OS
I find it very unlikely that you would during normal operations
end up
in a situation where you would first have permissions to create
files in
a directory, and then lose them.
What could be is that you have a directory where you never had
permissions to create the file in the first
comments?
Why not make it probabilistic by using, say, MyProcPid % n where n
is the
number of tablespaces? Then you don't need anything shared.
You still want a (local) counter, so that temp files for one session are
spread out.
Andreas
---(end of
On Thu, Jan 11, 2007 at 10:47:32PM -0500, Tom Lane wrote:
Actually I'd suggest that using an exported variable at all is probably
bad style. I'd suggest that libecpg export a set() function instead:
...
I think I found an easier solution. With my latest commit ecpg uses a
#define to set a
On Fri, Jan 12, 2007 at 01:20:15AM +0100, Joachim Wieland wrote:
Attached is a patch to get guppy green again (hopefully).
Applied.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL
On Thu, Jan 11, 2007 at 02:35:13PM -0800, [EMAIL PROTECTED] wrote:
I caught this thread about O_DIRECT on kerneltrap.org:
http://kerneltrap.org/node/7563
It sounds like there is much to be gained here in terms of reducing
the number of user/kernel space copies in the operating system. I
I had a problem when upgrading a database from 8.1.4 to 8.2.1:
Sorry, the error messages are in german.
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1531; 1259 3477393 INDEX
idx_inspektionen_dat_inspektion
pg_restore: [archiver (db)]
Zeugswetter Andreas ADI SD wrote:
comments?
Why not make it probabilistic by using, say, MyProcPid % n where n
is the
number of tablespaces? Then you don't need anything shared.
You still want a (local) counter, so that temp files for one session are
spread out.
Yes, but this can
On Fri, Jan 12, 2007 at 11:55:07AM +0100, Mario Weilguni wrote:
to_char(timestamp, '') should be constant and marked immutable,
or am I wrong here? Or is it not marked immutable because of possible
changes on date_format?
AIUI, to_char is not immutable because it can be effected by
Joachim Wieland [EMAIL PROTECTED] writes:
Attached patch enables the special expected files only for
i386-unknown-openbsd3.8.
This seems the wrong approach; we do not have anywhere near that good a
handle on which platforms have this behavior. I'd vote for treating it
like a locale difference,
Am Freitag, 12. Januar 2007 14:48 schrieb Martijn van Oosterhout:
On Fri, Jan 12, 2007 at 11:55:07AM +0100, Mario Weilguni wrote:
to_char(timestamp, '') should be constant and marked immutable,
or am I wrong here? Or is it not marked immutable because of possible
changes on date_format?
On Fri, Jan 12, 2007 at 10:49:53AM +0100, Zeugswetter Andreas ADI SD wrote:
I find it very unlikely that you would during normal operations
end up
in a situation where you would first have permissions to create
files in
a directory, and then lose them.
What could be is that you
On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote:
... And anyway there should never
*be* a real permissions problem; if there is then the user's been poking
under the hood sufficient
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
It seems the win unlink is not implemented correctly and we need to
replace it.
Easier said than done ...
regards, tom lane
---(end of broadcast)---
TIP 3: Have you
Mario Weilguni [EMAIL PROTECTED] writes:
Thanks for the info. Changing this to use extract is no real problem, I was
just curious if this is intendend behaviour.
From the CVS logs:
2006-11-28 14:18 tgl
* src/include/catalog/: pg_proc.h (REL7_3_STABLE), pg_proc.h
Mario Weilguni wrote:
I had a problem when upgrading a database from 8.1.4 to 8.2.1:
Sorry, the error messages are in german.
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1531; 1259
3477393 INDEX idx_inspektionen_dat_inspektion
Attached is a patch to get guppy green again (hopefully).
The two new files go into src/interfaces/ecpg/test/expected
Hi,
I just wanted to mention that the latest release of OpenBSD i386
(4.0) is still broken too. So the ecpg-check failure would apply to
(at least) to 3.8, 4.0, and likely
Magnus Hagander [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
One point worth making is that I'm not really convinced anymore that
we have proof that antivirus code has been creating any such problems.
We do. I have positive proof of this being caused by
On 1/11/07, Gurjeet Singh [EMAIL PROTECTED] wrote:
Also, the sources are not available.
Do you plan to make the sources available?
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 3rd Floor| [EMAIL
Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Attached patch enables the special expected files only for
i386-unknown-openbsd3.8.
This seems the wrong approach; we do not have anywhere near that good a
handle on which platforms have this behavior. I'd vote for treating it
like
I wrote:
I find it very unlikely that you would during normal operations
end up
in a situation where you would first have permissions to create
files in
a directory, and then lose them.
What could be is that you have a directory where you never had
permissions to create the file in
On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
One point worth making is that I'm not really convinced anymore that
we have proof that antivirus code has been creating any such
Yeah, it's a workaround. Since there's no concept other than
alpha/numeric/latin in tsearch2, Asian characters have to be fall in
one of them.
Ok, I see.
Pls, test attached patch - if it is good then I'll commit it at Monday to HEAD
and 8.2 branches.
PS. Magnus, may I ask you to test under
Magnus Hagander [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
No, I didn't claim that Windows AV software is bug-free ;-). What I
said was that I'm not certain it's related to the permission denied
reports, as opposed to other problems. Or are your stack
Michael Enke wrote:
Hello all,
I have a feature request as I think it is not possible with the actual
version:
I want to load huge amount of data and I know that COPY is much faster than
doing inserts.
But in my case I have an already filled table and rows (not all, only partly)
from
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
No, I didn't claim that Windows AV software is bug-free ;-). What I
said was that I'm not certain it's related to the permission denied
reports, as opposed to other problems.
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, it could still be the same problem, with the AV software only
involved to the extent that it's trying to scan files for viruses.
Partially the same, but I've seen AV software keeping it open for
hours... Basically until
On 1/11/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I am not clear about what is being proposed. Currently buildfarm syncs
against (or pulls a fresh copy from, depending on configuration) either
the main anoncvs repo or a mirror (which you can get using cvsup or
[EMAIL PROTECTED] wrote:
What do you think about setting up the buildfarm clients
with the users they are willing to test patches for, as opposed to
having the patch system track who is are trusted users? My thoughts
are the former is easier to implement and that it allows anyone to use
the
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, it could still be the same problem, with the AV software only
involved to the extent that it's trying to scan files for viruses.
Partially the same, but I've seen AV software keeping it open for
hours...
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
pg_control is certainly not ever deleted or renamed, and in fact I
believe there's an LWLock enforcing that only one PG process at a time
is even touching it. So we need another theory to explain this one :-(
Right. What we need is a
I just had a thought about fixing those Windows permission denied
problems. The case that we believe we understand is where the bgwriter
is trying to execute a previously-logged fsync request against a table
file that is pending delete --- that is, actually has been unlink()'d,
but some other
On 1/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi Gurjeet glad you copied me, else would have missed it no longer
subscribed.
I also almost missed your mail. I was monitoring just the conversation
(gmail) that I sent you mail in, but since you changed the subject, it
almost
Joachim Wieland wrote:
On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote:
Can't comment on that one, since I just noticed it existed. How similar
was this one to the standard regression tests? Those were moved into a
C executable so they'd run on a Windows system without a shell,
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
Christopher Browne wrote:
Seems to me that you could get ~80% of the way by having the simplest
2 queue implementation, where tables with size some threshold get
thrown at the little table queue, and tables above that size go to
On 1/12/07, Martijn van Oosterhout kleptog@svana.org wrote:
On Thu, Jan 11, 2007 at 02:35:13PM -0800, [EMAIL PROTECTED] wrote:
I caught this thread about O_DIRECT on kerneltrap.org:
http://kerneltrap.org/node/7563
It sounds like there is much to be gained here in terms of reducing
the
These two items are complete in 8.2, IIRC
Allow constraint_exclusion to work for UNIONs like it does for
inheritance, allow it to work for UPDATE and DELETE statements, and
allow it to be used for all statements with little performance impact
Fix memory leak from exceptions
On Fri, 2007-01-12 at 19:33 -0300, Alvaro Herrera wrote:
Alvaro, have you completed your design?
No, I haven't, and the part that's missing is precisely the queues
stuff. I think I've been delaying posting it for too long, and that is
harmful because it makes other people waste time
On Thu, Jan 11, 2007 at 06:04:56PM -0500, Andrew Dunstan wrote:
Please don't. At least not on the PostgreSQL web site nor in the docs.
And no, I don't run my production servers on Windows either.
For good or ill, we made a decision years ago to do a proper Windows
port. I think that it's
This works for small amount of data. But for large amount of data
the join takes a lot of time.
Regards,
Michael
Bruce Momjian wrote:
Michael Enke wrote:
Hello all,
I have a feature request as I think it is not possible with the actual version:
I want to load huge amount of data and I know
Michael Enke wrote:
This works for small amount of data. But for large amount of data
the join takes a lot of time.
It certainly is faster then anly algorithm that checks for duplicates
for each lines of copy input could ever be. Especially for joins, doing
them in one large batch allows you
Yeah, it's a workaround. Since there's no concept other than
alpha/numeric/latin in tsearch2, Asian characters have to be fall in
one of them.
Ok, I see.
Pls, test attached patch - if it is good then I'll commit it at Monday to
HEAD
and 8.2 branches.
I have tested on a Linux box
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Alvaro
Herrera) transmitted:
Simon Riggs wrote:
Some feedback from initial testing is that 2 queues probably isn't
enough. If you have tables with 100s of blocks and tables with
millions of blocks, the tables in the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can load
Tom Lane [EMAIL PROTECTED] writes:
3. What about dependencies on user-defined types, functions, etc?
How will you get things to behave sanely if one backend tries to drop a
type that some other backend is using in a column of a temp table? Even
if you put entries into pg_depend, which would
On Thu, Jan 11, 2007 at 09:51:39PM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just
Hi all,
Sorry for arriving so late into the discussion.
I don't know if it's possible but it could be useful to have the text
of the query which required the creation of the temporary files as an
additional DETAIL line. At least, if it's possible to have it in this
part of the code.
Thoughts?
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote:
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
If your
hardware is unreliable the corruption could anywhere.
Agreed.
I thought the point
Simon Riggs wrote:
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
and kind of at an odd place. I don't
think we want to go down the road of throwing trace in everwhere, do
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote:
I think the right approach is to look at our existing code and come up
with places we want them, and add them in one shot. Doing thing
in small parts doesn't work too well with a project this size.
Will do.
--
Simon Riggs
Guillaume Smet wrote:
Hi all,
Sorry for arriving so late into the discussion.
I don't know if it's possible but it could be useful to have the text
of the query which required the creation of the temporary files as an
additional DETAIL line. At least, if it's possible to have it in this
Hi Bruce,
Thanks for your answer.
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
We have the ability to conditionally print statements based on error
level, but LOG isn't a valid level for log_min_error_statement.
We could add a parameter that few people would use, but the right way to
do
Guillaume Smet [EMAIL PROTECTED] writes:
That's not what I had in mind. I was asking if the text of the query
was available when logging the temp file usage. If so it could be good
to add a DETAIL line with it directly and systematically when logging
the temp file usage.
(1) you could make
Guillaume Smet wrote:
Hi Bruce,
Thanks for your answer.
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
We have the ability to conditionally print statements based on error
level, but LOG isn't a valid level for log_min_error_statement.
We could add a parameter that few people
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If you want the
query, why not just log them all?
On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
That's not what I had in mind. I was asking if the text of the query
was available when logging the temp file usage. If so it could be good
to add a DETAIL line with it directly and systematically when
Guillaume Smet [EMAIL PROTECTED] writes:
On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote:
(2) there is already a generalized solution to this, it's called
log_min_error_statement.
I didn't think of that when posting my message but Bruce seems to say
that we can't use it in this case.
Dunno why
Guillaume Smet wrote:
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If you want the
query, why
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we could forcibly activate the freeze mode on a template database?
Might not be a bad idea. And even more to the point, forcibly disable
analyze.
Patch implementing this (albeit untested!)
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok, it does what it's intended to do. But in testing it I also
confirmed that a database-wide vacuum creates a pgstat entry for it and
for all tables in it. Is this something we want to prevent?
That's odd, because I didn't see any such thing when I
Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote:
(2) there is already a generalized solution to this, it's called
log_min_error_statement.
I didn't think of that when posting my message but Bruce seems to say
that we can't use it
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok, it does what it's intended to do. But in testing it I also
confirmed that a database-wide vacuum creates a pgstat entry for it and
for all tables in it. Is this something we want to prevent?
That's odd, because I didn't see
In response to Guillaume Smet [EMAIL PROTECTED]:
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok, it does what it's intended to do. But in testing it I also
confirmed that a database-wide vacuum creates a pgstat entry for it and
for all tables in it. Is this something we want to
On Thu, 2007-01-11 at 21:04 -0500, Neil Conway wrote:
Comments? I'll write up a doc patch, barring any objections.
I'll apply the attached doc patch to CVS tomorrow, barring any
objections.
-Neil
Index: doc/src/sgml/datatype.sgml
67 matches
Mail list logo