Message style improvements
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f4f4a649d80fea3ae0214b06e160eb5d46b48a16
Modified Files
--
src/backend/access/heap/vacuumlazy.c | 36 +++-
src/backend/commands/analyze.c | 10
Message style improvements
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d954019f0a60bb989ef6fe8e478b764d0d5f301c
Modified Files
--
src/backend/access/heap/vacuumlazy.c | 36 +++-
src/backend/commands/analyze.c
pg_amcheck: Add missing translation markers
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/789d8060f0517d4da0776480d937d8b64d5c5976
Modified Files
--
src/bin/pg_amcheck/nls.mk | 6 --
src/bin/pg_amcheck/pg_amcheck.c | 16
2 fil
pg_amcheck: Add missing translation markers
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9b0d71725eb2ca6ea0aaffdc38be599b90e7dc56
Modified Files
--
src/bin/pg_amcheck/nls.mk | 6 --
src/bin/pg_amcheck/pg_amcheck.c | 16 ---
Andres Freund writes:
> On 2021-08-06 21:49:52 -0700, Andres Freund wrote:
>> Not yet really sure what the best way to deal with this is. Presumably this
>> issue would be fixed if AtProcExit_Files()/CleanupTempFiles() were scheduled
>> via before_shmem_exit(). And perhaps it's not too off to sche
Hi,
On 2021-08-07 11:43:07 -0400, Tom Lane wrote:
> So if I have the lay of the land correctly:
>
> 1. Somebody decided it'd be a great idea for temp file cleanup to send
> stats collector messages.
>
> 2. Temp file cleanup happens after shmem disconnection.
>
> 3. This accidentally worked, up
Andres Freund writes:
> On 2021-08-07 11:43:07 -0400, Tom Lane wrote:
>> Intuitively it seems like temp file management should be a low-level,
>> backend-local function and therefore should be okay to run after
>> shmem disconnection. I do not have a warm feeling about reversing that
>> module la
Hi,
On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
> The bigger picture here is that anyplace anybody ever wants to add stats
> collection in suddenly becomes a "must run before shmem disconnection"
> module. I think that way madness lies --- we can't have the entire
> backend shut down before shm
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names.
Andres Freund writes:
> On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
>> Fair. But I suggest that the first cut should look more like what
>> I suggest above, ie just be willing to lose events during shutdown.
>> The downsides of that are not so enormous that we should be willing
>> to undertake
pg_amcheck: Message style improvements
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/80dfbbf1b17a1fb1123401799efdc660ee977051
Modified Files
--
src/bin/pg_amcheck/pg_amcheck.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
pg_amcheck: Message style improvements
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/51b95fb257a24aa4186960be8abc24466218
Modified Files
--
src/bin/pg_amcheck/pg_amcheck.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Hi,
On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
> >> Fair. But I suggest that the first cut should look more like what
> >> I suggest above, ie just be willing to lose events during shutdown.
> >> The downsides of that a
Hi,
On 2021-08-07 09:48:50 -0700, Andres Freund wrote:
> I'm somewhat inclined to split InitFileAccess() into two by separating out
> InitTemporaryFileAccess() or such. InitFileAccess() would continue to happen
> early and register a proc exit hook that errors out when there's a temp file
> (as a
Andres Freund writes:
> On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
>> Depends what you want to define as a bug. What I am not happy about
>> is the prospect of random assertion failures for the next six months
>> while you finish redesigning half of the system. The rest of us
>> have work we
Hi,
On 2021-08-07 15:12:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
> >> Depends what you want to define as a bug. What I am not happy about
> >> is the prospect of random assertion failures for the next six months
> >> while you finish red
Remove T_MemoryContext
This is an abstract node that shouldn't have a node tag defined.
Discussion:
https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc053...@enterprisedb.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/256909c6c1679767230
Move temporary file cleanup to before_shmem_exit().
As reported by a few OSX buildfarm animals there exist at least one path where
temporary files exist during AtProcExit_Files() processing. As temporary file
cleanup causes pgstat reporting, the assertions added in ee3f8d3d3ae caused
failures.
Th
Hi,
On 2021-08-07 12:01:31 -0700, Andres Freund wrote:
> Attached is a patch showing how this could look like. Note that the PANIC
> should likely not be that but a WARNING, but the PANIC more useful for running
> some initial tests...
I pushed a slightly evolved version of this. As the commit me
Fix use-after-free issue in regexp engine.
Commit cebc1d34e taught parseqatom() to optimize cases where a branch
contains only one, "messy", atom by getting rid of excess subRE nodes.
The way we really should do that is to keep the subRE built for the
"messy" child atom; but to avoid changing pars
Fix use-after-free issue in regexp engine.
Commit cebc1d34e taught parseqatom() to optimize cases where a branch
contains only one, "messy", atom by getting rid of excess subRE nodes.
The way we really should do that is to keep the subRE built for the
"messy" child atom; but to avoid changing pars
Make regexp engine's backref-related compilation state more bulletproof.
Up to now, we remembered the definition of a capturing parenthesis
subexpression by storing a pointer to the associated subRE node.
That was okay before, because that subRE didn't get modified anymore
while parsing the rest o
Make regexp engine's backref-related compilation state more bulletproof.
Up to now, we remembered the definition of a capturing parenthesis
subexpression by storing a pointer to the associated subRE node.
That was okay before, because that subRE didn't get modified anymore
while parsing the rest o
29 matches
Mail list logo
