Dropping schemas and "illegal seek"

[Felix Finch]

I have a perl test program which has about 80 test cases, each of
which creates its own schema so I can remove them with DROP SCHEMA xxx
CASCADE. Normally each test case creates and drops the same schema,
but it can run a mode to preserve each schema and all the disk files
for each test. I recently changed my cleanup code to run psql with
all -c commands on one command line rather than a separate psql -c for
each one ...

psql -c 'DROP SCHEMA x1 CASCADE'
psql -c 'DROP SCHEMA x2 CASCADE'
...

changed to

psql -c 'DROP SCHEMA x1 CASCADE' -c 'DROP SCHEMA x2 CASCADE' ...

and began getting this complaint from psql:

Can't drop schemas: Illegal seek

But nothing in the server log. I have set log_min_message s = warning
and maybe that accounts for it, but illegal seek sounds bad enough to
be at least a warning.

I changed it back to separate commands, and the illegal seek complant
only shows up for the last one (which is dropped). I tried adding
sleep 5 between each command, no difference.

VACUUM ANALYZE doesn't clear it. I can recreate all 80 schema and
delete them all and get the same message.

Have I hosed this database?

--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe***@crowfix.c om
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Felix Finch <fe***@crowfix. com> writes:

changed to
psql -c 'DROP SCHEMA x1 CASCADE' -c 'DROP SCHEMA x2 CASCADE' ...
AFAICT psql will only execute the last -c string if you try to specify
more than one on the command line, so the above is pretty hopeless anyway,
but
and began getting this complaint from psql:
Can't drop schemas: Illegal seek
I don't see this here. What platform is this on, and what PG version?
Have I hosed this database?

AFAICT whatever this is is local to psql's command processing, so no
your database isn't hosed.

My guess is that the "Illegal seek" message is coming from trying to
fseek stdin, but why it's trying to do that is impossible to guess
without seeing the complete command line.

Is "Can't drop schemas" coming from your script? I don't believe that
such a message text appears anywhere in psql or the backend.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Felix Finch <fe***@crowfix. com> writes:

changed to
psql -c 'DROP SCHEMA x1 CASCADE' -c 'DROP SCHEMA x2 CASCADE' ...
AFAICT psql will only execute the last -c string if you try to specify
more than one on the command line, so the above is pretty hopeless anyway,
but
and began getting this complaint from psql:
Can't drop schemas: Illegal seek
I don't see this here. What platform is this on, and what PG version?
Have I hosed this database?

AFAICT whatever this is is local to psql's command processing, so no
your database isn't hosed.

My guess is that the "Illegal seek" message is coming from trying to
fseek stdin, but why it's trying to do that is impossible to guess
without seeing the complete command line.

Is "Can't drop schemas" coming from your script? I don't believe that
such a message text appears anywhere in psql or the backend.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[felix-lists]

>>In article <16************ ***********@cro wfix.com>, Felix Finch <fe***@crowfix. com> writes:

I have a perl test program ... and began getting this complaint
from psql: Can't drop schemas: Illegal seek

Ahhh yesss... otherwise known as the subroutine not returning any
specific value and the caller expecting an error code, which explains
why adding debugging code changed it, running it under the debugger
changed it, and just about everything I did changed it, on a random
hit or miss basis.

My apologies for being too quick on the draw :-(

--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe***@crowfix.c om
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[felix-lists]

>>In article <16************ ***********@cro wfix.com>, Felix Finch <fe***@crowfix. com> writes:

I have a perl test program ... and began getting this complaint
from psql: Can't drop schemas: Illegal seek

Ahhh yesss... otherwise known as the subroutine not returning any
specific value and the caller expecting an error code, which explains
why adding debugging code changed it, running it under the debugger
changed it, and just about everything I did changed it, on a random
hit or miss basis.

My apologies for being too quick on the draw :-(

--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe***@crowfix.c om
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly