Robert Haas writes:
> On Wed, Jul 18, 2018 at 10:33 AM, Tom Lane wrote:
>>> So couldn't we use TopTransactionResourceOwner instead of
>>> AuxProcessResrouceOwner? I feel a bit uneasy that bootstrap and
>>> standalone-backend have *AuxProcess*ResourceOwner.
>> Since the aux processes aren't
On Wed, Jul 18, 2018 at 10:33 AM, Tom Lane wrote:
>> So couldn't we use TopTransactionResourceOwner instead of
>> AuxProcessResrouceOwner? I feel a bit uneasy that bootstrap and
>> standalone-backend have *AuxProcess*ResourceOwner.
>
> Since the aux processes aren't running transactions, I didn't
Kyotaro HORIGUCHI writes:
> Hello. I confirmed that this patch fixes the crash.
Thanks for double-checking.
> At Tue, 17 Jul 2018 20:01:05 -0400, Tom Lane wrote in
> <14892.1531872...@sss.pgh.pa.us>
>> Further investigation showed that the part of that code that was
>> actually needed was not
Hello. I confirmed that this patch fixes the crash.
At Tue, 17 Jul 2018 20:01:05 -0400, Tom Lane wrote in
<14892.1531872...@sss.pgh.pa.us>
> I wrote:
> >> So I said I didn't want to do extra work on this, but I am looking into
> >> fixing it by having these aux process types run a ResourceOwner
Robert Haas writes:
> On Tue, Jul 17, 2018 at 8:55 PM, Tom Lane wrote:
>> Uh, what? There are only a few callers of those, and they'd all have
>> crashed already if they were somehow dealing with an invalid buffer.
> Sorry, I meant Assert(owner != NULL).
Oh, gotcha: so that if an external
On Tue, Jul 17, 2018 at 8:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
>>> Any objections? Anyone want to do further review?
>
>> LGTM. I think this is an improvement. However, it seems like it
>> might be a good idea for
Robert Haas writes:
> On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
>> Any objections? Anyone want to do further review?
> LGTM. I think this is an improvement. However, it seems like it
> might be a good idea for ResourceOwnerRememberBuffer and
> ResourceOwnerForgetBuffer to
On Tue, Jul 17, 2018 at 8:01 PM, Tom Lane wrote:
> Any objections? Anyone want to do further review?
LGTM. I think this is an improvement. However, it seems like it
might be a good idea for ResourceOwnerRememberBuffer and
ResourceOwnerForgetBuffer to Assert(buffer != NULL), so that if
I wrote:
>> So I said I didn't want to do extra work on this, but I am looking into
>> fixing it by having these aux process types run a ResourceOwner that can
>> be told to clean up any open buffer pins at exit.
> That turned out to be a larger can of worms than I'd anticipated, as it
> soon
I wrote:
> So I said I didn't want to do extra work on this, but I am looking into
> fixing it by having these aux process types run a ResourceOwner that can
> be told to clean up any open buffer pins at exit. We could be sure the
> coverage is complete by dint of removing the special-case code
Andres Freund writes:
> On 2018-07-15 18:48:43 -0400, Tom Lane wrote:
>> So basically, WAL replay hits an error while holding a buffer pin, and
>> nothing is done to release the buffer pin, but AtProcExit_Buffers thinks
>> something should have been done.
> I think there's a few other cases
Hi,
On 2018-07-15 18:48:43 -0400, Tom Lane wrote:
> So basically, WAL replay hits an error while holding a buffer pin, and
> nothing is done to release the buffer pin, but AtProcExit_Buffers thinks
> something should have been done.
I think there's a few other cases where we hit this. I've seen
Michael Paquier writes:
> On Wed, Jun 27, 2018 at 06:39:39PM -0500, Justin Pryzby wrote:
>> < 2018-06-17 11:38:45.468 CDT >FATAL: could not extend file
>> "base/17379/38665798": No space left on device
>> < 2018-06-17 11:38:45.468 CDT >HINT: Check free disk space.
>> < 2018-06-17
On Wed, Jun 27, 2018 at 06:39:39PM -0500, Justin Pryzby wrote:
> < 2018-06-17 11:38:45.465 CDT pryzbyj >FATAL: the database system is in
> recovery mode
> < 2018-06-17 11:38:45.466 CDT pryzbyj >FATAL: the database system is in
> recovery mode
> < 2018-06-17 11:38:45.468 CDT >FATAL: could not
While grepping logs, I came across this crash, which I caused while adding many
indices in a test environment. I don't know that there's any reason to believe
one way or the other if this is specific to running on pg11b1.
< 2018-06-17 11:38:45.465 CDT pryzbyj >FATAL: the database system is in
15 matches
Mail list logo
