On 5/18/15 12:15 PM, Andrew Dunstan wrote:
On 05/18/2015 01:05 PM, Tom Lane wrote:
Meh. You could also add "select pg_backend_pid()" or some such.
But really, the way I generally do this is to run gdb via a script
that auto-attaches to the right postgres process if at all possible.
Removes the
On Mon, May 18, 2015 at 6:44 AM, Tom Lane wrote:
> Peter Geoghegan writes:
>> I came up with a simple approach to conveniently attaching a debugger
>> when a bug manifested itself from within the regression tests, by
>> patching Postgres. This worked quite well. The backend would look for
>> the
On 05/18/2015 01:05 PM, Tom Lane wrote:
Meh. You could also add "select pg_backend_pid()" or some such.
But really, the way I generally do this is to run gdb via a script
that auto-attaches to the right postgres process if at all possible.
Removes the whole problem.
This should go on the wik
Jim Nasby writes:
> On 5/18/15 8:44 AM, Tom Lane wrote:
>> If your approach involves modifying a target query in a regression test,
>> it really seems unnecessary to do all this. Just insert something like
>> "select pg_sleep(60)" into the test script before the target query.
>>
>> A variant is
On 5/18/15 8:44 AM, Tom Lane wrote:
Peter Geoghegan writes:
I came up with a simple approach to conveniently attaching a debugger
when a bug manifested itself from within the regression tests, by
patching Postgres. This worked quite well. The backend would look for
the occurrence of a magical t
Peter Geoghegan writes:
> I came up with a simple approach to conveniently attaching a debugger
> when a bug manifested itself from within the regression tests, by
> patching Postgres. This worked quite well. The backend would look for
> the occurrence of a magical token within each and every quer
During the course of UPSERT's development, I found it tricky to debug
regression tests failures on occasion. There are often non-obvious
dependencies across and within regression tests. Creating a minimal
test case having attached a debugger to a directly controlled backend
is often tricky, or at l
