On 10/25/07, Gregory Stark [EMAIL PROTECTED] wrote:
Huh, I hadn't heard of that either. The Debian package patchutils says it was
downloaded from:
http://cyberelk.net/tim/data/patchutils
What's really cool is that patchutils also appears to have the utility I've
been looking for for a
If a cursor is declared using Order by then it gives following error
during updation of the cursor:
ERROR: cursor c is not a simply updatable scan of table test
Ex:
DROP TABLE IF EXISTS test;
create table test (num int,num2 int );
insert into test values(1,100);
insert into test values(2,200);
I just consider this may happens and pg can't recover correctly:
if postgres crashed last time and left a postmaster.pid file, and last
postgres
id is reused by another process which is not postgres now.
Tom Lane [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED]
Richard Wang [EMAIL PROTECTED]
Roberto Icardi wrote:
Also, please set pgAdmin to 'Debug' log level (under File-Options),
create a new log of you recreating the crash (using direct debugging,
not a global breakpoint) and then send me the logfile.
Done
Doesn't shed any light though unfortunately. Do you have a firewall on
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
I know I haven't been very active for a while here, but I just got to
testing the October 3 version a bit prior to getting back to the Java
GSS client stuff I promised. There seem to be some funny things there.
Apologies for
Hi everybody,
I'm looking for using zlib function directly in the database :
Example : a function zipit that would take a bytea as argument and
returns a compressed bytea
and an unzipit that would take a compressed bytea as argument and
returns a uncompressed bytea
I'm sure it's very easy to
Tom Lane wrote:
SQL92 has this under Leveling Rules:
1) The following restrictions apply for Intermediate SQL:
a) A declare cursor shall not specify INSENSITIVE.
b) If an updatability clause of FOR UPDATE with or without
a column name list
Is there any reason to have both these macros? By my opinion
MaxHeapTuplesPerPage is more accurate and it should replace all
MaxOffsetNumber occurrence.
Any comments?
Zdenek
http://doxygen.postgresql.org/htup_8h.html#c8829334a53a69e12b070bf09b7b7ab7
Hubert FONGARNAND [EMAIL PROTECTED] writes:
I'm sure it's very easy to implement as a C function that would call zlib
Is there already an implementation of such things?
Not that I'm aware though you might look at pgcrypto. Good crypto has to
compress first so there may be a possibility of
Zdenek Kotala wrote:
Is there any reason to have both these macros? By my opinion
MaxHeapTuplesPerPage is more accurate and it should replace all
MaxOffsetNumber occurrence.
We use MaxOffsetNumber with index pages as well.
At quick glance, the only places I can see where we could replace
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Is there any reason to have both these macros? By my opinion
MaxHeapTuplesPerPage is more accurate and it should replace all
MaxOffsetNumber occurrence.
We use MaxOffsetNumber with index pages as well.
I forgot to indexes, but there is
On Thu, 2007-10-25 at 12:28 +0530, Dharmendra Goyal wrote:
If a cursor is declared using Order by then it gives following
error
during updation of the cursor:
ERROR: cursor c is not a simply updatable scan of table test
Ex:
DROP TABLE IF EXISTS test;
create table test (num int,num2 int
According to SQL specifications: If READ ONLY is not specified in
cursor declaration then for update is
implicit.
Anyway, even if i specify for update in the declare clause, behaviour is
same.
DROP TABLE IF EXISTS test;
create table test (num int,num2 int );
insert into test values(1,100);
On Thu, 2007-10-25 at 16:53 +0530, Dharmendra Goyal wrote:
According to SQL specifications: If READ ONLY is not specified in cursor
declaration then for update is
implicit.
Though that isn't what the PostgreSQL docs say.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
The problem is that for TOAST columns :
The compression technique used is a fairly simple and very fast member
of the LZ family of compression techniques. See
src/backend/utils/adt/pg_lzcompress.c for the details.
With such function you could choose you compression algorithm and
compression
Magnus Hagander wrote:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
At the risk of diluting my message: I still think it's a mistake to
call it gss instead of something like gss-noprot. I believe this
will cause misunderstandings in the future when we get the
On Thu, Oct 25, 2007 at 09:26:47AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
At the risk of diluting my message: I still think it's a mistake to
call it gss instead of something like gss-noprot. I believe this
Hi,
I noticed that the default parser does not recognize Windows-style
filenames:
alvherre=# SELECT alias, description, token FROM ts_debug(e'c:\\archivos');
alias | description | token
---+-+--
asciiword | Word, all ASCII | c
blank | Space
I'm trying to solve one TODO item mentioned in
src/backend/utils/mmgr/mcxt.c.
/*
* MemoryContextSwitchTo
* Returns the current context; installs the given context.
*
* This is inlined when using GCC.
*
* TODO: investigate supporting inlining for some non-GCC compilers.
I observed that the parser calls the part after the host in a URL,
uri. This is quite incorrect; a URI is supposed to be a
generalization of a URL, so it makes no sense to call that a URI.
RFC 1738, section 3.1 calls that url-path.
Are there objections to changing it at this time? The contrib
Dharmendra Goyal [EMAIL PROTECTED] writes:
If a cursor is declared using Order by then it gives following error
during updation of the cursor:
ERROR: cursor c is not a simply updatable scan of table test
This is not a bug. (See also quote from SQL92 in the other thread.)
Richard Wang [EMAIL PROTECTED] writes:
I just consider this may happens and pg can't recover correctly:
if postgres crashed last time and left a postmaster.pid file, and last
postgres
id is reused by another process which is not postgres now.
Postgres defends itself against that just fine,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
Is there any reason to have both these macros? By my opinion
MaxHeapTuplesPerPage is more accurate and it should replace all
MaxOffsetNumber occurrence.
We use MaxOffsetNumber with index pages as well.
At quick glance, the
Am Donnerstag, 25. Oktober 2007 schrieb Zdenek Kotala:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
I don't find an inclusion of primnodes.h in ecpg. Which file are you looking
at?
--
On Thu, Oct 25, 2007 at 01:49:57PM +0200, Hubert FONGARNAND wrote:
Another question : does this TOAST code works for all type of data, like
TEXT (in our case)
Yes.
Have a nice day,
--
Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
From each according to his ability.
Peter Eisentraut wrote:
Am Donnerstag, 25. Oktober 2007 schrieb Zdenek Kotala:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
I don't find an inclusion of primnodes.h in ecpg. Which file
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that the default parser does not recognize Windows-style
filenames:
Is this something worth worrying about?
I'm not too excited about it. The fact that there's a filename category
at all seems a bit of a wart to me, particularly since simple
Zdenek Kotala [EMAIL PROTECTED] writes:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
Why in the world is ecpg including either primnodes.h or postgres.h?
By my opinion Datum should
Hi
In looking at current developments in computers, it seems we're nearing
a point where a fundamental change may be possible in databases...
Namely in-memory databases which could lead to huge performance
improvements.
A good starting point is to look at memcached, since it provides proof
that
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
Why in the world is ecpg including either primnodes.h or postgres.h?
The problem
I'd suggest looking at the source code to several of the in-memory
databases which already exist.
On 10/25/07, Dan [EMAIL PROTECTED] wrote:
Hi
In looking at current developments in computers, it seems we're nearing
a point where a fundamental change may be possible in databases...
Namely
Zdenek Kotala wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
By my opinion Datum should be defined in separate file and all
headers which use this type should include it. (this is problem on
many places with another types). Another question is why ecpg needs it?
Datum is a
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why in the world is ecpg including either primnodes.h or postgres.h?
The problem is that ecpg shares parser.c source code and this code
includes postgres.h.
ecpg cannot do that. It would fail if parser.c happened to use anything
that
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why in the world is ecpg including either primnodes.h or postgres.h?
The problem is that ecpg shares parser.c source code and this code
includes postgres.h.
ecpg cannot do that. It would fail if parser.c happened to
Zdenek Kotala [EMAIL PROTECTED] writes:
One solution should be put sugar words into separate header and include
them directly from catalog/*.h files.
Yeah, that would probably be a good idea. It's unlikely that we'll
get away anytime soon from frontend code wanting to include
Alvaro Herrera [EMAIL PROTECTED] writes:
I observed that the parser calls the part after the host in a URL,
uri. This is quite incorrect; a URI is supposed to be a
generalization of a URL, so it makes no sense to call that a URI.
I was wondering about that, but failed to go check :-(
RFC
Zdenek Kotala wrote:
Zdenek Kotala wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
By my opinion Datum should be defined in separate file and all
headers which use this type should include it. (this is problem on
many places with another types). Another question is
On Thu, Oct 25, 2007 at 08:05:24AM -0700, Dan wrote:
In looking at current developments in computers, it seems we're nearing
a point where a fundamental change may be possible in databases...
Namely in-memory databases which could lead to huge performance
improvements.
I think there are a
From time to time people have raised the idea of a CPAN-like mechanism
for downloading, building and installing extensions and the like (types,
functions, sample dbs, anything not requiring Postgres itself to be
rebuilt), and I have been thinking on this for the last few days. What
sort of
Simon Riggs wrote:
On Thu, 2007-10-25 at 14:45 +, Alvaro Herrera wrote:
Log Message:
---
Extract catalog info for error reporting before an error actually happens.
Also, remove redundant reset of for-wraparound PGPROC flag.
Just noticed you've made these changes. I was
On Thu, 2007-10-25 at 13:41 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Thu, 2007-10-25 at 14:45 +, Alvaro Herrera wrote:
Log Message:
---
Extract catalog info for error reporting before an error actually happens.
Also, remove redundant reset of for-wraparound
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:41 -0300, Alvaro Herrera wrote:
...
FWIW I disagree with cancelling just any autovac work automatically; in
my patch I'm only cancelling if it's analyze, on the grounds that if
you have really bad luck you can potentially lose a lot of work that
Magnus Hagander [EMAIL PROTECTED] writes:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
There's no way to specify the gssapi library to use. I have three on
my main development Sun: MIT, Sun, and Heimdal. I might have more
than one version of one of those three at some
Michael Paesold wrote:
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:41 -0300, Alvaro Herrera wrote:
...
FWIW I disagree with cancelling just any autovac work automatically; in
my patch I'm only cancelling if it's analyze, on the grounds that if
you have really bad luck you can potentially
On Oct 25, 2007, at 8:05 AM, Dan wrote:
In looking at current developments in computers, it seems we're
nearing
a point where a fundamental change may be possible in databases...
Namely in-memory databases which could lead to huge performance
improvements.
...
The sites that use it see
Have we got consensus that initdb should just look at the first
component of the locale name to choose a text search configuration
(at least for 8.3)? If so, who's going to make the change?
I can do it but don't want to duplicate effort if someone else
was already on it.
Alvaro Herrera wrote:
Michael Paesold wrote:
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:41 -0300, Alvaro Herrera wrote:
...
FWIW I disagree with cancelling just any autovac work automatically; in
my patch I'm only cancelling if it's analyze, on the grounds that if
you have really bad luck
Michael Paesold wrote:
In the previous discussion, Simon and me agreed that schema changes
should not happen on a regular basis on production systems.
Shouldn't we rather support the regular usage pattern instead of the
uncommon one? Users doing a lot of schema changes are the ones who
Alvaro Herrera [EMAIL PROTECTED] writes:
Michael Paesold wrote:
Yeah, I thought we had agreed that we must cancel all auto vacuum/analyzes,
on the ground that foreground operations are usually more important than
maintenance tasks.
What this means is that autovacuum will be starved a lot
On Oct 25, 2007, at 10:22 AM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
There's no way to specify the gssapi library to use. I have
three on
my main development Sun: MIT, Sun, and Heimdal. I might have more
Andrew Dunstan [EMAIL PROTECTED] writes:
Michael Paesold wrote:
Shouldn't we rather support the regular usage pattern instead of the
uncommon one? Users doing a lot of schema changes are the ones who
should have to work around issues, not those using a DBMS sanely. No?
Unfortunately, doing
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Michael Paesold wrote:
Shouldn't we rather support the regular usage pattern instead of the
uncommon one? Users doing a lot of schema changes are the ones who
should have to work around issues, not those using a DBMS sanely. No?
On Thu, 2007-10-25 at 13:51 -0400, Andrew Dunstan wrote:
Michael Paesold wrote:
In the previous discussion, Simon and me agreed that schema changes
should not happen on a regular basis on production systems.
Shouldn't we rather support the regular usage pattern instead of the
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:51 -0400, Andrew Dunstan wrote:
Michael Paesold wrote:
In the previous discussion, Simon and me agreed that schema changes
should not happen on a regular basis on production systems.
Shouldn't we rather support the regular usage pattern
Update on my testing 8.3beta1 on Solaris.
* CLOG reads
* Asynchronous Commit benefit
* Hot CPU Utilization
Regards,
Jignesh
__Background_:_
We were using PostgreSQL 8.3beta1 testing on our latest Sun SPARC
Enterprise T5220 Server using Solaris 10 8/07 and Sun Fire X4200 using
Solaris 10
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Michael Paesold wrote:
Shouldn't we rather support the regular usage pattern instead of the
uncommon one? Users doing a lot of schema changes are the ones who
should have to work around issues, not those using a DBMS sanely. No?
Jignesh K. Shah [EMAIL PROTECTED] writes:
CLOG data is
not cached in any PostgreSQL shared memory segments
The above statement is utterly false, so your trace seems to indicate
something broken. Are you sure these were the only reads of pg_clog
files? Can you extend the tracing to determine
On Thu, Oct 25, 2007 at 03:54:28PM -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
On Thu, 2007-10-25 at 13:51 -0400, Andrew Dunstan wrote:
Michael Paesold wrote:
In the previous discussion, Simon and me agreed that schema
changes should not happen on a regular basis on production
On Oct 25, 2007, at 1:47 AM, Magnus Hagander wrote:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
I know I haven't been very active for a while here, but I just got to
testing the October 3 version a bit prior to getting back to the Java
GSS client stuff I promised. There
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
What the krb5 method does is IMO a documented bug. The realm name is part
of the name.
As I explained at some length you cannot assume the username (first
component of the principal) has any meaning by itself, except in small
deployments with no
Jignesh K. Shah [EMAIL PROTECTED] writes:
CLOG data is not cached in any PostgreSQL shared memory segments and hence
becomes the bottleneck as it has to constantly go to the filesystem to get
the read data.
This is the same bottleneck you discussed earlier. CLOG reads are cached in
the
Tom Lane [EMAIL PROTECTED] writes:
Jignesh K. Shah [EMAIL PROTECTED] writes:
CLOG data is
not cached in any PostgreSQL shared memory segments
The above statement is utterly false, so your trace seems to indicate
something broken. Are you sure these were the only reads of pg_clog
files?
Tom Lane wrote:
Have we got consensus that initdb should just look at the first
component of the locale name to choose a text search configuration
(at least for 8.3)? If so, who's going to make the change?
I can do it but don't want to duplicate effort if someone else
was already on it.
On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
What the krb5 method does is IMO a documented bug. The realm name
is part
of the name.
As I explained at some length you cannot assume the username (first
component of the principal) has any
Gregory Stark [EMAIL PROTECTED] writes:
Didn't we already go through this? He and Simon were pushing to bump up
NUM_CLOG_BUFFERS and you were arguing that the test wasn't representative and
some other clog.c would have to be reengineered to scale well to larger
values.
AFAIR we never did get
Tom,
It's still true that I'm leery of a large increase in the number of
buffers without reengineering slru.c. That code was written on the
assumption that there were few enough buffers that a linear search
would be fine. I'd hold still for 16, or maybe even 32, but I dunno
how much impact
Josh Berkus [EMAIL PROTECTED] writes:
Actually, 32 made a significant difference as I recall ... do you still have
the figures for that, Jignesh?
I'd want to see a new set of test runs backing up any call for a change
in NUM_CLOG_BUFFERS --- we've changed enough stuff around this area that
I encountered PANICs on CentOS 5.0 when I ran write-mostly workload.
It occurs only if wal_sync_method is set to open_sync; there were
no problem in fdatasync. It occurred on both Postgres 8.2.5 and 8.3dev.
PANIC: could not write to log file 0, segment 212 at offset 3399680,
length
On Fri, 26 Oct 2007, ITAGAKI Takahiro wrote:
My nearby Linux guy says mixed usage of buffered I/O and direct I/O
could cause errors (EIO) on many version of Linux kernels.
I'd be curious to get some more information about this--specifically which
versions have the problems. I'd heard about
69 matches
Mail list logo