Re: BUG #6411: Backend process' crash when a foreign table is used in a dependent subquery on select clause

On 26.01.2012 14:46, emre(dot)hasegeli(at)tart(dot)com(dot)tr wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6411
> Logged by: Using a Foreign Table in a Dependent Subquery
> Email address: emre(dot)hasegeli(at)tart(dot)com(dot)tr
> PostgreSQL version: 9.1.2
> Operating system: Linux 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 2
> Description:
>
> I installed Dave Page's MySQL Foreign Data Wrapper on GitHub [1]. It works
> fine until foreign table is used in a dependent subquery on select clause.

This mailing list is really for bugs in PostgreSQL itself, but I'll give
this a shot...

> How to reproduce:
>
> Create extension mysql_fdw;
>
> Create server AMySQLServer
> foreign data wrapper mysql_fdw
> options (address '***', port '3306');
>
> Create user mapping for public
> server AMySQLServer
> options (username '***', password '***');
>
> Create foreign table AForeignTable (id integer) server AMySQLServer options
> (query 'Select id from ASchema.ATable');
>
> Select id, (select true from AForeignTable where AForeignTable.id =
> ATable.id) from ATable;
>
> WARNING: 57P02: terminating connection because of crash of another server
> process
> DETAIL: The postmaster has commanded this server process to roll back the
> current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT: In a moment you should be able to reconnect to the database and
> repeat your command.
>
> [1] https://github.com/dpage/mysql_fdw

I'm guessing that there's mysql_fdw's rescan function isn't working
correctly. Looking at the source, it seems to be calling
"mysql_row_seek(festate->result, 0);". But according to MySQL's docs
[1], that 2nd argument should be an opaque value returned by
mysql_row_tell() or mysql_row_seek(), not a row number. I think
mysql_data_seek should be used there instead of mysql_row_seek().

That said, I have no idea if that's causing the crash.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com