| From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
|---|---|
| To: | Ajin Cherian <itsajin(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Single transaction in the tablesync worker? |
| Date: | 2021-02-02 10:00:54 |
| Message-ID: | CAHut+PtTR0n8Lyzc7-2id1oTpNOnaAK8DChuz3HDeZ-4bVfiBQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
After seeing Ajin's test [ac0202] which did a DROP TABLE, I have also
tried a simple test where I do a DROP TABLE with very bad timing for
the tablesync worker. It seems that doing this can cause the sync
worker's MyLogicalRepWorker->relid to become invalid.
In my test this caused a stack trace within some logging, but I
imagine other bad things can happen if the tablesync worker can be
executed with an invalid relid.
Possibly this is an existing PG bug which has just never been seen
before; The ereport which has failed here is not new code.
PSA the log for the test steps and the stack trace details.
----
[ac0202] https://www.postgresql.org/message-id/CAFPTHDYzjaNfzsFHpER9idAPB8v5j%3DSUbWL0AKj5iVy0BKbTpg%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
| Attachment | Content-Type | Size |
|---|---|---|
| v24-Testing-drop-table-20210202.txt | text/plain | 28.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ajin Cherian | 2021-02-02 10:03:52 | Re: Single transaction in the tablesync worker? |
| Previous Message | Paul Guo | 2021-02-02 09:55:43 | Re: Two patches to speed up pg_rewind. |