Hi,
Robert Lor robert@sun.com wrote:
The attached patch contains the probes (originally came from Theo
Schlossnagle) that were removed from the previous submitted patch.
Zdenek had some concerns about the way the probes were implemented
--On Freitag, März 06, 2009 02:26:12 +0100 Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
test=# select is_valid('978-3-937514-69-6'::isbn13);
ERROR: invalid check digit for ISBN number: 978-3-937514-69-6,
should be 7 ROW 1: select is_valid('978-3-937514-69-6'::isbn13);
According to
Hi,
I am trying to write values of different types to relation using following
code.
if(typbyval)
{
min_ba = (bytea *) palloc(len+1+VARHDRSZ);
memcpy(VARDATA(min_ba), min_datum, len);
SET_VARSIZE(min_ba, len+VARHDRSZ);
KaiGai Kohei wrote:
One matter was use permission, but I can agree to integrate
it into select permission as the original design did.
Ok, great.
The other is view. When we use a view in the query, it is extracted
as a subquery and its query tree is fetched from pg_rewrite.ev_action
which is
On Fri, 06 Mar 2009 00:32:40 +0100 Bernd Helmle wrote:
--On Freitag, März 06, 2009 02:26:12 +0100 Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
test=# select is_valid('978-3-937514-69-6'::isbn13);
ERROR: invalid check digit for ISBN number: 978-3-937514-69-6,
should be 7 ROW 1:
On Fri, 6 Mar 2009 07:14:20 +0100 A. Kretschmer wrote:
Nice advertisement for your book...
Actually the example is copypaste from the .tex file ;-)
Bye
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes:
The validator function should use the weak mode for itself to return
'f' in case of invalid input. It cannot be the users job to make sure a
validator function is working as expected.
Well the input function is being called before the
On Fri, Mar 6, 2009 at 10:03 AM, Kedar Potdar kedar.pot...@gmail.com wrote:
The aforementioned code works fine for types like int, data, text and I can
read values from the relation correctly. The problem arises for type
float8 which is not by value type and it has fixed length (8) where I
On Fri, 06 Mar 2009 10:50:41 + Gregory Stark wrote:
Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes:
The validator function should use the weak mode for itself to return
'f' in case of invalid input. It cannot be the users job to make sure a
validator function is working as
Thanks Greg, for showing interest.
The problem here is I need to store values of different types into bytearray
column of relation.
On Fri, Mar 6, 2009 at 4:33 PM, Greg Stark st...@enterprisedb.com wrote:
On Fri, Mar 6, 2009 at 10:03 AM, Kedar Potdar kedar.pot...@gmail.com
wrote:
The
--On Freitag, März 06, 2009 11:32:14 +0100 Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
No.
Straight from the source:
-- isn_weak(boolean) - Sets the weak input mode.
-- This function is intended for testing use only!
The validator function should use the weak mode for itself to
On Fri, Mar 6, 2009 at 11:41 AM, Kedar Potdar kedar.pot...@gmail.com wrote:
Thanks Greg, for showing interest.
The problem here is I need to store values of different types into bytearray
column of relation.
Oh, hm. I think you need to look at typlen instead of typbyval.
But you have an
On Fri, 06 Mar 2009 12:44:31 +0100 Bernd Helmle wrote:
--On Freitag, März 06, 2009 11:32:14 +0100 Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
I don't see anything that's not already documented. is_valid() checks the
presence of the invalid (!) marker only. It looks like the
On Fri, Mar 6, 2009 at 12:01 PM, Greg Stark st...@enterprisedb.com wrote:
But you have an additional problem for typbyval types: the pointer to
Datum isn't necessarily pointing at the right bytes. I think you have
to use the GET_[1248]_BYTES macros depending on typlen. There may be a
helper
I attached fix which modify foreign_data test. It fix problem with Czech
collation when numbers are ordered after letters. I retyped affected
column to name datatype which uses bitwise cmp.
Zdenek
diff -Nrc pgsql_psql.c3158b216657/src/test/regress/expected/foreign_data.out
Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes:
So this function is useless. If the syntax is valid, the check is
already done and is_valid() returns true. If the syntax is invalid, PG
will raise an error even before this function returns. The invalid
marker is not checked at all.
Hi Robert,
I tested your patch and it looks good. however I have several
comments/questions:
1) probes contains pointer but in probe.h it is declared as int. Is it
correct?
2) Maybe
TRACE_POSTGRESQL_SLRU_READPAGE_PHYSICAL_DONE(true, -1, -1);
would be better. Because slru_errcause, slru_errno
We have a customer running a very high-velocity database. We have set
up a PITR replica that's restoring correctly using JD's PITRtools and
pg_standby.
However, upon stopping the recovery and starting it for production (for
switchover) it promptly gets into these problems:
14895 2009-02-28
Alvaro Herrera alvhe...@commandprompt.com writes:
14903 2009-02-28 22:22:02 EST kangaroo app 49a9fe2e.3a37 ERROR: index
pg_toast_42299_index contains unexpected zero page at block 23768
There were actually several different instances of the first error
involving different toast values.
Do
ITAGAKI Takahiro píše v pá 06. 03. 2009 v 17:03 +0900:
Hi,
Robert Lor robert@sun.com wrote:
The attached patch contains the probes (originally came from Theo
Schlossnagle) that were removed from the previous submitted patch.
Zdenek had some concerns about the way the probes
Alvaro Herrera píše v pá 06. 03. 2009 v 10:32 -0300:
The servers are running 8.3.5.
Does this ring a bell for anyone?
look here:
http://archives.postgresql.org/pgsql-bugs/2008-11/msg00113.php
It look likes that there could be problem with btree wal.
Zdenek
--
Sent via
Zdenek Kotala wrote:
I attached fix which modify foreign_data test. It fix problem with Czech
collation when numbers are ordered after letters. I retyped affected
column to name datatype which uses bitwise cmp.
I have trouble understanding why this makes any sense at all. The only
thing you
Kedar Potdar kedar.pot...@gmail.com writes:
The problem here is I need to store values of different types into bytearray
column of relation.
Perhaps you should study the ANALYZE code. AFAICS your requirements are
not different from those of the pg_statistic data store. You should do
things
Alvaro Herrera píše v pá 06. 03. 2009 v 12:16 -0300:
Zdenek Kotala wrote:
I attached fix which modify foreign_data test. It fix problem with Czech
collation when numbers are ordered after letters. I retyped affected
column to name datatype which uses bitwise cmp.
I have trouble
Andreas 'ads' Scherbaum adsm...@wars-nicht.de writes:
This leads back to my initial question: intended behaviour or just a
bug? And how can one validate an ISBN without raising an error?
Judging from the comments, is_valid (and the internal validity bit)
were a bad design decision that the
Here's a little optimization for the parallel restore code, that
inhibits reopening the archive file unless the worker will actually need
to read from the file (i.e. a data member). It seems to work OK on both
Linux and Windows, and I propose to apply it in a day or two.
I've seen a recent
Andrew Dunstan and...@dunslane.net writes:
Here's a little optimization for the parallel restore code, that
inhibits reopening the archive file unless the worker will actually need
to read from the file (i.e. a data member). It seems to work OK on both
Linux and Windows, and I propose to
Thanks Tom for your interest.
I could find a workaround for the issue wherein the value of type
which is not stored by value and has fixed data length, is being
stored in string format to the relation.
While retrieving from relation, this value is converted by using
coerce_to_specific_type()
to
Kedar Potdar kedar.pot...@gmail.com writes:
I could find a workaround for the issue wherein the value of type
which is not stored by value and has fixed data length, is being
stored in string format to the relation.
The answer is simple: don't do that. You do not need to, and should
not,
On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Can you put together even a weakly reproducible test case? Something
that only fails every tenth or hundredth time would still help.
It seems that Olivier can reproduce the problem at will on Unixware. I
don't know if it's easy
Bryce Cutt pandas...@gmail.com writes:
Here is the new patch.
Our experiments show no noticeable performance issue when using the
patch for cases where the optimization is not used because the number
of extra statements executed when the optimization is disabled is
insignificant.
We have
Hi,
It seems that if you load libxml into a backend for whatever reason (say
you create a table with a column of type xml) and then create a plperlu
function that use XML::LibXML, we get a segmentation fault.
This sequence reproduces the problem for me in 8.3:
create table xmlcrash (a xml);
On Fri, Mar 6, 2009 at 1:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bryce Cutt pandas...@gmail.com writes:
Here is the new patch.
Our experiments show no noticeable performance issue when using the
patch for cases where the optimization is not used because the number
of extra statements
This looks like a problem caused by two different libxml versions:
the one used for the perl XML::LibXML wrappers and the one used to
build PostgreSQL. They really need to be the same. Does it still
segfault if they are identical?
Regards,
Ken
On Fri, Mar 06, 2009 at 04:14:04PM -0300, Alvaro
Alvaro Herrera wrote:
Hi,
It seems that if you load libxml into a backend for whatever reason (say
you create a table with a column of type xml) and then create a plperlu
function that use XML::LibXML, we get a segmentation fault.
Yes, I discovered this a few weeks ago. It looks like
Hi,
This message
r = (_QuerySecurityContextToken) (sspictx, token);
if (r != SEC_E_OK)
{
FreeLibrary(secur32);
pg_SSPI_error(ERROR,
gettext_noop(could not get security token from context), r);
}
looks poorly worded. What context is it talking
On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
Alvaro Herrera wrote:
Hi,
It seems that if you load libxml into a backend for whatever reason (say
you create a table with a column of type xml) and then create a plperlu
function that use XML::LibXML, we get a segmentation
Kenneth Marshall wrote:
This looks like a problem caused by two different libxml versions:
the one used for the perl XML::LibXML wrappers and the one used to
build PostgreSQL. They really need to be the same. Does it still
segfault if they are identical?
Unlikely, because AFAICT there's a
My Best Regards to all on this Mail List...
I'm using table partition on a large database to improve query performance
and vacuum management.
I'm read and understand all in item 5.9 in postgresql online manual.
In my father table, I have all the columns needed and which one is primary
key
Dickson S. Guedes escreveu:
[...]
Please, install the linuxtoolbox for AIX, try compile again and tell
us. It means that somethings is missing in your box.
Well done.
It works fine now, after I solved some incompatibilities between 32/64 bits, as
Tom pointed out here [1].
So, the flags that
On Fri, Mar 06, 2009 at 05:23:45PM -0300, Alvaro Herrera wrote:
Kenneth Marshall wrote:
This looks like a problem caused by two different libxml versions:
the one used for the perl XML::LibXML wrappers and the one used to
build PostgreSQL. They really need to be the same. Does it still
Kenneth Marshall wrote:
On Fri, Mar 06, 2009 at 05:23:45PM -0300, Alvaro Herrera wrote:
Kenneth Marshall wrote:
This looks like a problem caused by two different libxml versions:
the one used for the perl XML::LibXML wrappers and the one used to
build PostgreSQL. They really need to be
Hi
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
This time we did notice it two days too late.
I wish for a way to use out parameters in functions only through some
predefined prefix like in triggers new and old.
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
:)
This time we did notice it two days too late.
I wish for a way to use out parameters in
I think you missed the point of the performance questions. It wasn't
about avoiding extra simple if-tests in the per-tuple loops; a few of
those are certainly not going to add measurable cost given how complex
the code is already. (I really don't think you should be duplicating
hunks
Alvaro Herrera wrote:
Hi,
This message
r = (_QuerySecurityContextToken) (sspictx, token);
if (r != SEC_E_OK)
{
FreeLibrary(secur32);
pg_SSPI_error(ERROR,
gettext_noop(could not get security token from context), r);
}
looks poorly
Jonah H. Harris jonah.har...@gmail.com wrote:
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It really sucks what kind of mistakes you can pass to production
unknowingly. I would much prefer a way to prevent such nonsense.
Here was the case where out parameters were with
Kevin Grittner escribió:
I find the PostgreSQL implementation of OUT parameters, well,
surprising. I've used databases where stored procedures can have a
RETURN value, OUT parameters, and result streams as three discreet
things which can't be mistaken for one another -- which seems more
On Fri, 06 Mar 2009 10:27:52 -0500 Tom Lane wrote:
Judging from the comments, is_valid (and the internal validity bit)
were a bad design decision that the author later regretted, but felt
he couldn't change for compatibility reasons. I'm not sure why not
... we make bigger incompatible
On Fri, 06 Mar 2009 14:32:25 -0600, Kenneth Marshall wrote:
On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
Yes, I discovered this a few weeks ago. It looks like libxml is not
reentrant, so for perl you need to use some other XML library. Very
annoying.
Ugh! That is worse
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
This time we did notice it two days too late.
I wish for a way to use out parameters in functions
Robert,
I wonder whether it would be possible to make PL/pgsql take :foo to
mean the parameter named foo, and then provide an option to make that
THE ONLY WAY to refer to the parameter foo. For
backward-compatibility, and compatibility with (ahem) other database
products, we probably don't
Some of this behaviour (the plpgsql stuff) could be considered a bug,
but given the differences between pg's behaviour and the spec, the
expected behaviour probably needs to be thrashed out first (which is
why I didn't post this directly to -bugs).
Given (in 8.3.6):
create type ftype as (a
Holger Hoffstaette wrote:
On Fri, 06 Mar 2009 14:32:25 -0600, Kenneth Marshall wrote:
On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
Yes, I discovered this a few weeks ago. It looks like libxml is not
reentrant, so for perl you need to use some other XML library.
Andrew Dunstan wrote:
Holger Hoffstaette wrote:
http://www.nabble.com/New-libxml-which-is-reentrant---to18329452.html
Seems to me that Perl (?) is calling functions it is not supposed to call
- I'm guessing due to assumptions about mismatching lifecycles. The
parsing functions themselves
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Holger Hoffstaette wrote:
http://www.nabble.com/New-libxml-which-is-reentrant---to18329452.html
Seems to me that Perl (?) is calling functions it is not supposed to call
- I'm guessing due to assumptions about mismatching lifecycles. The
On Fri, 6 Mar 2009, Guillaume Smet wrote:
Date: Fri, 6 Mar 2009 18:58:58 +0100
From: Guillaume Smet guillaume.s...@gmail.com
To: Tom Lane t...@sss.pgh.pa.us
Cc: Andrew Dunstan and...@dunslane.net,
PostgreSQL-development pgsql-hackers@postgresql.org, o...@pyrenet.fr
Subject: Re: [HACKERS]
57 matches
Mail list logo
