On Fri, 6 Mar 2009, Guillaume Smet wrote:
Date: Fri, 6 Mar 2009 18:58:58 +0100
From: Guillaume Smet
To: Tom Lane
Cc: Andrew Dunstan ,
PostgreSQL-development , o...@pyrenet.fr
Subject: Re: [HACKERS] small parallel restore optimization
On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane wrote:
Can y
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
p
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
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. Ver
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 intege
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 want
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja 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 only through s
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
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 ch
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
>
>>> "Jonah H. Harris" wrote:
> On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja 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 same names with
>> select int
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);
> }
>
> loo
> > 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
>
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja 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 only
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. M
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
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 stil
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
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 and
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
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 s
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
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
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 Herr
On Fri, Mar 6, 2009 at 1:57 PM, Tom Lane wrote:
> Bryce Cutt 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 d
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);
in
Bryce Cutt 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 updated the patc
On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane 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 to find useful i
Kedar Potdar 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, convert to string form
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()"
Andrew Dunstan 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 apply it in a day
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 e
"Andreas 'ads' Scherbaum" 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 author later regretted
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
Kedar Potdar 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 the same way they are d
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
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 pgs
ITAGAKI Takahiro píše v pá 06. 03. 2009 v 17:03 +0900:
> Hi,
>
> Robert Lor 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 impleme
Alvaro Herrera 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 you know how big this
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 22:
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
Andreas 'ads' Scherbaum 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.
This seems pretty cle
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 pgsql_psql/src
On Fri, Mar 6, 2009 at 12:01 PM, Greg Stark 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 function for this but
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
> 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 author never
> intend
On Fri, Mar 6, 2009 at 11:41 AM, Kedar Potdar 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 additional problem for
--On Freitag, März 06, 2009 11:32:14 +0100 Andreas 'ads' Scherbaum
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 return
'f' in case of inv
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 wrote:
> On Fri, Mar 6, 2009 at 10:03 AM, Kedar Potdar
> wrote:
> >
> > The aforementioned code works fine for types li
On Fri, 06 Mar 2009 10:50:41 + Gregory Stark wrote:
> Andreas 'ads' Scherbaum 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.
>
> Wel
On Fri, Mar 6, 2009 at 10:03 AM, Kedar Potdar 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
> can't read the v
Andreas 'ads' Scherbaum 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 validator function ever
On Fri, 6 Mar 2009 07:14:20 +0100 A. Kretschmer wrote:
> Nice advertisement for your book...
Actually the example is copy&paste from the .tex file ;-)
Bye
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Director
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
> 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_
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
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);
--On Freitag, März 06, 2009 02:26:12 +0100 Andreas 'ads' Scherbaum
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 the docs, this is int
Hi,
Robert Lor 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
> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01168
57 matches
Mail list logo
