Re: Backup to Tape Incomplete - Mailing list pgsql-admin

From Phillip Smith
Subject Re: Backup to Tape Incomplete
Date
Msg-id 02e901c879b2$18ee0210$9b0014ac@wbaus090
Whole thread Raw
In response to Re: Backup to Tape Incomplete  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> > I wonder what it's meaning by invalid arg?
>
> On my Fedora machine, "man write" explains EINVAL thusly:
>
>        EINVAL fd  is attached to an object which is unsuitable for
writing; or
>               the file was opened with  the  O_DIRECT  flag,  and  either
the
>               address  specified  in buf, the value specified in count, or
the
>               current file offset is not suitably aligned.
>
> I'm not sure that writing to a tape is quite like O_DIRECT, but the
mention of
> an un-aligned count seems pretty relevant.  If you grant the assumption
that
> the underlying problem is that the tape drive has to be written to in
> multiples of its blocksize, then this supports the idea that a violation
of
> that rule would be reported as EINVAL.

Interesting... If I set the block-size to 32, everything goes without any
error,
But not ending with "PostgreSQL database dump complete":

[postgres@stirling ~]$ mt setblk 32
[postgres@stirling ~]$ mt stat
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 32 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
[postgres@stirling ~]$ pg_dump dbname > /dev/st0
[postgres@stirling ~]$ tail - < /dev/st0
REVOKE ALL ON TABLE stock_test FROM dbuser;
GRANT ALL ON TABLE stock_test TO dbuser;
GRANT ALL ON TABLE stock_test TO PUBLIC;


--
-- Name: stores; Type: ACL; Schema: public; Owner: dbuser
--

[postgres@stirling ~]$


If I set the block-size to 0... Well it's really not happy:

[postgres@stirling ~]$ mt setblk 0
[postgres@stirling ~]$ mt stat
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
[postgres@stirling ~]$ pg_dump dbname > /dev/st0
[postgres@stirling ~]$ tail - < /dev/st0
tail: error reading `standard input': Cannot allocate memory
[postgres@stirling ~]$ cat /dev/st0 > /tmp/test-restore.sql
cat: /dev/st0: Cannot allocate memory
[postgres@stirling ~]$


THINK BEFORE YOU PRINT - Save paper if you don't really need to print this

*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to
the addressee.  If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments
e-mail.

pgsql-admin by date:

Previous
From: "Tena Sakai"
Date:
Subject: Re: trouble with pg_dumpall
Next
From: "Phillip Smith"
Date:
Subject: Re: trouble with pg_dumpall