[BUGS] Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory
A. Hackmann ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory Long Description Hi, I'm loading aprrox. 20GB into a Postgresql 7.3.2 db (using COPY command). Copying works fine, but when I tried to create indices, I get the error message above. Postmaster is running under Red Hat Linux 7.1 on a dual Xeon machine having 2GB RAM. 1 GB ist reserved for shared memory, where 600Mb is used for this particular db instance. I changed wlog parameters, but this had no effect. Source has been compilied on gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85). Thanks, Andre. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Postgresql 7.3.2 Crash
Stephan Szabo <[EMAIL PROTECTED]> writes: > That's because the set default uses a pretty ugly hack. It plans the > query with =NULL and then replaces the NULL with the default value's > stored plan info. My first guess is that it's something with this that's > causing the crash. Yeah, it's failing to allow for the possible need to insert a type coercion step. This code shouldn't be here at all, really --- it should be using build_column_default instead of messing about with the default expression directly. I can fix it, unless you want to... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Postgresql 7.3.2 Crash
On Thu, 27 Mar 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > That's because the set default uses a pretty ugly hack. It plans the > > query with =NULL and then replaces the NULL with the default value's > > stored plan info. My first guess is that it's something with this that's > > causing the crash. > > Yeah, it's failing to allow for the possible need to insert a type > coercion step. This code shouldn't be here at all, really --- it should > be using build_column_default instead of messing about with the > default expression directly. I can fix it, unless you want to... Either way works for me. :) I'd guess it should look more like the default inserting stuff in copy for getting the expression's value. Doesn't look too hard to change (might take me a couple of days due to work, but I don't think that'll be a big issue). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Postgresql 7.3.2 Crash
Stephan Szabo <[EMAIL PROTECTED]> writes: > Either way works for me. :) I'd guess it should look more like the default > inserting stuff in copy for getting the expression's value. Doesn't look > too hard to change (might take me a couple of days due to work, but I > don't think that'll be a big issue). Sounds like you're busy -- I'll take care of it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Postgresql 7.3.2 Crash
Stephan Szabo <[EMAIL PROTECTED]> writes:
> That's because the set default uses a pretty ugly hack. It plans the
> query with =NULL and then replaces the NULL with the default value's
> stored plan info. My first guess is that it's something with this that's
> causing the crash.
I've applied the attached patch (for 7.3, cvs tip is a bit different)
to fix this problem.
regards, tom lane
*** src/backend/utils/adt/ri_triggers.c.origThu Oct 3 17:06:23 2002
--- src/backend/utils/adt/ri_triggers.c Thu Mar 27 11:28:36 2003
***
*** 35,41
--- 35,43
#include "catalog/pg_operator.h"
#include "commands/trigger.h"
#include "executor/spi_priv.h"
+ #include "optimizer/planmain.h"
#include "parser/parse_oper.h"
+ #include "rewrite/rewriteHandler.h"
#include "utils/lsyscache.h"
#include "miscadmin.h"
***
*** 2672,2681
const char *qualsep;
Oid queryoids[RI_MAX_NUMKEYS];
Plan *spi_plan;
! AttrDefault *defval;
! TargetEntry *spi_qptle;
! int i,
! j;
/* --
* The query string built is
--- 2674,2681
const char *qualsep;
Oid queryoids[RI_MAX_NUMKEYS];
Plan *spi_plan;
! int i;
! List *l;
/* --
* The query string built is
***
*** 2712,2755
*/
qplan = SPI_prepare(querystr, qkey.nkeypairs,
queryoids);
! /* --
!* Here now follows very ugly code depending on
internals
!* of the SPI manager.
!*
!* EVIL EVIL EVIL (but must be - Jan)
*
!* We replace the CONST NULL targetlist expressions
!* in the generated plan by (any) default values found
!* in the tuple constructor.
!* --
*/
spi_plan = (Plan *) lfirst(((_SPI_plan *)
qplan)->ptlist);
! if (fk_rel->rd_att->constr != NULL)
! defval = fk_rel->rd_att->constr->defval;
! else
! defval = NULL;
! for (i = 0; i < qkey.nkeypairs && defval != NULL; i++)
{
! /*
!* For each key attribute lookup the tuple
constructor
!* for a corresponding default value
!*/
! for (j = 0; j <
fk_rel->rd_att->constr->num_defval; j++)
! {
! if (defval[j].adnum ==
!
qkey.keypair[i][RI_KEYPAIR_FK_IDX])
! {
! /*
!* That's the one - push the
expression from
!* defval.adbin into the
plan's targetlist
!*/
! spi_qptle = (TargetEntry *)
! nth(defval[j].adnum -
1,
!
spi_plan->targetlist);
! spi_qptle->expr =
stringToNode(defval[j].adbin);
! break;
! }
}
}
}
--- 2712,2742
*/
qplan = SPI_prepare(querystr, qkey.nkeypairs,
queryoids);
! /*
!* Scan the plan's targetlist and replace the NULLs by
!* appropriate column defaults, if any (if not,
Re: [BUGS] Solution for bug #899
Patch applied. Thanks.
---
Laurent FAILLIE wrote:
> Hello Bruce,
>
> there is a contextual diff of my patch w/ the current
> (I hope) snapshot of postgresql.
>
> I test it on my own database, but I found another bug
> w/ SEQUENCE this time. I have created a new ticket,
> #918 for this as it's totaly a separate problem.
>
> Bye
>
> Laurent
>
> --
>
> *** pg_dump.c.org Tue Mar 25 10:33:01 2003
> --- pg_dump.c Tue Mar 25 11:42:17 2003
> ***
> *** 605,610
> --- 605,618
>
> /* Now sort the output nicely */
> SortTocByOID(g_fout);
> +
> + /*
> + * Procedural languages have to be declared just
> after
> + * database and schema creation, before they are
> used.
> + */
> + MoveToStart(g_fout, "ACL LANGUAGE");
> + MoveToStart(g_fout, "PROCEDURAL LANGUAGE");
> + MoveToStart(g_fout, "FUNC PROCEDURAL LANGUAGE");
> MoveToStart(g_fout, "SCHEMA");
> MoveToStart(g_fout, "DATABASE");
> MoveToEnd(g_fout, "TABLE DATA");
> ***
> *** 3626,3632
> {
> char *tmp = strdup(fmtId(lanname));
>
> ! dumpACL(fout, "LANGUAGE", tmp, lanname,
> finfo[fidx].pronamespace->nspname,
> NULL, lanacl, lanoid);
> free(tmp);
> --- 3634,3640
> {
> char *tmp = strdup(fmtId(lanname));
>
> ! dumpACL(fout, "ACL LANGUAGE", tmp, lanname,
> finfo[fidx].pronamespace->nspname,
> NULL, lanacl, lanoid);
> free(tmp);
> ***
> *** 3732,3737
> --- 3740,3746
> char *prosecdef;
> char *lanname;
> char *rettypename;
> + char *funcproclang; /* Boolean : is this
> function a PLang handler ? */
>
> if (finfo->dumped)
> goto done;
> ***
> *** 3747,3753
> appendPQExpBuffer(query,
> "SELECT proretset, prosrc, probin, "
> "provolatile, proisstrict,
> prosecdef, "
> ! "(SELECT lanname FROM
> pg_catalog.pg_language
> WHERE oid = prolang) as lanname "
> "FROM pg_catalog.pg_proc "
> "WHERE oid = '%s'::pg_catalog.oid",
> finfo->oid);
> --- 3756,3763
> appendPQExpBuffer(query,
> "SELECT proretset, prosrc, probin, "
> "provolatile, proisstrict,
> prosecdef, "
> ! "(SELECT lanname FROM
> pg_catalog.pg_language
> WHERE oid = prolang) as lanname, "
> ! "exists (SELECT 'x' FROM
> pg_catalog.pg_language WHERE lanplcallfoid =
> pg_catalog.pg_proc.oid) as funcproclang "
> "FROM pg_catalog.pg_proc "
> "WHERE oid = '%s'::pg_catalog.oid",
> finfo->oid);
> ***
> *** 3759,3765
>"case when proiscachable then 'i' else 'v' end as
> provolatile, "
> "proisstrict, "
> "'f'::boolean as prosecdef, "
> ! "(SELECT lanname FROM pg_language
> WHERE oid
> = prolang) as lanname "
> "FROM pg_proc "
> "WHERE oid = '%s'::oid",
> finfo->oid);
> --- 3769,3776
>"case when proiscachable then 'i' else 'v' end as
> provolatile, "
> "proisstrict, "
> "'f'::boolean as prosecdef, "
> ! "(SELECT lanname FROM pg_language
> WHERE oid
> = prolang) as lanname, "
> ! "exists (SELECT 'x' FROM pg_language
> WHERE
> lanplcallfoid = pg_proc.oid) as funcproclang "
> "FROM pg_proc "
> "WHERE oid = '%s'::oid",
> finfo->oid);
> ***
> *** 3771,3777
>"case when proiscachable then 'i' else 'v' end as
> provolatile, "
>
Re: [BUGS] Bug #918: pg_dump problem w/ SEQUENCE
It's my bad. Has to do with the sequence having the default value and *NOT* having been called. See -patches for update to simply skip START WITH in that case. On Tue, 2003-03-25 at 10:08, Bruce Momjian wrote: > I just did 'CREATE SEQUENCE x' and pg_dump produced: > > CREATE SEQUENCE x > START WITH 1 > INCREMENT BY 1 > NO MAXVALUE > NO MINVALUE > CACHE 1; > > which has the proper value after START WITH. Any ideas why your setup > is different? > > --- > > [EMAIL PROTECTED] wrote: > > laurent faillie ([EMAIL PROTECTED]) reports a bug with a severity of 2 > > The lower the number the more severe it is. > > > > Short Description > > pg_dump problem w/ SEQUENCE > > > > Long Description > > Hi all, > > > > in order to correct bug #899, I have downloaded the current snapshot and I > > discover a new trouble w/ pg_dump. > > > > If you have a sequence in your database, pg_dump produce something like : > > > > CREATE SEQUENCE seq_id_fch > > START WITH > > INCREMENT BY 1 > > MAXVALUE 2147483647 > > NO MINVALUE > > CACHE 1; > > > > and psql rise following error : > > > > ERROR: parser: parse error at or near "WITH" at character 38 > > > > PS: I have downloaded the snapshot monday 24/03/2003 > > > > Bye > > > > Laurent > > > > > > Sample Code > > > > > > No file was uploaded with this report > > > > > > ---(end of broadcast)--- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faqs/FAQ.html > > -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [BUGS] Solution for bug #899
Bruce Momjian <[EMAIL PROTECTED]> writes: > Patch applied. Thanks. Did you do anything to address my complaints about this patch? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Solution for bug #899
>Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
>
> Did you do anything to address my complaints about this patch?
Yes. It is a new version of the patch, with comments in each section.
I am attaching the patch --- any other changes?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Hello Bruce,
there is a contextual diff of my patch w/ the current
(I hope) snapshot of postgresql.
I test it on my own database, but I found another bug
w/ SEQUENCE this time. I have created a new ticket,
#918 for this as it's totaly a separate problem.
Bye
Laurent
--
*** pg_dump.c.org Tue Mar 25 10:33:01 2003
--- pg_dump.c Tue Mar 25 11:42:17 2003
***
*** 605,610
--- 605,618
/* Now sort the output nicely */
SortTocByOID(g_fout);
+
+ /*
+* Procedural languages have to be declared just after
+* database and schema creation, before they are used.
+*/
+ MoveToStart(g_fout, "ACL LANGUAGE");
+ MoveToStart(g_fout, "PROCEDURAL LANGUAGE");
+ MoveToStart(g_fout, "FUNC PROCEDURAL LANGUAGE");
MoveToStart(g_fout, "SCHEMA");
MoveToStart(g_fout, "DATABASE");
MoveToEnd(g_fout, "TABLE DATA");
***
*** 3626,3632
{
char *tmp = strdup(fmtId(lanname));
! dumpACL(fout, "LANGUAGE", tmp, lanname,
finfo[fidx].pronamespace->nspname,
NULL, lanacl, lanoid);
free(tmp);
--- 3634,3640
{
char *tmp = strdup(fmtId(lanname));
! dumpACL(fout, "ACL LANGUAGE", tmp, lanname,
finfo[fidx].pronamespace->nspname,
NULL, lanacl, lanoid);
free(tmp);
***
*** 3732,3737
--- 3740,3746
char *prosecdef;
char *lanname;
char *rettypename;
+ char *funcproclang; /* Boolean : is this function a PLang handler
? */
if (finfo->dumped)
goto done;
***
*** 3747,3753
appendPQExpBuffer(query,
"SELECT proretset, prosrc, probin, "
"provolatile, proisstrict,
prosecdef, "
! "(SELECT lanname FROM
pg_catalog.pg_language WHERE oid = prolang) as lanname "
"FROM pg_catalog.pg_proc "
"WHERE oid = '%s'::pg_catalog.oid",
finfo->oid);
--- 3756,3763
appendPQExpBuffer(query,
"SELECT proretset, prosrc, probin, "
"provolatile, proisstrict,
prosecdef, "
! "(SELECT lanname FROM
pg_catalog.pg_language WHERE oid = prolang) as lanname, "
! "exists (SELECT 'x' FROM
pg_catalog.pg_language WHERE lanplcallfoid = pg_catalog.pg_proc.oid) as funcproclang "
"FROM pg_catalog.pg_proc "
"WHERE oid = '%s'::pg_catalog.oid",
finfo->oid);
***
*** 3759,3765
"case when proiscachable then 'i' else 'v' end as provolatile, "
"proisstrict, "
"'f'::boolean as prosecdef, "
! "(SELECT lanname FROM pg_language
WHERE oid = prolang) as lanname "
"FROM pg_proc "
"WHERE oid = '%s'::oid",
finfo->oid);
--- 3769,3776
"case when proiscachable then 'i' else 'v' end as provolatile, "
"proisstrict, "
"'f'::boolean as prosecdef, "
! "(SELECT lanname FROM pg_language
WHERE oid = prolang) as lanname, "
! "exists (SELECT 'x' FROM pg_language
WHERE lanplcallfoid = pg_proc.oid) as funcproclang "
