From: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kevin(dot)grittner(at)enterprisedb(dot)com> |
Subject: | Re: REFRESH MATERIALIZED VIEW command in PL block hitting Assert |
Date: | 2013-04-24 12:34:19 |
Message-ID: | CAM2+6=VFgBDNFpcdWGBToQrqNVk6HzXEuED+nJK3tK+wPtMJOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 24, 2013 at 3:04 AM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> wrote:
> > On Mon, Apr 22, 2013 at 6:41 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
> wrote:
> >> On 2013-04-22 18:35:04 +0530, Jeevan Chalke wrote:
>
> >>> I have observed that following sequence is causing server crash.
> >>>
> >>> CREATE MATERIALIZED VIEW temp_class_mv AS
> >>> SELECT * FROM pg_class
> >>> WITH NO DATA;
> >>>
> >>> CREATE OR REPLACE FUNCTION test_refresh_mv()
> >>> RETURNS int
> >>> AS $$
> >>> BEGIN
> >>> REFRESH MATERIALIZED VIEW temp_class_mv;
> >>> return 1;
> >>> END; $$ LANGUAGE plpgsql;
> >>>
> >>> SELECT test_refresh_mv();
> >>>
> >>>
> >>> I had a quick look over the crash and it is hitting following Assert in
> >>> spi.c:
> >>>
> >>> else if (IsA(stmt, RefreshMatViewStmt))
> >>> {
> >>> Assert(strncmp(completionTag,
> >>> "REFRESH MATERIALIZED VIEW ", 23)
> == 0);
> >>> _SPI_current->processed = strtoul(completionTag +
> 23,
> >>> NULL, 10);
> >>> }
> >>>
> >>> It seems like we are missing expected value for completionTag in
> >>> ExecRefreshMatView()
>
> >> Possibly independent from this issue, but where did that 23 come from?
>
> When the consensus developed to change the syntax from LOAD
> MATERIALIZED VIEW I failed to noticed the length here when making
> the changes for that.
>
> > BTW, attached is the patch which works well for me, but need details
> review.
>
> I suggest that we just rip out this section of code. Trying to
> provide a number here is probably all wrong, anyway. As the
> features evolve, there may not be a readily accessible rowcount for
> this command in all cases.
>
OK.
>
> Any objections to the attached to fix this issue?
>
Nope. Fine with me.
Thanks
>
> --
> Kevin Grittner
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Jeevan B Chalke
Senior Software Engineer, R&D
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Phone: +91 20 30589500
Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb
This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-04-24 13:24:50 | Re: high io BUT huge amount of free memory |
Previous Message | Fabrízio de Royes Mello | 2013-04-24 12:04:04 | Re: Proposal to add --single-row to psql |