Skip site navigation (1) Skip section navigation (2)

Re: I'm amazed we never caught this before ...

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: I'm amazed we never caught this before ...
Date: 2001-01-07 00:02:36
Message-ID: Pine.BSF.4.31.0101062001390.18110-100000@thelab.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, 6 Jan 2001, Tom Lane wrote:

> The stringToNode routines (backend/nodes/read.c and readfuncs.c) depend
> on a static variable that is the next-input pointer for lsptok().
>
> Guess what happens if stringToNode is invoked recursively.  (Hint:
> it's not good.)
>
> It's apparently not easy for this to happen, but I have a reproducible
> test case involving relcache flush while reading the rule action
> parsetree for a view.  readDatum() needs to be able to look up the
> pg_type entry for the value it's reading, and that lookup could result
> in relcache flush, which would lead to an attempt to read the rule
> actions for any locked relcache entries --- like, say, the one we
> are currently trying to load.
>
> I propose fixing this by making stringToNode save and restore the
> entry-time value of the static pointer.  (Alternatively, we could
> explicitly pass a pointer-to-pointer-to-char to lsptok() and every
> single one of the readfuncs, but that seems like way too much
> notational clutter.)
>
> I am not sure that is enough to fix the problem completely.  It might
> be best to avoid calling get_typbyval() from readDatum, which could
> be done if we re-ordered the fields of a CONST dump so that the byval
> field appears before we need to read the const value itself.  That
> means an initdb, but we've already forced an initdb for beta2 ...
>
> Marc, can you hold off wrapping beta2 for a few hours?  I think this
> is a 'must fix'.

No probs ... I got the update to mk-release from Peter, so let me know
when you are ready and we'll go with beta2 ...



In response to

Responses

pgsql-hackers by date

Next:From: bpalmerDate: 2001-01-07 00:42:36
Subject: Re: CVS regression test failure on OBSD
Previous:From: Tom LaneDate: 2001-01-06 23:59:21
Subject: I'm amazed we never caught this before ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group