Re: [HACKERS] Error attribution in foreign scans
On Wed, Feb 09, 2011 at 10:55:05AM +0900, Itagaki Takahiro wrote: On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On Mon, Feb 7, 2011 at 21:17, Noah Misch n...@leadboat.com wrote: The message does not show which foreign table yielded the error. ??We could evade the problem in this case by adding a file name to the error message in the COPY code, Yeah, an error context callback like that makes sense. In the case of the file FDW, though, just including the filename in the error message seems even better. Especially if the error is directly related to failure in reading the file. What do you think about filenames in terms of security? We will allow non-superusers to use existing foreign tables of file_fdw. For reference, we hide some path settings in GUC variables. Comprehensively hiding the name from non-superusers is ideal, but it seems adequate to document that the name will not be kept secret. The superuser could always mask the name by creating a symbolic link in $PGDATA and referencing that in the foreign table configuration. We also reconsider privilege of fdwoptions, umoptions, etc. They could contain password or server-side path, but all users can retrieve the values. It's an existing issue, but will be more serious in 9.1. This would be good to get right by 9.1 (not sure what right is, though). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Error attribution in foreign scans
On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On Mon, Feb 7, 2011 at 21:17, Noah Misch n...@leadboat.com wrote: The message does not show which foreign table yielded the error. We could evade the problem in this case by adding a file name to the error message in the COPY code, Yeah, an error context callback like that makes sense. In the case of the file FDW, though, just including the filename in the error message seems even better. Especially if the error is directly related to failure in reading the file. What do you think about filenames in terms of security? We will allow non-superusers to use existing foreign tables of file_fdw. For reference, we hide some path settings in GUC variables. We also reconsider privilege of fdwoptions, umoptions, etc. They could contain password or server-side path, but all users can retrieve the values. It's an existing issue, but will be more serious in 9.1. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Error attribution in foreign scans
Suppose you create several file_fdw foreign tables, query them together, and read(2) returns EIO for one of the files: [local] postgres=# SELECT * FROM ft0, ft1, ft2; ERROR: could not read from COPY file: Input/output error The message does not show which foreign table yielded the error. We could evade the problem in this case by adding a file name to the error message in the COPY code, but that strategy doesn't translate to twitter_fdw, firebird_fdw, etc. We need a convention for presenting foreign errors that clearly attributes them to the originating foreign table. What should it be? Perhaps something as simple as having the core foreign scan code push an error context callback that does errcontext(scan of foreign table \%s\, tabname)? Disclaimer: I have only skimmed SQL/MED patches other than copy_export. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Error attribution in foreign scans
On 07.02.2011 14:17, Noah Misch wrote: Suppose you create several file_fdw foreign tables, query them together, and read(2) returns EIO for one of the files: [local] postgres=# SELECT * FROM ft0, ft1, ft2; ERROR: could not read from COPY file: Input/output error The message does not show which foreign table yielded the error. We could evade the problem in this case by adding a file name to the error message in the COPY code, but that strategy doesn't translate to twitter_fdw, firebird_fdw, etc. We need a convention for presenting foreign errors that clearly attributes them to the originating foreign table. What should it be? Perhaps something as simple as having the core foreign scan code push an error context callback that does errcontext(scan of foreign table \%s\, tabname)? Yeah, an error context callback like that makes sense. In the case of the file FDW, though, just including the filename in the error message seems even better. Especially if the error is directly related to failure in reading the file. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
