On Wed, Oct 26, 2016 at 2:12 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-10-26 13:49:12 -0500, Merlin Moncure wrote:
>> On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund <andres@anarazel.de> wrote:
>> >
>> >
>> > On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure <mmoncure@gmail.com> wrote:
>> >>On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund <andres@anarazel.de>
>> >>wrote:
>> >>> Any chance that plsh or the script it executes does anything with the
>> >>file descriptors it inherits? That'd certainly one way to get into odd
>> >>corruption issues.
>> >>
>> >>not sure. it's pretty small -- see
>> >>https://github.com/petere/plsh/blob/master/plsh.c
>> >
>> > Afaics that could also be in your script, not just plsh. The later doesn't seem to close all file handles above
stderr,which means that all handles for relations etc week be open in your script. If you e.g. do any unusual
redirections(2>&17 or such), that could end badly. But I'm just on my phone, in a taxi without seatbelts, at 60mph,
soI didn't look carefully.
>>
>> gotcha :-). see above:
>> *) sqshf:
>> #!/bin/bash
>> cat \
>> $2 \
>> | eval "sqsh $1 -L'datetime=%Y-%m-%d %H:%M:%S.%u' -G 7.0"
>>
>> echo "Success"
>>
>> *) shexec:
>> #!/bin/bash
>>
>> eval $1
>>
>> FWICT that's all that's happening here with respect to pl/sh.
>
> My point is that that doesn't mean anything. Whatever sqsh is, or
> whatever $1 eval's to (and $2 for that matter), could access the
> filehandles the backend has opened.
I don't think that's the case. sqsh is a psql-like utility. it
writes to stdout and stderr only which is captured by plsh and sent.
In this context shexec only wraps rm -f 'file' where 'file' is a file
previously created with COPY in the same transaction.
In a test environment, spamming this routine with 16 threads I was not
able to reproduce. Still hunting...
merlin
