On Wed, Mar 29, 2017 at 12:40 PM, Vaishnavi Prabakaran <vaishnaviprabaka...@gmail.com> wrote: > Michael Paquier wrote: >>Could you as well update src/tools/msvc/vcregress.pl, aka the routine >>modulescheck so as this new test is skipped. I am sure that nobody >>will scream if this test is not run on Windows, but the buildfarm will >>complain if the patch is let in its current state. > > Thanks for the finding. Hmm, modulescheck will not pick up test_libpq as > "subdircheck" will fail for this module(because it does not have > "sql"/"expected" folders in it) and hence it will be skipped. > But, Modified "Mkvcbuild.pm" to exclude "test_libpq" module, as this test > anyways will not be run in Windows and also because it uses linux specific > APIs(gettimeofday , timersub).
src/port/gettimeofday.c extends things on Windows, and we could consider to just drop the timing portion for simplicity (except Windows I am not seeing any platform missing timersub). But that's just a point of detail. Or we could just drop those tests from the final patch, and re-implement them after having some psql-level subcommands. That would far better for portability. > There are 2 cases tested here: > > 1. Example for the case - Using COPY command in batch mode will trigger > failure. (Specified in documentation) > Failure can be seen only when processing the copy command's results. That > is, after dispatching COPY command, server goes into COPY state , but the > client dispatched another query in batch mode. > > Below error messages belongs to this case : > Error status and message got from server due to COPY command failure are : > PGRES_FATAL_ERROR ERROR: unexpected message type 0x50 during COPY from > stdin > CONTEXT: COPY batch_demo, line 1 > > message type 0x5a arrived from server while idle Such messages are really confusing to the user as they refer to the protocol going out of sync. I would think that something like "cannot process COPY results during a batch processing" would be cleaner. Isn't some more error handling necessary in GetCopyStart()? > Attached the latest code and test patches. For me the test is still broken: ok 1 - testlibpqbatch disallowed_in_batch ok 2 - testlibpqbatch simple_batch ok 3 - testlibpqbatch multi_batch ok 4 - testlibpqbatch batch_abort ok 5 - testlibpqbatch timings not ok 6 - testlibpqbatch copyfailure Still broken here. I can see that this patch is having enough safeguards in PQbatchBegin() and PQsendQueryStart(), but this issue is really pointing out at something... -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
