Update Microsoft documentation link
Reported-by: Juan José SantamarÃa Flecha
Discussion:
https://www.postgresql.org/message-id/CAC%2BAXB1EDXiRPmiVfh%2BWX79x5vXJDU17k0GkDjfyPgOWO4Y5og%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ed0d8837658946de
Add assertions to _bt_update_posting().
Copy some assertions from _bt_form_posting() to its sibling function,
_bt_update_posting().
Discussion:
https://postgr.es/m/cah2-wzkpr8kmwkl0ap976kmxwbceuktehz6fb-u__wvup1s...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org
On Sun, Mar 1, 2020 at 8:06 PM Tom Lane wrote:
> > I was thinking of the approach taken in the attached patch. It more or
> > less copies over the assertions from _bt_form_posting() that did not
> > appear in _bt_update_posting().
>
> OK by me.
Pushed. Thanks.
--
Peter Geoghegan
Another issue I just noticed is that src/tools/pginclude/cpluspluscheck
complains thusly:
./src/include/access/nbtree.h: In function 'void
BTreeTupleSetPosting(IndexTupleData*, int, int)':
./src/include/access/nbtree.h:384: warning: comparison between signed and
unsigned integer expressions
I s
Silence nbtree.h cpluspluscheck warning.
Add a cast to size_t to silence "comparison between signed and unsigned
integer expressions" cpluspluscheck warning.
Reported-By: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.post
On Mon, Mar 2, 2020 at 9:47 AM Tom Lane wrote:
> I suppose this can be silenced with an appropriate cast, and doing so
> would seem like a good idea.
I pushed a commit that silenced the cpluspluscheck warning just now.
Thanks
--
Peter Geoghegan
Blacklist port/win32_msvc/utime.h in cpluspluscheck and headerscheck.
Since commit 481c8e923 it tends to produce "error: sys/utime.h: No such
file or directory" on non-Windows platforms.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7b425a5283cb2c8a452c2e79d6218e4
Represent command completion tags as structs
The backend was using strings to represent command tags and doing string
comparisons in multiple places, but that's slow and unhelpful. Create a
new command list with a supporting structure to use instead; this is
stored in a tag-list-file that can be
On 3/2/20 2:05 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On Sat, Feb 29, 2020 at 10:41 AM Tom Lane wrote:
>>> Did the buildfarm adjustments get made? (I'm assuming Andrew knows)
>> It's in Release 11 of the client and is mentioned in the release
>> notes. The release is dated last Septem
Fix possibly-uninitialized variable.
Thinko in 2f9661311. Per buildfarm, as well as warning seen locally.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/91f3bd732cea7e25e53eaceae88232d0ab984434
Modified Files
--
contrib/pg_stat_statements/pg_stat_stat
Preserve pg_index.indisclustered across REINDEX CONCURRENTLY
If the flag value is lost, a CLUSTER query following REINDEX
CONCURRENTLY could fail. Non-concurrent REINDEX is already handling
this case consistently.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20200229024202.gh29...@telsa
Preserve pg_index.indisclustered across REINDEX CONCURRENTLY
If the flag value is lost, a CLUSTER query following REINDEX
CONCURRENTLY could fail. Non-concurrent REINDEX is already handling
this case consistently.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20200229024202.gh29...@telsa
Report progress of streaming base backup.
This commit adds pg_stat_progress_basebackup view that reports
the progress while an application like pg_basebackup is taking
a base backup. This uses the progress reporting infrastructure
added by c16dc1aca5e0, adding support for streaming base backup.
B
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix the name of the first WAL segment file, in docs.
Previously the documentation explains that WAL segment files
start at 0001. But the first WAL segment file
that initdb creates is 00010001 not
0001. This change was caused by old
commit 8c8
Fix assertion failure with ALTER TABLE ATTACH PARTITION and indexes
Using ALTER TABLE ATTACH PARTITION causes an assertion failure when
attempting to work on a partitioned index, because partitioned indexes
cannot have partition bounds.
The grammar of ALTER TABLE ATTACH PARTITION requires partiti
Fix assertion failure with ALTER TABLE ATTACH PARTITION and indexes
Using ALTER TABLE ATTACH PARTITION causes an assertion failure when
attempting to work on a partitioned index, because partitioned indexes
cannot have partition bounds.
The grammar of ALTER TABLE ATTACH PARTITION requires partiti
Fix assertion failure with ALTER TABLE ATTACH PARTITION and indexes
Using ALTER TABLE ATTACH PARTITION causes an assertion failure when
attempting to work on a partitioned index, because partitioned indexes
cannot have partition bounds.
The grammar of ALTER TABLE ATTACH PARTITION requires partiti
Remove overzealous _bt_split() assertions.
_bt_split() is passed NULL as its insertion scankey for internal page
splits. Two recently added Assert() statements failed to consider this,
leading to a crash with pg_upgrade'd BREE_VERSION < 4 indexes. Remove
the assertions.
The assertions in questi
Fix typo in monitoring.sgml.
Author: Noriyoshi Shinoda
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/61b73940452b1f6871a1d73f35216fb052a7a5ab
Modified Files
--
doc/src/sgml/monitoring.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
pg_standby: Don't use HAVE_WORKING_LINK
HAVE_WORKING_LINK is meant to indicate support for hard links, mainly
for Windows. Here it is used for soft links on Unix, and the
functionality is optional anyway, so we can just make it error out
normally if needed.
Discussion:
https://www.postgresql.or
25 matches
Mail list logo