I discover that the following declaration inside
a stored procedure with postgres7.3 was legal:
a_variable ALIAS FOR$1;
note the missing space after FOR
now is not working anymore with 7.4beta
I don't know how much people will be affected,
may be is good wrote this in the migration note.
Regar
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > if ( !ret_value ) {
> > ereport(FATAL,
> > (errcode(ERRCODE_OUT_OF_MEMORY),
> >
As suggested by Bruce Mojiman I'm working on
substitute some strdup not checked with xstrdup.
I seen that in the backend source tree there is no
xstrdup ( there is one in bin/psql tree) ,
I wrote it and inserted temporarelly in
backend/utils/mmgr/aset.c
I don't know exactly how work the error
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I found a few notices and warnings that inform you that the command you
> > are executing has no effect because the object is already in the state
you
> > want it. I think these are useless, and there is also
http://developers.slashdot.org/article.pl?sid=03/09/05/1241235&mode=thread&tid=131&tid=137&tid=189&tid=198
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> wrote:
> >> I've found a number of infelicities in the hash index code that can't
be
> >>
"Vince Vielhaber" <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2003, Shridhar Daithankar wrote:
>
> > On 2 Sep 2003 at 15:50, Czuczy Gergely wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > i'm using pgsql 7.3.4.
> > > how can I fix it? i think so, i should modify the header files, i've
trie
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> The thing that slows me down the most --- trips like FOSDEM. I am doing
> one every month or every other month. That takes 1/4 of each month.
> The threading discussion took 1/1000 of a month, but I do several
> hundred of those, so it fills up a mont
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> I've found a number of infelicities in the hash index code that can't be
> fixed without an on-disk format change. The biggest one is that the
> hashm_ntuples field in hash meta pages is only uint32, meaning that
> hash index space management will become co
I seen on this list a lot of energy ( also little flames involving SCO
& Co. ) spent on thread safety;
was really necessary spent so much energy in this direction?
I was at Fosdem in Bruxelles ( I spoke there about the use
of postgres in my project ) and I seen al people there
was really exicited
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Gaetano Mendola wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > > I see other strdup() calls that don't check on a return. Should we
deal
> > > with those too?
> >
> > Well strdup obtain the memory for the new string using a malloc
> > and nor
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > I can hardly imagine that the backend started working with 9mb of
> > memory. what did you do that PostgreSQL needed so much memory from the
> > beginning???
>
> On some platforms, "t
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote:
> Mendola Gaetano wrote:
>
> >Hi all,
> >is not usefull have a mailing list in where people can
> >partecipate in a sort of "code revision" about the
> >actual code ?
> >
> Do
Hi all,
is not usefull have a mailing list in where people can
partecipate in a sort of "code revision" about the
actual code ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Just a follow up,
is it better to give a patch for this kind of stuff ?
Regards
Gaetano Mendola
""Mendola Gaetano"" <[EMAIL PROTECTED]> wrote:
> Hi all,
> I found this code on the file variables.c and
> in the function SetVariable I read:
>
Hi all,
I found this code on the file variables.c and
in the function SetVariable I read:
if (strcmp(current->name, name) == 0)
{
free(current->value);
current->value = strdup(value);
return current->value ? true : false;
}
this mean that if there is no me
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > I noticed that some date are not anymore accepted:
> > test=# select '18/03/71'::date;
> > ERROR: invalid input syntax for date: "18/03
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Mendola Gaetano wrote:
> > Hi all,
> > I noticed that some date are not anymore accepted:
> >
> >
> > Postgres 7.3.3:
> >
> > test=# select '18/03/71'::date;
> >
Hi all,
I noticed that some date are not anymore accepted:
Postgres 7.3.3:
test=# select '18/03/71'::date;
date
1971-03-18
(1 row)
Postgres 7.4beta1:
test=# select '18/03/71'::date;
ERROR: invalid input syntax for date: "18/03/71"
is this the indendeed behaviour ?
Re
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> ERROR: table "schema"."foo" does not exist
>
> which is just plain ugly.
I think that is better for the moment this ugly message
that have lack of information.
Regards
Gaetano Mendola
---(end of broadcast)-
"Tom Lane" <[EMAIL PROTECTED]>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I got the same thing as Gaetano on my just prior to beta1 system.
>
> Well, we couldn't have fixed it since beta1 --- there's been no changes
> anywhere near SPI. I'm thinking it must be platform-dependent. What
> are
Yes.
- Original Message -
From: ""Jinqiang Han"" <[EMAIL PROTECTED]>
Newsgroups: comp.databases.postgresql.hackers
Sent: Thursday, August 07, 2003 11:26 AM
Subject: PITR in 7.4
hi, Tom and Momjian
Is PITR also delayed to 7.5?Right?
3x
Jinqiang Han
[EMAIL PROTECTED]
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> > the following code was working properly under Postgres 7.3.X
> > I'm now running my regression test with Postgres 7.4beta1 and I'm
> > having the error in subj.
>
> I tried this and got
>
> regression=# sele
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > From my perspective, we could really use a "delimiter" between the
> > "fields" of log output which is unlikely to appear within those fields
> > instead of parsing by character count, rather than making dbname a
>
From: "Tom Lane" <[EMAIL PROTECTED]>
> To forestall this scenario, I'm thinking of introducing backoff into the
> sleep intervals --- that is, after first failure to get the spinlock,
> sleep 10 msec; after the second, sleep 20 msec, then 40, etc, with a
> maximum sleep time of maybe a second. Th
Hi all,
last week ( 27/7/2003 ) I did a post with subj:
"postmaster core ( finally I have it )",
at that time I was supspecting that the core was caused by
a select on a view ( the view is always the same that cause the core )
that was running together with a vacuum; Tom Lane told me that
is reall
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > Is once-in-a-while but always at 00 minutes. This select is performed
each
> > 20 minutes and
> > the core happen always at 00 never at 20 and never at 40
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > From: "Tom Lane" <[EMAIL PROTECTED]>
> >> I suspect some form of
> >> data corruption in the pg_rewrite row(s) for this table. Do
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > The process killed made always the same select ( with different
> > id_package ):
>
> > SELECT id_publisher, publisher_name, id_package, package_nam
Hi all,
since long time ( in the mean time I did Postgres upgrade four time and
now I'm using 7.3.3 ) I'm having, at least once in a week, a signal 11 on
a backend, and how you can immagine with the subseguent drop of all
connections, finally now I have the core.
The process killed made always the
"Kenji Sugita" <[EMAIL PROTECTED]> wrote:
> =# explain select * from class1 where id = 1234;
> QUERY PLAN
> --
> Index Scan using class1_id_index on class1 (cost=0.00..3.01 rows=2
width=4)
>Inde
Hi all,
we are going to move our production postgres box ( on Linux )
in a new machine, I'm wondering if I shall leave the Hyperthreading
feature on or disable it.
Anyone have experience on this?
Thank you in advance
Gaetano
PS: Is really faster postgresql compiled with Intel compiler ?
---
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Let's start beta July 18 or that weekend. I can catch up with email by
> then, and Tom will have the elog() changes done by then too.
What about the PITR ( point in time recovery )?
I mean: the 7.4 will have PITR or not ?
Thank you in advance
Gaetan
"Hans-Jürgen Schönig" <[EMAIL PROTECTED]> wrote:
> We have used Peter's fix which makes it possible to compile PostgreSQL
> with Intel's C compiler. PostgreSQL built nicely (just some nasty
> warnings). We have tries to run our benchmark (mostly simple statements
> and cursor work) on this version
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Mendola Gaetano wrote:
> I certainly would like to see Dllist removed too.
>
> > This mean that is waste of time work on dllist.
> > I seen that exist a TODO list about "features",
> > exist a list
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > I'm improving the Dllist in these direction:
>
> AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
> and so any improvement for Dll
I'm improving the Dllist in these direction:
1) Avoid "if" statements in insertion/remove phase, for instance now the
AddHeader appear like this:
void
DLAddHead(Dllist *l, Dlelem *e)
{
Dlelem *where = l->dll_master_node->dle_next;
e->dle_next = where;
e->dle_prev = where->dle_prev;
w
>On Thursday 29 May 2003 17:41, Sander Steffann wrote:
>> Someone else has already built RPMs for RH73 and Lamar has already
uploaded
>> them to ftp.postgresql.org. I just completed the RH62 packages. Lamar
will
>> put them on the FTP server, but until then they can be picked up from
>> http://www
38 matches
Mail list logo
