doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
doc: Mention the level of locks taken on objects in COMMENT
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Ni
Hi,
On 2022-01-20 17:23:30 +1300, Thomas Munro wrote:
> Having failed to reproduce this locally, I clicked on "re-run tests"
> all afternoon on CI until eventually I captured a failure log[1]
> there, with the smoking gun:
Phew, finally.
> Since this page doesn't require wraparound vacuuming, i
On Wed, Jan 19, 2022 at 12:08 PM Andres Freund wrote:
> On 2022-01-18 17:19:06 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > That's an extremely small shared_buffers for running the regression
> > > tests, it'd not
> > > be surprising if that provoked problems we don't otherwise see. Pe
Jeff Davis writes:
> On Wed, 2022-01-19 at 20:39 +, Tom Lane wrote:
>> Make configure prefer python3 to plain python.
> It looks like this is failing on a few buildfarm members, e.g. jay.
Yeah, see
https://www.postgresql.org/message-id/773175.1642632477%40sss.pgh.pa.us
On Wed, 2022-01-19 at 20:39 +, Tom Lane wrote:
> Make configure prefer python3 to plain python.
It looks like this is failing on a few buildfarm members, e.g. jay.
I committed afterward... sorry, I should have double checked that the
buildfarm was stable first. I'll check up on my patch again
Make logical decoding a part of the rmgr.
Add a new rmgr method, rm_decode, and use that rather than a switch
statement.
In preparation for rmgr extensibility.
Reviewed-by: Julien Rouhaud
Discussion:
https://postgr.es/m/ed1fb2e22d15d3563ae0eb610f7b61bb15999c0a.camel%40j-davis.com
Discussion: ht
interval_out() must be marked STABLE, not IMMUTABLE.
Its results vary depending on the IntervalStyle GUC, so it cannot
be considered immutable.
This is an extremely ancient bug. AFAICT it was a sloppy mistake
in 6f58115dd, which marked it "cacheable" alongside marking several
other interval func
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID
Make configure prefer python3 to plain python.
This avoids possibly selecting Python 2.x on systems that have
both Python 2 and Python 3. We used to feel that what "python"
links to is a user choice that we should honor. However, we're
about to cease support for Python 2, so users will no longer
Don't enable fsync in src/test/recovery/t/008_fsm_truncation.pl.
In adverse circumstances, the fsync calls cause this test to run for
quite a long time (multiple minutes) and even suffer timeout failures.
This seems to date from before we made an effort to disable fsync in
all our test cases; ther
Remove redundant memory context switches in BeginCopyFrom().
This is probably a leftover from code refactoring.
Japin Li
Discussion:
https://postgr.es/m/meyp282mb16693ddabdfec7949ac31857b6...@meyp282mb1669.ausp282.prod.outlook.com
Branch
--
master
Details
---
https://git.postgresql.or
Dynamically find correct installation docs in Makefile.
The base Makefile will output help to the user when invoking make in
an unconfigured tree, the help was however always referring to a file
which may not be present as it's only in tarballs. Dynamically check
for the presence of the INSTALL f
Fix alignment problem with bbsink_copystream buffer.
bbsink_copystream wants to store a type byte just before the buffer,
but basebackup.c wants the buffer to be aligned so that it can call
PageIsNew() and PageGetLSN() on it. Therefore, instead of inserting
1 extra byte before the buffer, insert M
23 matches
Mail list logo
