> The issue is that if I set my machine's locale to Turkish or
> French, say, it doesn't matter what locale I set during
> initdb or in postgresql.conf, the server's log messages
> always seem to come out in the machine's locale.
Does this happen only for those locales? And how specifically do
> > The issue is that if I set my machine's locale to Turkish
> or French,
> > say, it doesn't matter what locale I set during initdb or in
> > postgresql.conf, the server's log messages always seem to
> come out in
> > the machine's locale.
>
> Does this happen only for those locales? And ho
On Wed, Dec 28, 2005 at 07:38:36PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > The issue is whether anything you want to ORDER BY needs to be
> > described by an B-tree operator class, and hence have a real sort
> > function.
>
> I think it's reasonable to remove that feature, *af
Looks like the plperl changes hurt Snake :-(
C:/Perl/lib/CORE/win32iop.h:304:1: warning: "kill" redefined
In file included from ../../../src/include/c.h:821,
from ../../../src/include/postgres.h:48,
from SPI.xs:2:
../../../src/include/port.h:197:1: warning: this i
On Tue, 2005-12-27 at 23:00 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > The TODO list has an item "add missing date selectivity", which is a
> > hang-over from 1999 or before.
> >
> > Is this still an issue? Can somebody describe exactly what it is?
> >
> > I can't find the exact discuss
On Thu, 2005-12-29 at 10:47 +0300, Dmitry Panov wrote:
> On Wed, 2005-12-28 at 11:05 -0500, Tom Lane wrote:
> > Dmitry Panov <[EMAIL PROTECTED]> writes:
> > > Yes, but if the server has crashed earlier the script won't be called
> > > and if the filesystem can't be recovered the changes will be los
On Wed, 2005-12-28 at 20:58 -0500, Bruce Momjian wrote:
> Having read through this thread, I would like to propose a
> syntax/behavior.
>
> I think we all now agree that the logging is more part of the table than
> the command itself. Right now we have a COPY LOCK patch, but people are
> going to
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We have a build failure to fix first:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-29%2000:44:52
Weird. It seems to be choking on linking to check_function_bodies,
but plpgsql does that exactly the sam
> So, my thinking would be to separate things into two:
> a) Add a TODO item "shared temp tables" that caters for (1) and (4)
>
> ALTER TABLE name RELIABILITY
> {DELETE ROWS AT RECOVERY | FULL RECOVERY}
> (syntax TBD)
DELETE ROWS AT RECOVERY would need to be careful or disal
On Thu, 2005-12-29 at 09:35 -0500, Rod Taylor wrote:
> > So, my thinking would be to separate things into two:
> > a) Add a TODO item "shared temp tables" that caters for (1) and (4)
> >
> > ALTER TABLE name RELIABILITY
> > {DELETE ROWS AT RECOVERY | FULL RECOVERY}
> > (syntax TBD
Martijn van Oosterhout writes:
> Hmm. By feature I assume you mean "ORDER BY ... USING" (which no-one
> could find an example of) and not "requiring the operator to be part of
> an opclass".
> In fact, I don't think we ever need to remove the syntax, just as long
> as the operator is part of an o
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I would also like to add -Wno-comment to the CFLAGS for win32/gcc, top
> suppress at least some of those warnings.
Why don't you complain to the Perl people, instead? The fact that no
such warnings occur on Unix Perl installations makes these seem pre
Bruce Momjian said:
> DROP would drop the table on a restart
> after a non-clean shutdown. It would do _no_ logging on the table and
> allow concurrent access, plus index access. DELETE is the same as
> DROP, but it just truncates the table (perhaps TRUNCATE is a better
> word).
>
> EXCLUSIVE wou
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2005-12-27 at 23:00 -0500, Bruce Momjian wrote:
>> * Add missing rtree optimizer selectivity
> I thought rtree was no longer supported either...
We still have rtree-like opclasses. I agree the TODO item is worded
in a way that makes it look obsol
Andrew Dunstan wrote:
> Bruce Momjian said:
> > DROP would drop the table on a restart
> > after a non-clean shutdown. It would do _no_ logging on the table and
> > allow concurrent access, plus index access. DELETE is the same as
> > DROP, but it just truncates the table (perhaps TRUNCATE is a b
Simon Riggs <[EMAIL PROTECTED]> writes:
> My view would be that this thread has been complex because everybody has
> expressed a somewhat different requirement, which could be broken down
> as:
> 1. The need for a multi-user-accessible yet temporary table
> 2. Loading data into a table immediately
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have committed a fix - the perl headers were mangling DLLIMPORT so I
> moved the declaration above the perl includes.
BTW, probably a cleaner answer is to put check_function_bodies into some
header file instead of having an "extern" in the PLs' .c fi
Bruce Momjian writes:
> Andrew Dunstan wrote:
>> I an horribly scared that this will be used as a "performance boost" for
>> normal use. I would at least like to see some restrictions that make it
>> harder to mis-use. Perhaps restrict to superuser?
> Certainly restrict to table owner.
I can see
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > My view would be that this thread has been complex because everybody has
> > expressed a somewhat different requirement, which could be broken down
> > as:
> > 1. The need for a multi-user-accessible yet temporary table
> > 2. Loading da
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2005-12-27 at 23:00 -0500, Bruce Momjian wrote:
> >> * Add missing rtree optimizer selectivity
>
> > I thought rtree was no longer supported either...
>
> We still have rtree-like opclasses. I agree the TODO item is worded
> i
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I would also like to add -Wno-comment to the CFLAGS for win32/gcc, top
>> suppress at least some of those warnings.
>
> Why don't you complain to the Perl people, instead? The fact that no
> such warnings occur on Unix Perl installati
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.
---
Eu
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I have committed a fix - the perl headers were mangling DLLIMPORT so I
>> moved the declaration above the perl includes.
>
> BTW, probably a cleaner answer is to put check_function_bodies into
> some header file instead of having an "e
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Bruce Momjian said:
> > DROP would drop the table on a restart
> > after a non-clean shutdown. It would do _no_ logging on the table and
> > allow concurrent access, plus index access. DELETE is the same as
> > DROP, but it just truncates the table
Greg Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian said:
> > > DROP would drop the table on a restart
> > > after a non-clean shutdown. It would do _no_ logging on the table and
> > > allow concurrent access, plus index access. DELETE is the same as
> > > DROP,
I believe this is one of the projects that we have slated for removal, since
it lives nicely elsewhere. Is it worth me writing up a patch to remove the
files and update the README to provide pointers to the project site and maybe
a few other places like the oraclecompat project (and maybe even
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> BTW, probably a cleaner answer is to put check_function_bodies into
>> some header file instead of having an "extern" in the PLs' .c files. I
>> was thinking about that yesterday, but couldn't decide where was a good
>> place to put
Hi,
I have a query that previously worked fine using pg8 on Fedora. Since
then we've moved to a FreeBSD 6 server running pg8.1.1 and the query
doesn't seem to ever finish.
I have VACUUM ANALYZEd the database. Here is the query:
SELECT column_name, table_schema, table_name, c.data_type,
et.data_t
Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Tom Lane said:
>>> BTW, probably a cleaner answer is to put check_function_bodies into
>>> some header file instead of having an "extern" in the PLs' .c files.
>>> I was thinking about that yesterday, but couldn't decide where was a
>
Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem.
On Thu, Dec 29, 2005 at 11:14:59AM -0800, Sebastian wrote:
> I have a query that previously worked fine using pg8 on Fedora. Since
> then we've moved to a FreeBSD 6 server running pg8.1.1 and the query
> doesn't seem to ever finish.
How long did you wait? In one of my tests the query took over th
I've waited 10 minutes before cancelling. On pg8 it runs in less than a second
: test=> EXPLAIN SELECT * FROM information_schema.element_types;
: ERROR: record type has not been registered
I can reproduce this...
- sebastian
On 12/29/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 29
On Thu, Dec 29, 2005 at 12:12:52PM -0800, Sebastian wrote:
> I've waited 10 minutes before cancelling. On pg8 it runs in less than a second
How many columns in the table? In 8.1.1 I'm seeing a nearly
exponential increase in time with each extra column, at least up
to about five columns; with more
> How many columns in the table?
There are 4 columns in the table
On 12/29/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 29, 2005 at 12:12:52PM -0800, Sebastian wrote:
> > I've waited 10 minutes before cancelling. On pg8 it runs in less than a
> > second
>
> How many columns in the t
On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
> Well, no, that's not the problem: the problem is that you should be able
> to specify ORDER BY any sort ordering that the system can deal with, and
> the USING syntax is in fact too impoverished to do that. What if the
> mentioned operato
On Dec 29 2005, Michael Fuhr wrote:
On Thu, Dec 29, 2005 at 12:12:52PM -0800, Sebastian wrote:
> I've waited 10 minutes before cancelling. On pg8 it runs in less than
> a second
How many columns in the table? In 8.1.1 I'm seeing a nearly
exponential increase in time with each extra column, a
Robert Treat wrote:
> I believe this is one of the projects that we have slated for removal, since
> it lives nicely elsewhere. Is it worth me writing up a patch to remove the
> files and update the README to provide pointers to the project site and maybe
> a few other places like the oraclecomp
Tom, has this bug been addressed or documented?
---
Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > On Sun, Dec 18, 2005 at 10:08:22PM -0500, Tom Lane wrote:
> >> Just for the record, that behavior is serio
Bruce Momjian writes:
> Tom, has this bug been addressed or documented?
No. Please add a TODO:
* Make CLUSTER preserve recently-dead tuples per MVCC requirements
I have not tested, but I suspect the table-rewriting variants of ALTER TABLE
have the same problem.
regards
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom, has this bug been addressed or documented?
>
> No. Please add a TODO:
>
> * Make CLUSTER preserve recently-dead tuples per MVCC requirements
>
> I have not tested, but I suspect the table-rewriting variants of ALTER TABLE
> have the same problem
I encountered an error today (can't repeat) on SunOS 5.8:
--test that we read consecutive LFs properly
CREATE TEMP TABLE testnl (a int, b text, c int);
+ ERROR: could not open relation 1663/16384/37713: Interrupted system call
The reason I guess is the open() call is interrupted by a signal
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> + ERROR: could not open relation 1663/16384/37713: Interrupted system call
> The reason I guess is the open() call is interrupted by a signal (what
> signal BTW?).
I've heard of this in connection with NFS ... is your DB on an NFS
filesystem by any cha
"Tom Lane" <[EMAIL PROTECTED]> wrote
> Qingqing Zhou <[EMAIL PROTECTED]> writes:
>> + ERROR: could not open relation 1663/16384/37713: Interrupted system
>> call
>
>> The reason I guess is the open() call is interrupted by a signal (what
>> signal BTW?).
>
> I've heard of this in connection with
On Thursday 29 December 2005 21:35, Bruce Momjian wrote:
> Robert Treat wrote:
> > I believe this is one of the projects that we have slated for removal,
> > since it lives nicely elsewhere. Is it worth me writing up a patch to
> > remove the files and update the README to provide pointers to the p
44 matches
Mail list logo
