Le mer. 28 oct. 2020 à 13:11, Michael Paquier a
écrit :
> On Wed, Oct 28, 2020 at 01:41:01PM +0900, Michael Paquier wrote:
> > Yes, thanks. I was already investigating it. No need for a
> > back-trace, I have been able to reproduce it here avec some -m32'ing
> > with gcc:
>
> And this was just
On Wed, Oct 28, 2020 at 01:41:01PM +0900, Michael Paquier wrote:
> Yes, thanks. I was already investigating it. No need for a
> back-trace, I have been able to reproduce it here avec some -m32'ing
> with gcc:
And this was just a thinko with one of the GetDatum() calls. Now
fixed with ce7f772 af
Use correct GetDatum() in pg_relation_check_pages()
UInt32GetDatum() was getting used, while the result needs
Int64GetDatum(). Oversight in f2b8839.
Per buildfarm member florican.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git
On Wed, Oct 28, 2020 at 12:26:29AM -0400, Tom Lane wrote:
> Seems to have some issues according to florican:
>
> 2020-10-28 00:04:53.191 EDT [27031:5] DETAIL: Failed process was
> running: SELECT relname, failed_block_num FROM (SELECT relname,
> (pg_catalog.pg_relation_check_pages(oid)).* FROM
Michael Paquier writes:
> Add pg_relation_check_pages() to check on-disk pages of a relation
Seems to have some issues according to florican:
2020-10-28 00:04:40.336 EDT [27040:3] 022_page_check.pl LOG: statement: SELECT
relname, failed_block_num FROM (SELECT relname,
(pg_catalog.pg_relation_
Add pg_relation_check_pages() to check on-disk pages of a relation
This makes use of CheckBuffer() introduced in c780a7a, adding a SQL
wrapper able to do checks for all the pages of a relation. By default,
all the fork types of a relation are checked, and it is possible to
check only a given rela
Add CheckBuffer() to check on-disk pages without shared buffer loading
CheckBuffer() is designed to be a concurrent-safe function able to run
sanity checks on a relation page without loading it into the shared
buffers. The operation is done using a lock on the partition involved
in the shared buf
Minor improvements in description of spilled counters in
pg_stat_replication_slots view.
Per a suggestion by Justin Pryzby.
Discussion:
https://postgr.es/m/ca+fd4k5_ppayrtdro2pbttoe0ehqpbvuqmcr8ic39utnmr4...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/com
Fix use-after-free bug with event triggers and ALTER TABLE.
EventTriggerAlterTableEnd neglected to make sure that it built its
output list in the right context. In simple cases this was masked
because the function is called in PortalContext which will be
sufficiently long-lived anyway; but that d
Fix use-after-free bug with event triggers and ALTER TABLE.
EventTriggerAlterTableEnd neglected to make sure that it built its
output list in the right context. In simple cases this was masked
because the function is called in PortalContext which will be
sufficiently long-lived anyway; but that d
Fix use-after-free bug with event triggers and ALTER TABLE.
EventTriggerAlterTableEnd neglected to make sure that it built its
output list in the right context. In simple cases this was masked
because the function is called in PortalContext which will be
sufficiently long-lived anyway; but that d
Fix use-after-free bug with event triggers and ALTER TABLE.
EventTriggerAlterTableEnd neglected to make sure that it built its
output list in the right context. In simple cases this was masked
because the function is called in PortalContext which will be
sufficiently long-lived anyway; but that d
Fix use-after-free bug with event triggers and ALTER TABLE.
EventTriggerAlterTableEnd neglected to make sure that it built its
output list in the right context. In simple cases this was masked
because the function is called in PortalContext which will be
sufficiently long-lived anyway; but that d
Doc: improve explanation of how to use our code coverage infrastructure.
The reference to running "make coverage" in a subdirectory was a
bit obscure, so clarify what happens when you do that. Do a little
desultory copy-editing, too.
Per a question from Peter Smith.
Discussion:
https://postgr.
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
master
Details
---
https://g
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_10_STABLE
Details
---
ht
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_11_STABLE
Details
---
ht
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_13_STABLE
Details
---
ht
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_12_STABLE
Details
---
ht
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_6_STABLE
Details
---
ht
Makefile comment: remove reference to tools/thread/thread_test
You can't compile thread_test alone anymore, and the location moved too.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_5_STABLE
Details
---
ht
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
pg_dump: Lock all relations, not just plain tables
Now that LOCK TABLE can take any relation type, acquire lock on all
relations that are to be dumped. This prevents schema changes or
deadlock errors that could cause a dump to fail after expending much
effort. The server is tested to have the ca
Add select_common_typmod()
This accompanies select_common_type() and select_common_collation().
Typmods were previously combined using hand-coded logic in several
places. The logic in select_common_typmod() isn't very exciting, but
it makes the code more compact and readable in a few locations, a
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
Accept relations of any kind in LOCK TABLE
The restriction that only tables and views can be locked by LOCK TABLE
is quite arbitrary, since the underlying mechanism can lock any relation
type. Drop the restriction so that programs such as pg_dump can lock
all relations they're interested in, prev
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
docs: remove reference to src/tools/thread
This directory and the ability to build the thread test independently
were removed in commit 8a2121185b.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatc
Fix enum errdetail to mention bytes, not chars
The enum label length is in terms of bytes, not charactes.
Author: Ian Lawrence Barwick
Reviewed-by: Julien Rouhaud
Discussion:
https://www.postgresql.org/message-id/flat/CAB8KJ=itzej7c9bacthsygeuysh4xx8wdionyppnslyn6-g...@mail.gmail.com
Branch
-
Make procedure OUT parameters work with JDBC
The JDBC driver sends OUT parameters with type void. This makes sense
when calling a function, so that the parameters are ignored in
ParseFuncOrColumn(). For a procedure call we want to treat them as
unknown.
Reviewed-by: Andrew Dunstan
Discussion:
doc: Fix order of protocol messages in listing
Move GSSENCRequest to the correct alphabetical position.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8fed2eadb8558185d162cc7fd09192c2e10b915f
Modified Files
--
doc/src/sgml/protocol.sgml | 75 ++
46 matches
Mail list logo
