| Bug #37012 | Online backup: Can't backup to a pipe. | ||
|---|---|---|---|
| Submitted: | 27 May 2008 19:18 | Modified: | 13 Jan 17:29 |
| Reporter: | Priyesh Narayanan | ||
| Status: | Closed | ||
| Category: | Server: Backup | Severity: | S3 (Non-critical) |
| Version: | 6.0.5 alpha, 6.0-backup BK | OS: | Any |
| Assigned to: | Target Version: | ||
| Triage: | D3 (Medium) | ||
[27 May 2008 19:18]
Priyesh Narayanan
[27 May 2008 20:42]
Sveta Smirnova
Thank you for the report. Verified as described.
[10 Jun 2008 12:23]
Lars Thalmann
On Tue, May 27, 2008 at 12:02:29PM -0600, Peter Gulutzan wrote: > On Tue, 2008-05-27 at 08:46 +0200, Lars Thalmann wrote: > > Peter, what should the option be called? > > As I understand the request: > > The user wants to backup to a named pipe. > The user does not want to restore from a named pipe. > The user does not want LOCAL, i.e. backup on client machine. > > One way is to allow writing even if something exists; > BACKUP DATABASE d TO '' [ OVERWRITE | APPEND ]; > That would be convenient anyway, when re-using obsolete files. > But I think it's insecure. Users with FILE and BACKUP > privileges could overwrite interesting things. > > So I think it's better to change nothing in the syntax, > but just say "allow writing if 'file' is a named pipe". > The most generic way to find out, I think, is to check > if file size = 0. In that case, we don't have to call > the option anything. > > This probably won't work with "parallel" backup feature. > > I do not know what should happen if the server starts with > --chroot=path, -r path > http://dev.mysql.com/doc/refman/5.0/en/server-options.html > > FYI, > Microsoft dropped named-pipes (Windows) support in 2005: > "For security reasons, SQL Server does not support backup to named > pipes." > http://msdn.microsoft.com/en-us/library/ms144262.aspx > But DB2 still allows it on Unix > http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad... Sounds ok. Don't change syntax, but do allow append without error to a zero-sized file.
[19 Jun 2008 16:15]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/48179 2638 Sergey Vojtovich 2008-06-19 BUG#37012 - Online backup: Can't backup to a pipe. It was impossible to backup to a pipe. Backup code refuse to overwrite existing files no matter if they're regular files or named pipes. This fix allows to write backup image to existing named pipe.
[29 Jun 2008 8:57]
Oystein Grovlen
Approved, given that the m_flags issue is resolved according to what Rafal and I agreed upon.
[1 Jul 2008 15:13]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/48806 2641 Sergey Vojtovich 2008-07-01 BUG#37012 - Online backup: Can't backup to a pipe. It was impossible to backup to a pipe. Backup code refuse to overwrite existing files no matter if they're regular files or named pipes. This fix allows to write backup image to existing named pipe. No test case for this fix, as currently there is no good way in our test suite to determine if OS supports named pipes.
[5 Aug 2008 19:02]
Sergey Vojtovich
Was pushed to 6.0.6.
[5 Aug 2008 19:52]
Paul DuBois
Noted in 6.0.6 changelog. On Unix, it is now possible for the output file for BACKUP DATABASE to be an existing FIFO.
[14 Sep 2008 4:32]
Bugs System
Pushed into 6.0.6-alpha (revid:svoj@mysql.com-20080701131203-hhtex74pkzs4qiio) (version source revid:hakan@mysql.com-20080716160135-l7310heud233kagu) (pib:3)
[3 Jan 20:28]
Tomas Dalebjörk
I have exactly the same symptom, but in my example; it was a windows system. I run: Server version: 6.0.8-alpha-community MySQL Community Server (GPL) I am not sure if this fix has been applied to this version as well...
[13 Jan 17:29]
Susanne Ebrecht
Many thanks for your feedback. I tested with our actual bzr source release to make sure that we don't have a regression here. All works fine and we could exclude a regression here at the moment.
