> On Wed, 5 Oct 2022 at 16:30, Tom Lane wrote:
> > One other point to discuss: should we consider back-patching? I've
> > got mixed feelings about that myself. I don't think that cases where
> > this helps significantly are at all mainstream, so I'm kind of leaning
> > to "patch HEAD only".
At
On Wed, 5 Oct 2022 at 16:30, Tom Lane wrote:
>
> Kyotaro Horiguchi writes:
> > At Tue, 4 Oct 2022 17:15:31 -0700, Nathan Bossart
> > wrote in
> >> On Tue, Oct 04, 2022 at 07:53:11PM -0400, Tom Lane wrote:
> >>> After further thought, maybe it'd be better to do it as attached,
> >>> with one lon
On Wed, Oct 05, 2022 at 11:30:22AM -0400, Tom Lane wrote:
> One other point to discuss: should we consider back-patching? I've
> got mixed feelings about that myself. I don't think that cases where
> this helps significantly are at all mainstream, so I'm kind of leaning
> to "patch HEAD only".
+
Kyotaro Horiguchi writes:
> At Tue, 4 Oct 2022 17:15:31 -0700, Nathan Bossart
> wrote in
>> On Tue, Oct 04, 2022 at 07:53:11PM -0400, Tom Lane wrote:
>>> After further thought, maybe it'd be better to do it as attached,
>>> with one long-lived hash table for all the locks.
> First one is strai
At Tue, 4 Oct 2022 17:15:31 -0700, Nathan Bossart
wrote in
> On Tue, Oct 04, 2022 at 07:53:11PM -0400, Tom Lane wrote:
> > I wrote:
> >> PFA a quick-hack fix that solves this issue by making per-transaction
> >> subsidiary hash tables. That's overkill perhaps; I'm a little worried
> >> about wh
On Tue, Oct 04, 2022 at 07:53:11PM -0400, Tom Lane wrote:
> I wrote:
>> PFA a quick-hack fix that solves this issue by making per-transaction
>> subsidiary hash tables. That's overkill perhaps; I'm a little worried
>> about whether this slows down normal cases more than it's worth.
>> But we ought
I wrote:
> PFA a quick-hack fix that solves this issue by making per-transaction
> subsidiary hash tables. That's overkill perhaps; I'm a little worried
> about whether this slows down normal cases more than it's worth.
> But we ought to do something about this, because aside from the
> duplicatio
[ redirecting to -hackers because patch attached ]
David Rowley writes:
> So that confirms there were 950k relations in the xl_standby_locks.
> The contents of that message seem to be produced by standby_desc().
> That should be the same WAL record that's processed by standby_redo()
> which adds
user cropin_suhal: *
*BEGIN*
*CREATE TABLE*
*ERROR: invalid memory alloc request size 1073741824*
*ERROR: current transaction is aborted, commands ignored until end of
transaction block*
*ERROR: current transaction is aborted, commands ignored until end of
transaction block*
*ERROR: current transacti
Suhal Vemu writes:
> so, i need to import the tif file of memory greater than 500mb at least .
If you're trying to cram that into a single bytea field, it's unsurprising
that it fails. PG is not designed to work with table rows (let alone
individual fields) that exceed some not-very-large fracti
On 6 April 2018 at 22:06, Suhal Vemu wrote:
> ERROR:
> BEGIN
> CREATE TABLE
> ERROR: invalid memory alloc request size 1073741824
Can we see the full CREATE TABLE command?
Are you able to get the CREATE TABLE to succeed if you try removing
some combination of columns? Start with
ve checked with tiles by setting -t auto but when aggregating results
of titles using st_union my system is getting hung.
so, i need to import the tif file of memory greater than 500mb at least .
the error that i am getting is
*ERROR:*
*BEGIN*
*CREATE TABLE*
*ERROR: invalid memory alloc re
12 matches
Mail list logo
