Avoid pin scan for replay of XLOG_BTREE_VACUUM
Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to require
complex interlocking that matched the requirements on the master. This required
an O(N) operation that became a significant problem with large indexes, causing
replication
Hi,
On 2016-01-09 10:13:27 +, Simon Riggs wrote:
> src/backend/access/rmgrdesc/nbtdesc.c |2 +-
I've not reviewed the patch, but a very quick glance during a rebase
with conflicts showed:
@@ -48,7 +48,7 @@ btree_desc(StringInfo buf, XLogReaderState *record)
{
x
On 9 January 2016 at 12:23, Andres Freund wrote:
> Hi,
>
> On 2016-01-09 10:13:27 +, Simon Riggs wrote:
> > src/backend/access/rmgrdesc/nbtdesc.c |2 +-
>
> I've not reviewed the patch, but a very quick glance during a rebase
> with conflicts showed:
>
> @@ -48,7 +48,7 @@ btree_desc(String
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
Add STRICT to some C functions created by the regression tests.
These functions readily crash when passed a NULL input value. The tests
themselves do not pass NULL values to them; but when the regression
database is used as a basis for fuzz testing, they cause a lot of noise.
Also, if someone wer
On 2016-01-09 17:58:01 +, Simon Riggs wrote:
> On 9 January 2016 at 12:23, Andres Freund wrote:
>
> > Hi,
> >
> > On 2016-01-09 10:13:27 +, Simon Riggs wrote:
> > > src/backend/access/rmgrdesc/nbtdesc.c |2 +-
> >
> > I've not reviewed the patch, but a very quick glance during a rebase
On 9 January 2016 at 18:08, Andres Freund wrote:
> On 2016-01-09 17:58:01 +, Simon Riggs wrote:
> > On 9 January 2016 at 12:23, Andres Freund wrote:
> >
> > > Hi,
> > >
> > > On 2016-01-09 10:13:27 +, Simon Riggs wrote:
> > > > src/backend/access/rmgrdesc/nbtdesc.c |2 +-
> > >
> > >
Revoke change to rmgr desc of btree vacuum
Per discussion with Andres Freund
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/b6028426137532afae00188405fdecf7057b208c
Modified Files
--
src/backend/access/rmgrdesc/nbtdesc.c |2 +-
1 file changed, 1 inse
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up code for widget_in() and widget_out().
Given syntactically wrong input, widget_in() could call atof() with an
indeterminate pointer argument, typically leading to a crash; or if it
didn't do that, it might return a NULL pointer, which again would lead
to a crash since old-style C function
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Clean up some lack-of-STRICT issues in the core code, too.
A scan for missed proisstrict markings in the core code turned up
these functions:
brin_summarize_new_values
pg_stat_reset_single_table_counters
pg_stat_reset_single_function_counters
pg_create_logical_replication_slot
pg_create_physical_
Add some checks on "char"-type columns to type_sanity and opr_sanity.
I noticed that the sanity checks in the regression tests omitted to
check a couple of "poor man's enum" columns that you'd reasonably
expect them to check.
There are other "char"-type columns in system catalogs that are not
cov
Remove a useless PG_GETARG_DATUM() call from jsonb_build_array.
This loop uselessly fetched the argument after the one it's currently
looking at. No real harm is done since we couldn't possibly fetch off
the end of memory, but it's confusing to the reader.
Also remove a duplicate (and therefore
Remove a useless PG_GETARG_DATUM() call from jsonb_build_array.
This loop uselessly fetched the argument after the one it's currently
looking at. No real harm is done since we couldn't possibly fetch off
the end of memory, but it's confusing to the reader.
Also remove a duplicate (and therefore
27 matches
Mail list logo
