On Thu, 6 Apr 2023 at 16:04, Michael Paquier wrote:
> I have just seen this commit, and I am pretty sure that the checks
> have been placed in vacuum() to guard against incorrect option
> manipulations in the context of an autovacuum building the relations,
> so you are making this code weaker
Hi,
On 2023-04-06 13:04:17 +0900, Michael Paquier wrote:
> On Thu, Apr 06, 2023 at 03:45:19AM +, David Rowley wrote:
> > Move various prechecks from vacuum() into ExecVacuum()
> >
> > vacuum() is used for both the VACUUM command and for autovacuum. There
> > were many prechecks being done
Hi David,
On Thu, Apr 06, 2023 at 03:45:19AM +, David Rowley wrote:
> Move various prechecks from vacuum() into ExecVacuum()
>
> vacuum() is used for both the VACUUM command and for autovacuum. There
> were many prechecks being done inside vacuum() that were just not relevant
> to
Move various prechecks from vacuum() into ExecVacuum()
vacuum() is used for both the VACUUM command and for autovacuum. There
were many prechecks being done inside vacuum() that were just not relevant
to autovacuum. Let's move the bulk of these into ExecVacuum() so that
they're only executed
Convert many uses of ReadBuffer[Extended](P_NEW) to ExtendBufferedRel()
A few places are not converted. Some because they are tackled in later
commits (e.g. hio.c, xlogutils.c), some because they are more
complicated (e.g. brin_pageops.c). Having a few users of ReadBuffer(P_NEW) is
good anyway,
Hi,
On 2023-04-05 16:58:41 -0700, Andres Freund wrote:
> On 2023-04-05 19:19:48 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Don't initialize page in {vm,fsm}_extend(), not needed
> >
> > Various buildfarm members are complaining about under-braced
> > initializations added by this
Use ExtendBufferedRelTo() in {vm,fsm}_extend()
This uses ExtendBufferedRelTo(), introduced in 31966b151e6, to extend the
visibilitymap and freespacemap to the size needed.
It also happens to fix a warning introduced in 3d6a98457d8, reported by Tom
Lane.
Discussion:
Always make a BufferAccessStrategy for ANALYZE
32fbe0239 changed things so we didn't bother allocating the
BufferAccessStrategy during VACUUM (ONLY_DATABASE_STATS); and VACUUM
(FULL), however, it forgot to consider that VACUUM (FULL, ANALYZE) is a
possible combination. That change would have
Fix row tracking in pg_stat_statements with extended query protocol
pg_stat_statements relies on EState->es_processed to count the number of
rows processed by ExecutorRun(). This proves to be a problem under the
extended query protocol when the result of a query is fetched through
more than one
bufmgr: Introduce infrastructure for faster relation extension
The primary bottlenecks for relation extension are:
1) The extension lock is held while acquiring a victim buffer for the new
page. Acquiring a victim buffer can require writing out the old page
contents including possibly
Hi,
On 2023-04-05 19:19:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Don't initialize page in {vm,fsm}_extend(), not needed
>
> Various buildfarm members are complaining about under-braced
> initializations added by this commit.
>
> visibilitymap.c: In function
On Wed, Apr 05, 2023 at 07:19:48PM -0400, Tom Lane wrote:
> freespace.c: In function \342\200\230fsm_extend\342\200\231:
> freespace.c:611:2: warning: missing braces around initializer
> [-Wmissing-braces]
> PGAlignedBlock pg = {0};
> ^
> freespace.c:611:2: warning: (near initialization for
Andres Freund writes:
> Don't initialize page in {vm,fsm}_extend(), not needed
Various buildfarm members are complaining about under-braced
initializations added by this commit.
visibilitymap.c: In function \342\200\230vm_extend\342\200\231:
visibilitymap.c:625:2: warning: missing braces around
Allow to use system CA pool for certificate verification
This adds a new option to libpq's sslrootcert, "system", which will load
the system trusted CA roots for certificate verification. This is a more
convenient way to achieve this than pointing to the system CA roots
manually since the
bufmgr: Support multiple in-progress IOs by using resowner
A future patch will add support for extending relations by multiple blocks at
once. To be concurrency safe, the buffers for those blocks need to be marked
as BM_IO_IN_PROGRESS. Until now we only had infrastructure for recovering from
an
Support "Right Anti Join" plan shapes.
Merge and hash joins can support antijoin with the non-nullable input
on the right, using very simple combinations of their existing logic
for right join and anti join. This gives the planner more freedom
about how to order the join. It's particularly
bufmgr: Acquire and clean victim buffer separately
Previously we held buffer locks for two buffer mapping partitions at the same
time to change the identity of buffers. Particularly for extending relations
needing to hold the extension lock while acquiring a victim buffer is
painful.But it also
Acquire locks on views in AcquirePlannerLocks, too.
Commit 47bb9db75 taught AcquireExecutorLocks to re-acquire locks
on views using data from their RTE_SUBQUERY replacements, but
it now seems like we should make AcquirePlannerLocks do the same.
In this way, if a view has been redefined, we will
pg_dump: Add support for zstd compression
Allow pg_dump to use the zstd compression, in addition to gzip/lz4. Bulk
of the new compression method is implemented in compress_zstd.{c,h},
covering the pg_dump compression APIs. The rest of the patch adds test
and makes various places aware of the new
bufmgr: Add some more error checking [infrastructure] around pinning
This adds a few more assertions against a buffer being local in places we
don't expect, and extracts the check for a buffer being pinned exactly once
from LockBufferForCleanup() into its own function. Later commits will use this
bufmgr: Add Pin/UnpinLocalBuffer()
So far these were open-coded in quite a few places, without a good reason.
Reviewed-by: Melanie Plageman
Reviewed-by: David Rowley
Discussion:
https://postgr.es/m/20221029025420.eplyow6k7tgu6...@awork3.anarazel.de
Branch
--
master
Details
---
Add smgrzeroextend(), FileZero(), FileFallocate()
smgrzeroextend() uses FileFallocate() to efficiently extend files by multiple
blocks. When extending by a small number of blocks, use FileZero() instead, as
using posix_fallocate() for small numbers of blocks is inefficient for some
file systems /
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers. Other variants of ENABLE/DISABLE TRIGGER would
improperly apply
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers. Other variants of ENABLE/DISABLE TRIGGER would
improperly apply
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers. Other variants of ENABLE/DISABLE TRIGGER would
improperly apply
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers. Other variants of ENABLE/DISABLE TRIGGER would
improperly apply
Don't initialize page in {vm,fsm}_extend(), not needed
The read path needs to be able to initialize pages anyway, as relation
extensions are not durable. By avoiding initializing pages, we can, in a
future patch, extend the relation by multiple blocks at once.
Using smgrextend() for
Fix wrong word in comment.
Reported by Peter Smith.
Discussion:
http://postgr.es/m/cahut+pt52ueoeao-g5qeziipv1p9pbt_w5vj3btyfc8sd8l...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/86a3fc7ec8a03bca7120894bababa7c734628b4c
Modified Files
Update information_schema for SQL:2023
This is mainly a light renumbering to match the sections in the
standard.
The comments for SQL_IMPLEMENTATION_INFO and SQL_SIZING are no longer
applicable because the required information has been moved into part
9.
Branch
--
master
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
REL_11_STABLE
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
REL_12_STABLE
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
REL_13_STABLE
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
REL_14_STABLE
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
REL_15_STABLE
Details
---
doc: Update error messages in RLS examples
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
Branch
--
master
Details
---
doc: Update SQL features/conformance information to SQL:2023
Optional subfeatures have been changed to top-level features, so there
is a bit of a churn in the list for that.
Some existing functions have been added to the standard, so they are
moved from the "other" to the "standard" lists in
Fix function reference in comment
Commit a61b1f748 renamed ExecCheckRTEPerms to ExecCheckPermissions
as part of a larger body of work, but missed this comment. Fix by
updating the referenced function name to make the comment the same
as other occurrences.
Author: Koshi Shibagaki
Discussion:
doc: Update SQL keywords list to SQL:2023
Per previous convention (see
ace397e9d24eddc56e7dffa921f506117b602d78), drop SQL:2011 and only keep
the latest two standards and SQL-92.
Discussion:
https://www.postgresql.org/message-id/flat/63f285d9-4ec8-0c9e-4bf5-e76334ddc...@enterprisedb.com
Branch
38 matches
Mail list logo
