On Wed, Jun 9, 2021 at 11:37 AM Drouvot, Bertrand wrote:
>
> On 6/9/21 5:33 AM, Amit Kapila wrote:
> > On Wed, Jun 9, 2021 at 12:06 AM Jeremy Schneider
> > wrote:
> >> On 6/4/21 23:42, Amit Kapila wrote:
> >>
> >> On 2021-Jun-04, Jeremy Schneider wrote:
> >>
> >> ERROR: XX000: could not open rel
On Wed, Jun 9, 2021 at 12:06 AM Jeremy Schneider wrote:
>
> On 6/4/21 23:42, Amit Kapila wrote:
>
> On 2021-Jun-04, Jeremy Schneider wrote:
>
> ERROR: XX000: could not open relation with OID 0
> LOCATION: ReorderBufferToastReplace, reorderbuffer.c:305
>
> Even, if this fixes the issue, I guess it
On Sat, Jun 5, 2021 at 5:41 AM Alvaro Herrera wrote:
>
> > This indicates that a toast record was present for that relation,
> > despite:
>
> Can you explain what it is you saw that indicates that a toast record
> was present for the relation? I may be misreading the code, but there's
> nothing o
On Sat, Jun 5, 2021 at 5:05 AM Alvaro Herrera wrote:
>
> On 2021-Jun-04, Jeremy Schneider wrote:
>
> > ERROR: XX000: could not open relation with OID 0
> > LOCATION: ReorderBufferToastReplace, reorderbuffer.c:305
>
> Hah.
>
> It seems to me that this code should silently return if
> rd_rel->reltoa
[Resent -- apologies to those who are getting this email twice. Please
be mindful to reply to this one if you do. I think the no-crosspost
policy is very obnoxious and should be relaxed.)
On 2019-Dec-11, Andres Freund wrote:
> On 2019-12-11 08:17:01 +, Drouvot, Bertrand wrote:
> > >>Cor
On 2021-Jun-04, Jeremy Schneider wrote:
> ERROR: XX000: could not open relation with OID 0
> LOCATION: ReorderBufferToastReplace, reorderbuffer.c:305
Hah.
It seems to me that this code should silently return if
rd_rel->reltoastrelid == 0; just like in the case of
txn->toast_hash == NULL. It evi
Hi,
On 2019-12-13 16:13:35 -0800, Jeremy Schneider wrote:
> On 12/11/19 08:35, Andres Freund wrote:
> > I think we need to see pg_waldump output for the preceding records. That
> > might allow us to see why there's a toast record that's being associated
> > with this table, despite there not being
Hi,
On 2019-12-11 12:11:03 -0500, Tom Lane wrote:
> I don't think you can make that conclusion. Perhaps the table once
> needed a toast table because of some wide column that got dropped;
> if so, it'd still have one. It'd be safer to look at
> pg_class.reltoastrelid to verify existence (or not)
On Wed, Dec 11, 2019 at 12:11 PM Tom Lane wrote:
> I don't think you can make that conclusion. Perhaps the table once
> needed a toast table because of some wide column that got dropped;
> if so, it'd still have one. It'd be safer to look at
> pg_class.reltoastrelid to verify existence (or not)
Andres Freund writes:
> This indicates that a toast record was present for that relation,
> despite:
> [ \d that looks like the table isn't wide enough for that ]
> I think we need to see pg_waldump output for the preceding records. That
> might allow us to see why there's a toast record that's be
Hi,
On 2019-12-11 08:17:01 +, Drouvot, Bertrand wrote:
> >>Core was generated by `postgres: walsender
> >>(31712)'.
> >>Program terminated with signal 11, Segmentation fault.
> >>#0 ReorderBufferToastReplace (rb=0x3086af0, txn=0x3094a78,
> >>relation=0x2b79177249c8, relat
On Wed, Dec 11, 2019 at 3:17 AM Drouvot, Bertrand wrote:
>Here it is:
>
> \d+ rel_having_issue
You did a heck of a job choosing the name of that table. I bet nobody
was surprised when it had an issue!
:-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Co
On 12/9/19, 10:10 AM, "Tomas Vondra" wrote:
>On Wed, Dec 04, 2019 at 05:36:16PM -0800, Jeremy Schneider wrote:
>>On 9/8/19 14:01, Tom Lane wrote:
>>> Fix RelationIdGetRelation calls that weren't bothering with error
checks.
>>>
>>> ...
>>>
>>> Details
>>> ---
On Wed, Dec 04, 2019 at 05:36:16PM -0800, Jeremy Schneider wrote:
On 9/8/19 14:01, Tom Lane wrote:
Fix RelationIdGetRelation calls that weren't bothering with error checks.
...
Details
---
https://git.postgresql.org/pg/commitdiff/69f883fef14a3fc5849126799278abcc43f40f56
We had two differ
14 matches
Mail list logo