On Sat, Jul 2, 2022 at 11:10 AM Thomas Munro wrote:
> On Sat, Jul 2, 2022 at 1:15 AM Robert Haas wrote:
> > Changing the default on certain platforms to 'posix' or 'sysv'
> > according to what works best on that platform seems reasonable to me.
>
> Ok, I'm going to make that change in 15 + master
Hi,
On 2022-07-02 11:10:07 +1200, Thomas Munro wrote:
> 2022-07-01 18:25:25.848 CEST [27738:21] pg_regress/prepared_xacts
> ERROR: could not open shared memory segment "/PostgreSQL.499018794":
> File exists
> 2022-07-01 18:25:25.848 CEST [27738:22] pg_regress/prepared_xacts
> STATEMENT: SELECT *
On Sat, Jul 2, 2022 at 1:15 AM Robert Haas wrote:
> Changing the default on certain platforms to 'posix' or 'sysv'
> according to what works best on that platform seems reasonable to me.
Ok, I'm going to make that change in 15 + master.
> I agree that defaulting to 'mmap' doesn't seem like a lot
On Thu, Jun 30, 2022 at 10:34 PM Thomas Munro wrote:
> So... I think we should select a different default
> dynamic_shared_memory_type in initdb.c if defined(__sun__). Which is
> the least terrible? For sysv, it looks like all the relevant sysctls
> that used to be required to use sysv memory be
On Fri, Jul 1, 2022 at 4:02 AM Robert Haas wrote:
> On Wed, Jun 29, 2022 at 12:01 AM Thomas Munro wrote:
> > - if (errno != EEXIST)
> > + if (op == DSM_OP_ATTACH || errno != EEXIST)
> > ereport(elevel,
> >
On Wed, Jun 29, 2022 at 12:01 AM Thomas Munro wrote:
> As for whether PostgreSQL needs to do anything, perhaps we should
> ereport for this unexpected error as a matter of self-preservation, to
> avoid the NULL dereference you'd presumably get on a non-cassert build
> with the current coding? May
On Wed, Jun 29, 2022 at 4:00 PM Thomas Munro wrote:
> I suppose this could indicate that the machine and/or RAM disk is
> overloaded/swapping and one of those open() or unlink() calls is
> taking a really long time, and that could be fixed with some system
> tuning.
Hmm, I take that bit back. Ev
On Wed, Jun 29, 2022 at 6:04 AM Robert Haas wrote:
> My first thought was that the return value of the call to
> dsm_impl_op() at the end of dsm_attach() is not checked and that maybe
> it was returning NULL, but it seems like whoever wrote
> dsm_impl_posix() was pretty careful to ereport(elevel,
On Thu, Jun 2, 2022 at 8:06 PM Thomas Munro wrote:
> I know that on Solaris we use dynamic_shared_memory=posix. The other
> Solaris/Sparc system is wrasse, and it's not doing this. I don't see
> it yet, but figured I'd report this much to the list in case someone
> else does.
My first thought w
Am 28.06.2022 um 08:27 schrieb Thomas Munro:
On Fri, Jun 3, 2022 at 12:05 PM Thomas Munro wrote:
BF animal margay (a newly started Solaris 11.4/Sparc/GCC 11.2 box) is
sometimes failing with:
TRAP: FailedAssertion("seg->mapped_address != NULL", File: "dsm.c",
Line: 1069, PID: 9038)
I spent so
On Fri, Jun 3, 2022 at 12:05 PM Thomas Munro wrote:
> BF animal margay (a newly started Solaris 11.4/Sparc/GCC 11.2 box) is
> sometimes failing with:
>
> TRAP: FailedAssertion("seg->mapped_address != NULL", File: "dsm.c",
> Line: 1069, PID: 9038)
I spent some time on the GCC farm machine gcc211 (
Hi,
BF animal margay (a newly started Solaris 11.4/Sparc/GCC 11.2 box) is
sometimes failing with:
TRAP: FailedAssertion("seg->mapped_address != NULL", File: "dsm.c",
Line: 1069, PID: 9038)
I can't immediately see why it's doing this, but my tool that looks
for assertion failures hasn't seen that
12 matches
Mail list logo
