On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
I finally had time to test this further on a variety of systems, and was
unable
to reproduce on any non-Windows platform. The dump even works fine on
Windows
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian br...@momjian.us wrote:
From Tom Lane in the above thread:
Hmm. I can see how that would happen if you're using one of the Windows
environments wherein malloc's done inside libpq have to be free'd inside
On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
I finally had time to test this further on a variety of systems, and was
unable
to reproduce on any non-Windows platform. The dump even works fine on Windows
XP; just not Windows 7.
This prompted me to do a little more
I finally had time to test this further on a variety of systems, and was
unable to reproduce on any non-Windows platform. The dump even works fine
on Windows XP; just not Windows 7.
This prompted me to do a little more research, and this time I found this
thread from Sept. 2011:
On Mon, Nov 28, 2011 at 9:48 PM, Craig Ringer ring...@ringerc.id.au wrote:
Getting a usable stack trace on Windows isn't actually too hard.
The problem isn't getting the trace - I know how to do that - it's that I
don't have the pdbs for this build, and so the trace wouldn't be very
useful. I
I probably can't get a stack trace, but I was able to reproduce it with
just that function. Without the function, pg_dump works fine. I can DROP
the function, pg_dump works, then add it back again and pg_dump crashes.
Here are my steps:
initdb -A md5 --no-locale -E UTF8 -U testuser -D
David Schnur dnsch...@gmail.com writes:
I probably can't get a stack trace, but I was able to reproduce it with
just that function. Without the function, pg_dump works fine. I can DROP
the function, pg_dump works, then add it back again and pg_dump crashes.
Hmph. I still can't reproduce
On 11/29/2011 06:20 AM, David Schnur wrote:
I probably can't get a stack trace
Getting a usable stack trace on Windows isn't actually too hard. See:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
That's focused on debugging the
I'm seeing pg_dump [8.3.15 Windows] crash reproducibly against a particular
database. Searching the web, I found [
http://grokbase.com/t/postgresql.org/pgsql-general/2001/02/pg-dump-crash/06ss55h5l35jh4bnnqfigxisy534]
with
a response from Tom Lane suggesting that it was probably due to a bug in
David Schnur dnsch...@gmail.com writes:
I'm seeing pg_dump [8.3.15 Windows] crash reproducibly against a particular
database.
Can you provide a stack trace from the crash? There's some info about
that here:
Sure; the function is created programmatically as part of schema creation,
by the same user who owns (almost) everything else in the database. The
definition looks like this:
CREATE OR REPLACE FUNCTION datastore_unpack(
data_times TIMESTAMP WITH TIME ZONE[],
David Schnur dnsch...@gmail.com writes:
Sure; the function is created programmatically as part of schema creation,
by the same user who owns (almost) everything else in the database. The
definition looks like this:
CREATE OR REPLACE FUNCTION datastore_unpack(
data_times
12 matches
Mail list logo
