On Mon, Mar 16, 2020 at 12:38:35PM -0700, Andres Freund wrote:
> > We have ruled out (?) below-PG hardware problems by a
> > successful run of:
> >
> > cp -rv —preserve=all /var/lib/postgresql/9.6 /tmp/
>
> FWIW, I don't think that rules out hardware problems at all. In plenty
> cases of
On Sun, Mar 15, 2020 at 08:11:18PM -0400, Tom Lane wrote:
> Karsten Hilbert writes:
> >>> According to
> >>> http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html
> >>> an UPDATE of the row is recommended -- should that work
> >>> better than a DELETE ?
>
> > OK, got that. What I
Hi,
On March 16, 2020 1:22:18 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2020-03-16 12:44:53 -0700, Andres Freund wrote:
>>> On 2020-03-15 20:11:18 -0400, Tom Lane wrote:
I wonder if we should change it to allow that when
allow_system_table_mods is true? This isn't the
Andres Freund writes:
> On 2020-03-16 12:44:53 -0700, Andres Freund wrote:
>> On 2020-03-15 20:11:18 -0400, Tom Lane wrote:
>>> I wonder if we should change it to allow that when
>>> allow_system_table_mods is true? This isn't the first time we've
>>> seen people need to be able to do surgery on
Hi,
On 2020-03-16 12:44:53 -0700, Andres Freund wrote:
> On 2020-03-15 20:11:18 -0400, Tom Lane wrote:
> > Unfortunately, it seems like you can't do that either, short of
> > hacking up the backend or writing some custom C code, because the
> > executor won't let you open a toast table as result
Hi,
On 2020-03-15 20:11:18 -0400, Tom Lane wrote:
> Unfortunately, it seems like you can't do that either, short of
> hacking up the backend or writing some custom C code, because the
> executor won't let you open a toast table as result relation :-(.
> I wonder if we should change it to allow
Hi,
On 2020-03-15 19:23:49 +0100, Karsten Hilbert wrote:
> > /home/marc# pg_dump -p 5432 --username=gm-dbo --dbname=gnumed_v22
> > --compress=0 --no-sync --format=custom --file=/dev/null
> > pg_dump: Ausgabe des Inhalts der Tabelle »doc_obj« fehlgeschlagen:
> > PQgetResult() fehlgeschlagen.
> >
Karsten Hilbert writes:
>>> According to
>>> http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html
>>> an UPDATE of the row is recommended -- should that work
>>> better than a DELETE ?
> OK, got that. What I now don't understand is how the UPDATE
> won't have to touch the TOAST
On Sun, Mar 15, 2020 at 02:35:39PM -0700, Adrian Klaver wrote:
> On 3/15/20 1:21 PM, Karsten Hilbert wrote:
> > On Sun, Mar 15, 2020 at 12:58:53PM -0700, Adrian Klaver wrote:
> >
> > > > > We then tried to DELETE the offending row
> > > > >
> > > > > delete from blobs.doc_obj where pk =
On 3/15/20 1:21 PM, Karsten Hilbert wrote:
On Sun, Mar 15, 2020 at 12:58:53PM -0700, Adrian Klaver wrote:
We then tried to DELETE the offending row
delete from blobs.doc_obj where pk = 82224;
but that, again, shows the "unexpected chunk" problem.
According to
On Sun, Mar 15, 2020 at 05:04:06PM -0400, Jan Wieck wrote:
> Have you tried to reindex the table? Toast internally forces an index scan,
> so missing index tuples or an otherwise corrupted toast index would have
> the same symptoms as toast chunks actually missing.
We sure did, but thanks for
Have you tried to reindex the table? Toast internally forces an index scan,
so missing index tuples or an otherwise corrupted toast index would have
the same symptoms as toast chunks actually missing.
Regards, Jan
On Sun, Mar 15, 2020, 16:21 Karsten Hilbert wrote:
> On Sun, Mar 15, 2020 at
On Sun, Mar 15, 2020 at 12:58:53PM -0700, Adrian Klaver wrote:
> > > We then tried to DELETE the offending row
> > >
> > > delete from blobs.doc_obj where pk = 82224;
> > >
> > > but that, again, shows the "unexpected chunk" problem.
> >
> > According to
> >
> >
On 3/15/20 12:20 PM, Karsten Hilbert wrote:
On Sun, Mar 15, 2020 at 07:23:49PM +0100, Karsten Hilbert wrote:
We then tried to DELETE the offending row
delete from blobs.doc_obj where pk = 82224;
but that, again, shows the "unexpected chunk" problem.
According to
On Sun, Mar 15, 2020 at 07:23:49PM +0100, Karsten Hilbert wrote:
> We then tried to DELETE the offending row
>
> delete from blobs.doc_obj where pk = 82224;
>
> but that, again, shows the "unexpected chunk" problem.
According to
Dear community,
we are seeing the below error on PG 9.6.16 on Debian:
(different issue from the psycopg2 one recently posted by me)
> /home/marc# pg_dump -p 5432 --username=gm-dbo --dbname=gnumed_v22
> --compress=0 --no-sync --format=custom --file=/dev/null
> pg_dump: Ausgabe des Inhalts der
16 matches
Mail list logo
