| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dave Cramer <davecramer(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Binary support for pgoutput plugin |
| Date: | 2020-07-20 15:17:25 |
| Message-ID: | CAH2-Wz=79hKQ4++c5A060RYbjTHgiYTHz=fw6mptCtgghH2gJA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 18, 2020 at 9:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've pushed this patch, with a number of adjustments, some cosmetic
> and some not so much (no pg_dump support!?). We're not quite
> done though ...
Skink's latest run reports a failure that I surmise was caused by this patch:
==722318== VALGRINDERROR-BEGIN
==722318== Invalid read of size 1
==722318== at 0x4F4CC9: apply_handle_update (worker.c:834)
==722318== by 0x4F4F81: apply_dispatch (worker.c:1427)
==722318== by 0x4F5104: LogicalRepApplyLoop (worker.c:1635)
==722318== by 0x4F57BF: ApplyWorkerMain (worker.c:2141)
==722318== by 0x4BD49E: StartBackgroundWorker (bgworker.c:813)
==722318== by 0x4CBAB4: do_start_bgworker (postmaster.c:5865)
==722318== by 0x4CBBF5: maybe_start_bgworkers (postmaster.c:6091)
==722318== by 0x4CC4BF: sigusr1_handler (postmaster.c:5260)
==722318== by 0x486413F: ??? (in
/usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==722318== by 0x4DC7845: select (select.c:41)
==722318== by 0x4CCE40: ServerLoop (postmaster.c:1691)
==722318== by 0x4CE106: PostmasterMain (postmaster.c:1400)
==722318== Address 0x78cb0ab is 443 bytes inside a recently
re-allocated block of size 8,192 alloc'd
==722318== at 0x483877F: malloc (vg_replace_malloc.c:307)
==722318== by 0x6A55BD: AllocSetContextCreateInternal (aset.c:468)
==722318== by 0x280262: AtStart_Memory (xact.c:1108)
==722318== by 0x2806ED: StartTransaction (xact.c:1979)
==722318== by 0x282128: StartTransactionCommand (xact.c:2829)
==722318== by 0x4F5514: ApplyWorkerMain (worker.c:2014)
==722318== by 0x4BD49E: StartBackgroundWorker (bgworker.c:813)
==722318== by 0x4CBAB4: do_start_bgworker (postmaster.c:5865)
==722318== by 0x4CBBF5: maybe_start_bgworkers (postmaster.c:6091)
==722318== by 0x4CC4BF: sigusr1_handler (postmaster.c:5260)
==722318== by 0x486413F: ??? (in
/usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==722318== by 0x4DC7845: select (select.c:41)
==722318==
==722318== VALGRINDERROR-END
See https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2020-07-20%2002%3A37%3A51
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lawrence Jones | 2020-07-20 15:21:55 | Postgres-native method to identify if a tuple is frozen |
| Previous Message | Marko Tiikkaja | 2020-07-20 14:27:30 | Local visibility with logical decoding |