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 PROTE
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 shall not specify INSENSITIVE.
>
> b) If an of FOR UPDATE with or without
> a is specified, then neither SCROLL nor
>
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
http://doxygen.post
"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
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
Ma
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 MaxIndexT
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
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);
i
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 level
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 beli
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 symbo
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 contr
"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
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 gla
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 abilit
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 sim
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 sho
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 i
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...
> Name
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
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
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
catalog/pg_ty
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 :-(
>
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). An
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 re
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.
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-
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
vacuu
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
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 pot
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 incredi
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.
r
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 yo
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
shou
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 starve
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?
> Unfortunate
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
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 in
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 8/07.
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 sane
"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 deter
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
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 see
* 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 wi
"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
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 meanin
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 di
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 im
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 73
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 s
68 matches
Mail list logo
