Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Move RecoveryLockList into a hash table.
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done
Reword SPI_ERROR_TRANSACTION errors in PL/pgSQL
The previous message for SPI_ERROR_TRANSACTION claimed "cannot begin/end
transactions in PL/pgSQL", but that is no longer true. Nevertheless,
the error can still happen, so reword the messages. The error cases in
exec_prepare_plan() could never hap
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already pr
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already pr
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already pr
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already pr
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already pr
Increase upper limit for vacuum_cleanup_index_scale_factor
Upper limits for vacuum_cleanup_index_scale_factor GUC and reloption
were initially set to 100.0 in 857f9c36. However, after further
discussion, it appears that some users like to disable B-tree cleanup
index scan completely (assuming the
On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov
wrote:
> vacuum_cleanup_index_scale_factor is used barely to protect against
> stalled index statistics. And after detailed consideration it appears
> that risk of stalled index statistics is low. And it would be nice to
> allow advanced users s
On Tue, Jun 26, 2018 at 3:59 PM Alexander Korotkov
wrote:
>
> On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov
> wrote:
> > vacuum_cleanup_index_scale_factor is used barely to protect against
> > stalled index statistics. And after detailed consideration it appears
> > that risk of stalled ind
Allow direct lookups of AppendRelInfo by child relid
find_appinfos_by_relids had quite a large overhead when the number of
items in the append_rel_list was high, as it had to trawl through the
append_rel_list looking for AppendRelInfos belonging to the given
childrelids. Since there can only be a
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Fix documentation bug related to backup history file.
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to pr
Enable failure to rename a partitioned index
Concurrently with partitioned index development (commit 8b08f7d4820f),
the code to handle failure to rename indexes was refactored (commit
8b9e9644dc6a). Turns out that that particular case was untested, which
naturally led it to be broken. Add tests
Alexander Korotkov writes:
> BTW, this line looks cumbersome.
> +DETAIL: Valid values are between "0.00" and
> "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245
Remove obsolete comment block in nbtsort.c.
Building a new nbtree index through incremental insertions would always
be slower than our actual approach of sorting using tuplesort,
assembling leaf pages from tuplesort output, and writing and WAL-logging
whole pages. Remove a comment block from the
On Tue, Jun 26, 2018 at 7:00 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > BTW, this line looks cumbersome.
>
> > +DETAIL: Valid values are between "0.00" and
> > "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464
Correct a comment on logtape.c's leader tape.
randomAccess parallel tuplesorts are disallowed because the leader would
try to write to its own leader tape, not because the leader would try to
write to a worker tape directly.
Cleanup from commit 9da0cc35284.
Branch
--
master
Details
---
|--- gitweb/email subject limit -|-|
doc: PG 11 relnotes: remove channel binding from major features
Also move to the source code section, and expand the paragraph
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a89357e2f7839f5bc0815f4c
On Tue, Jun 26, 2018 at 06:32:01PM +, Bruce Momjian wrote:
> |--- gitweb/email subject limit -|-|
Oops, sorry for the line above. I modified my script to remove it, but
it seems it did not work.
-
Fix upper limit for vacuum_cleanup_index_scale_factor
6ca33a88 sets upper limit for vacuum_cleanup_index_scale_factor to
DBL_MAX. DBL_MAX appears to be platform-dependent. That causes
many buildfarm animals to fail, because we check boundaries of
vacuum_cleanup_index_scale_factor in regression te
Fix "base" snapshot handling in logical decoding
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used
Fix "base" snapshot handling in logical decoding
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used
Fix "base" snapshot handling in logical decoding
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used
Fix "base" snapshot handling in logical decoding
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used
Fix "base" snapshot handling in logical decoding
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used
Cosmetic improvements for faster column addition.
Changed the name of few structure members for the sake of clarity and
removed spurious whitespace.
Reported-by: Amit Kapila
Author: Amit Kapila, based on suggestion by Andrew Dunstan
Reviewed-by: Alvaro Herrera
Discussion:
https://postgr.es/m/CAA
doc: Document some nuances of logical replication of TRUNCATE
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c9d6a45724d642a00bd2b4c0f082cf4e1eb76e29
Modified Files
--
doc/src/sgml/logical-replication.sgml | 16
1 file changed, 16 insert
Fix whitespace
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0fcf5e0e6e7a353f862504da0a321f148ad2de03
Modified Files
--
src/test/perl/TestLib.pm| 4 ++--
src/tools/perlcheck/find_perl_files | 3 +--
src/tools/perlcheck/perlcriticrc| 1 -
3
doc: Improve wording and fix whitespace
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ae5ed75ed4a951c58ec6a76362241b6ac32be61c
Modified Files
--
doc/src/sgml/logical-replication.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Remove duplicated return statement from llvmjit code.
The duplicated return clearly doesn't make sense / isn't
reachable. Likely introduced by me (Andres), while revising the code.
Author: Rushabh Lathia
Discussion:
https://postgr.es/m/CAGPqQf2raxWOcbuTP36M1rEF3=rfo7od29k3psdyhmee5sw...@mail.gma
Change pqformat.h's integer handling functions to take unsigned integers.
As added in 1de09ad8eb1fa673ee7899d6dfbb2b49ba204818 the new functions
all accept signed integers as parameters. That's not great, because
it's perfectly reasonable to call them with unsigned parameters.
Unfortunately unsign
41 matches
Mail list logo
