Hi,
Kevin: CCed you, because it doesn't really look like a logical decoding
related issue.
On 2014-11-17 11:25:40 -0500, Steve Singer wrote:
> On 11/17/2014 10:37 AM, Andres Freund wrote:
> >On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
> >
> >
> >Also since updating (to 2c267e47afa4f9a7c) I've seen a assertion failure in
> >a normal client connection, not the walsender
> >
> >#3 0x00000000006b4978 in GetSerializableTransactionSnapshotInt (
> > snapshot=snapshot@entry=0xbfa8a0 <CurrentSnapshotData>,
> > sourcexid=sourcexid@entry=0) at predicate.c:1738
> >#4 0x00000000006b66c3 in GetSafeSnapshot (origSnapshot=<optimized out>)
> > at predicate.c:1517
> >#5 GetSerializableTransactionSnapshot (
> > snapshot=0xbfa8a0 <CurrentSnapshotData>) at predicate.c:1598
> >#6 0x00000000007d16dd in GetTransactionSnapshot () at snapmgr.c:200
> >#7 0x00000000006c0e35 in exec_simple_query (
> > query_string=0x1fd01b8 "select ev_origin, ev_seqno, ev_timestamp,
> >ev_snapshot, \"pg_catalog\".txid_snapshot_xmin(ev_snapshot),
> >\"pg_catalog\".txid_snapshot_xmax(ev_snapshot),
> >coalesce(ev_provider_xid,\""...)
> > at postgres.c:959
> >#8 PostgresMain (argc=<optimized out>, argv=argv@entry=0x1f5ab50,
> >
> >
> >I have no idea if this has anything to do with your recent changes or some
> >other change. I haven't so far been able to replicate that since the first
> >time I saw it.
> >That crash is decidedly odd. Any chance you still have the full
> >backtrace around?
>
> Yes I still have the core file
Cool, could you show the full thing? Or did you just snip it because
it's just the Assert/ExceptionalCondition thing?
Could you print *snapshot in frame #3?
> >
> >This is in the SSI code... I'm not immediately seeing how this could be
> >related to logical decoding. It can't even be a imported snapshot,
> >because the exported snapshot is marked repeatable read.
> >
> >Are you actually using serializable transactions? If so, how and why?
>
> Yes, the test client that performs the 'simulated workload' does some
> serializable transactions. It connects as a normal client via JDBC and does
> a prepareStatement("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE") and then
> does some DML. Why? because it seemed like a good thing to include in the
> test suite.
Yes, it's a good reason as the above backtrace proves ;). I'm just
trying to understand uner which circumstances it happens.
The above backtrace looks like it can only be triggered if you do a
BEGIN TRANSACTION SERIALIZABLE DEFERRABLE READ ONLY; Is that something
you do?
> Your right this might have nothing to do with logical decoding. I haven't
> been able to reproduce again either, I can't even say
> if this problem was introduced to 9.4 in the past month or if it has been
> around much longer and I just haven't hit it before.
It's not hard to imagine that the safe/deferred snapshot code isn't all
that well exercised. I don't think many people use it yet.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
