Fix misplaced const
These instances were apparently trying to carry the const qualifier
from the arguments through the complex casts, but for that the const
qualifier was misplaced.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c8c885b7a5c8c1175288de1d8aaec3b4ae90
On 3/25/19 8:44 AM, Alexander Korotkov wrote:
> Get rid of backtracking in jsonpath_scan.l
>
> Non-backtracking flex parsers work faster than backtracking ones. So, this
> commit gets rid of backtracking in jsonpath_scan.l. That required explicit
> handling of some cases as well as manual backt
Fix typo
Author: Daniel Gustafsson
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/05295e36ca9b40c53b7c36f5c7f75f822cd49baf
Modified Files
--
doc/src/sgml/ecpg.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Peter Eisentraut writes:
> Fix misplaced const
> These instances were apparently trying to carry the const qualifier
> from the arguments through the complex casts, but for that the const
> qualifier was misplaced.
Hmm, maybe even better to make it like this?
const char *sa = *((const ch
Andrew Dunstan writes:
> On 3/25/19 8:44 AM, Alexander Korotkov wrote:
>> Get rid of backtracking in jsonpath_scan.l
> jacana appears to be having trouble with this:
I wonder if that's related to the not-very-reproducible failures
we've seen on snapper. Can you get a stack trace?
Improve psql's \d display of foreign key constraints
When used on a partition containing foreign keys coming from one of its
ancestors, \d would (rather unhelpfully) print the details about the
pg_constraint row in the partition. This becomes a bit frustrating when
the user tries things like drop
On Tue, Mar 26, 2019 at 5:21 PM Tom Lane wrote:
> Andrew Dunstan writes:
> > On 3/25/19 8:44 AM, Alexander Korotkov wrote:
> >> Get rid of backtracking in jsonpath_scan.l
>
> > jacana appears to be having trouble with this:
>
> I wonder if that's related to the not-very-reproducible failures
> we
On 2019-Mar-26, Andrew Dunstan wrote:
> On 3/25/19 8:44 AM, Alexander Korotkov wrote:
> > Get rid of backtracking in jsonpath_scan.l
> >
> > Non-backtracking flex parsers work faster than backtracking ones. So, this
> > commit gets rid of backtracking in jsonpath_scan.l. That required explicit
>
Get rid of duplicate child RTE for a partitioned table.
We've been creating duplicate RTEs for partitioned tables just
because we do so for regular inheritance parent tables. But unlike
regular-inheritance parents which are themselves regular tables
and thus need to be scanned, partitioned tables
psql: Schema-qualify typecast in one \d query
Bug introduced in my commit bc87f22ef6ef
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/1d21ba8a9b8cb784f927a2c9c5818f8ff6779c0b
Modified Files
--
src/bin/psql/describe.c | 2 +-
1 file changed, 1 insertion(
psql: Schema-qualify typecast in one \d query
Bug introduced in my commit bc87f22ef6ef
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e46072dc397fcdde3eebe6c4963d9692058da6e3
Modified Files
--
src/bin/psql/describe.c | 2 +-
1 file changed, 1 ins
On 3/26/19 11:22 AM, Alvaro Herrera wrote:
> On 2019-Mar-26, Andrew Dunstan wrote:
>
>> On 3/25/19 8:44 AM, Alexander Korotkov wrote:
>>> Get rid of backtracking in jsonpath_scan.l
>>>
>>> Non-backtracking flex parsers work faster than backtracking ones. So, this
>>> commit gets rid of backtrack
On Mon, Mar 25, 2019 at 12:17 AM Peter Eisentraut
wrote:
> On 2019-03-25 06:07, Tom Lane wrote:
> > Buildfarm member snapper doesn't like this. I think the problem is
> > that the queries it's failing on do not bother to constrain their
> > output row order. Adding an "EXPLAIN" right there indic
Fix oversight in data-type change for autovacuum_vacuum_cost_delay.
Commit caf626b2c missed that the relevant reloptions entry needs
to be moved from the intRelOpts[] array to realRelOpts[].
Somewhat surprisingly, it seems to work anyway, perhaps because
the desired default and limit values are al
On 3/26/19 12:36 PM, Andrew Dunstan wrote:
> On 3/26/19 11:22 AM, Alvaro Herrera wrote:
>> On 2019-Mar-26, Andrew Dunstan wrote:
>>
>>> On 3/25/19 8:44 AM, Alexander Korotkov wrote:
Get rid of backtracking in jsonpath_scan.l
Non-backtracking flex parsers work faster than backtracki
Peter Geoghegan writes:
> Buildfarm member snapper is still unhappy about this:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper&dt=2019-03-26%2013%3A01%3A31
Ah, the reason's not so far to seek: Peter only fixed two of the four
queries with platform-dependent results. (Could pro
Add ORDER BY to more ICU regression test cases.
Commit c77e12208 didn't fully fix the problem. Per buildfarm
and local testing.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8994cc6ffc8828569a39139996a0b0b8348ca036
Modified Files
--
src/test/regress/
Build "other rels" of appendrel baserels in a separate step.
Up to now, otherrel RelOptInfos were built at the same time as baserel
RelOptInfos, thanks to recursion in build_simple_rel(). However,
nothing in query_planner's preprocessing cares at all about otherrels,
only baserels, so we don't re
Fix partitioned index creation bug with dropped columns
ALTER INDEX .. ATTACH PARTITION fails if the partitioned table where the
index is defined contains more dropped columns than its partition, with
this message:
ERROR: incorrect attribute map
The cause was that one caller of CompareIndexInfo
Fix partitioned index creation bug with dropped columns
ALTER INDEX .. ATTACH PARTITION fails if the partitioned table where the
index is defined contains more dropped columns than its partition, with
this message:
ERROR: incorrect attribute map
The cause was that one caller of CompareIndexInfo
Compute XID horizon for page level index vacuum on primary.
Previously the xid horizon was only computed during WAL replay. That
had two major problems:
1) It relied on knowing what the table pointed to looks like. That was
easy enough before the introducing of tableam (we knew it had to be
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Track unowned relations in doubly-linked list
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one
Switch function current_schema[s]() to be parallel-unsafe
When invoked for the first time in a session, current_schema() and
current_schemas() can finish by creating a temporary schema. Currently
those functions are parallel-safe, however if for a reason or another
they get launched across multip
Switch some palloc/memset calls to palloc0
Some code paths have been doing some allocations followed by an
immediate memset() to initialize the allocated area with zeros, this is
a bit overkill as there are already interfaces to do both things in one
call.
Author: Daniel Gustafsson
Reviewed-by: M
29 matches
Mail list logo
