Add index OID macro argument to DECLARE_INDEX
Instead of defining symbols such as AmOidIndexId explicitly, include
them as an argument of DECLARE_INDEX() and have genbki.pl generate the
way as the table OID symbols from the CATALOG() declaration.
Reviewed-by: John Naylor
Discussion:
https://www
On Tue, Jun 29, 2021 at 12:40:13AM -0400, Tom Lane wrote:
> Should this not have included a bump of XLOG_PAGE_MAGIC?
It should, thanks! Fixed now.
--
Michael
signature.asc
Description: PGP signature
Bump XLOG_PAGE_MAGIC for format changes related to FPW compression
Oversight in 4035cd5, spotted by Tom Lane.
Discussion: https://postgr.es/m/365778.1624941...@sss.pgh.pa.us
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/445e36ad4e14480a3c97d0f973a3532912424e85
M
Michael Paquier writes:
> Add support for LZ4 with compression of full-page writes in WAL
Should this not have included a bump of XLOG_PAGE_MAGIC?
regards, tom lane
Fix compilation warning in xloginsert.c
This is reproducible with gcc using at least -O0. The last checks
validating the compression of a block could not be reached with this
variable not set, but let's be clean.
Oversight in 4035cd5, per buildfarm member lapwing.
Branch
--
master
Details
Add support for LZ4 with compression of full-page writes in WAL
The logic is implemented so as there can be a choice in the compression
used when building a WAL record, and an extra per-record bit is used to
track down if a block is compressed with PGLZ, LZ4 or nothing.
wal_compression, the exist
In XLogFileInit(), fix *use_existent postcondition to suit callers.
Infrequently, the mismatch caused log_checkpoints messages and
TRACE_POSTGRESQL_CHECKPOINT_DONE() to witness an "added" count too high
by one. Since that consequence is so minor, no back-patch.
Discussion: https://postgr.es/m/20
Skip WAL recycling and preallocation during archive recovery.
The previous commit addressed the chief consequences of a race condition
between InstallXLogFileSegment() and KeepFileRestoredFromArchive(). Fix
three lesser consequences. A spurious durable_rename_excl() LOG message
remained possible
Remove XLogFileInit() ability to unlink a pre-existing file.
Only initdb used it. initdb refuses to operate on a non-empty directory
and generally does not cope with pre-existing files of other kinds.
Hence, use the opportunity to simplify.
Discussion: https://postgr.es/m/20210202151416.gb3304..
Dump public schema ownership and security labels.
As a side effect, this corrects dumps of public schema ACLs in databases
where the DBA dropped and recreated that schema.
Reviewed by Asif Rehman.
Discussion: https://postgr.es/m/20201229134924.ga1431...@rfd.leadboat.com
Branch
--
master
De
Remove XLogFileInit() ability to skip ControlFileLock.
Cold paths, initdb and end-of-recovery, used it. Don't optimize them.
Discussion: https://postgr.es/m/20210202151416.gb3304...@rfd.leadboat.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c53c6b98d38a4d238
Don't ERROR on PreallocXlogFiles() race condition.
Before a restartpoint finishes PreallocXlogFiles(), a startup process
KeepFileRestoredFromArchive() call can unlink the preallocated segment.
If a CHECKPOINT sql command had elicited the restartpoint experiencing
the race condition, that sql comma
Dump COMMENT ON SCHEMA public.
As we do for other attributes of the public schema, omit the COMMENT
command when its payload would match what initdb had installed. For
dumps that do carry this new COMMENT command, non-superusers restoring
them are likely to get an error.
Reviewed by Asif Rehman.
doc: Improve PG14 release notes
Mostly markup improvements.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20210625230456.gp29...@telsasoft.com
Backpatch-through: 14 only
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/caa0f07d2d4b69cd53b5bf7c
Doc: further updates for RELEASE_CHANGES process notes.
Mention expectations for email notifications of appropriate lists
when a branch is made or retired.
(I've been doing that informally for years, but it's better to have
it written down.)
Branch
--
master
Details
---
https://git.post
On Mon, Jun 28, 2021 at 12:53 PM Tom Lane wrote:
> > How about the approach taken in the attached patch?
>
> WFM.
Pushed. Thanks.
--
Peter Geoghegan
Improve pgindent release workflow.
Update RELEASE_CHANGES to direct the reader towards completing the steps
outlined in the pgindent README, both as a pre-beta task and as a task
to be performed when starting a new development cycle.
This makes it less likely that somebody will miss updating the
Peter Geoghegan writes:
> On Mon, Jun 28, 2021 at 9:47 AM Tom Lane wrote:
>> The instructions for "Starting a New Development Cycle" perhaps need
>> a specific "see src/tools/pgindent/README". I'd be inclined to
>> remove the separate mention of .git-blame-ignore-revs from "Pre-Beta
>> Tasks", t
On Mon, Jun 28, 2021 at 9:47 AM Tom Lane wrote:
> The instructions for "Starting a New Development Cycle" perhaps need
> a specific "see src/tools/pgindent/README". I'd be inclined to
> remove the separate mention of .git-blame-ignore-revs from "Pre-Beta
> Tasks", too. If you didn't read pginden
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
Don't use abort(3) in libpq's fe-print.c.
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error retur
On Mon, Jun 28, 2021 at 9:43 AM Alvaro Herrera wrote:
> ... and now that I look at running that command, I notice that the date
> format it generates for me is different from what it did for you:
This is because our global git configs differ.
> Is it worth documenting whatever is causing the out
Peter Geoghegan writes:
> On Mon, Jun 28, 2021 at 9:31 AM Andrew Dunstan wrote:
>> Hmm, did I miss something or do we need to update some instructions
>> somewhere?
> I did update the instructions in commit 8e638845, but perhaps I
> omitted to update something. What do you think?
The instructio
On 2021-Jun-28, Peter Geoghegan wrote:
> On Mon, Jun 28, 2021 at 9:31 AM Andrew Dunstan wrote:
> > Hmm, did I miss something or do we need to update some instructions
> > somewhere?
>
> (Responded on the other committers thread just now too.)
>
> I did update the instructions in commit 8e638845
Don't depend on -fwrapv semantics in pgbench's random() function.
Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion. This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizin
Don't depend on -fwrapv semantics in pgbench's random() function.
Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion. This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizin
Don't depend on -fwrapv semantics in pgbench's random() function.
Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion. This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizin
Don't depend on -fwrapv semantics in pgbench's random() function.
Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion. This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizin
On Mon, Jun 28, 2021 at 9:31 AM Andrew Dunstan wrote:
> Hmm, did I miss something or do we need to update some instructions
> somewhere?
(Responded on the other committers thread just now too.)
I did update the instructions in commit 8e638845, but perhaps I
omitted to update something. What do y
On Mon, Jun 28, 2021 at 8:08 AM Andrew Dunstan wrote:
> Pre branch pgindent / pgperltidy run
We recently started maintaining a file that lists ignorable commits --
commits that git-blame ignores to produce more helpful output (when an
individual hacker opts in).
See:
https://postgr.es/m/CAH2-Wz
On 6/28/21 12:26 PM, Peter Geoghegan wrote:
> Add pgindent commit to git-blame-ignore-revs file.
>
> Add entry for recent commit e1c1c30f.
>
Hmm, did I miss something or do we need to update some instructions
somewhere?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Add pgindent commit to git-blame-ignore-revs file.
Add entry for recent commit e1c1c30f.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ba135fa537ab5c2fca0d589c826ebb3ecf98b2f1
Modified Files
--
.git-blame-ignore-revs | 5 -
1 file changed, 4 insert
Stamp HEAD as 15devel.
Let the hacking begin ...
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/596b5af1d3675b58d4018acd64217e2f627da3e4
Modified Files
--
configure| 18 +-
configure.ac |2 +-
doc/src/sgml/fileli
Branch REL_14_STABLE was created.
View: https://git.postgresql.org/pg/shortlog/refs/heads/REL_14_STABLE
Pre branch pgindent / pgperltidy run
Along the way make a slight adjustment to
src/include/utils/queryjumble.h to avoid an unused typedef.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e1c1c30f635390b6a3ae4993e8cac213a33e6e3f
Modified Files
--
src/bac
40 matches
Mail list logo
