Fix subtly-wrong volatility checking in BeginCopyFrom().
contain_volatile_functions() is best applied to the output of
expression_planner(), not its input, so that insertion of function
default arguments and constant-folding have been done. (See comments
at CheckMutability, for instance.) It's p
Fix subtly-wrong volatility checking in BeginCopyFrom().
contain_volatile_functions() is best applied to the output of
expression_planner(), not its input, so that insertion of function
default arguments and constant-folding have been done. (See comments
at CheckMutability, for instance.) It's p
Fix subtly-wrong volatility checking in BeginCopyFrom().
contain_volatile_functions() is best applied to the output of
expression_planner(), not its input, so that insertion of function
default arguments and constant-folding have been done. (See comments
at CheckMutability, for instance.) It's p
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Tom Lane wrote:
> Fix blatantly broken record_image_cmp() logic for pass-by-value
> fields.
>
> Doesn't anybody here pay attention to compiler warnings?
> http://git.postgresql.org/pg/commitdiff/28858811472f316f73eba0e564837088fc8c6ccd
I don't get a warning on this with either of these compiler
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due
Kevin Grittner writes:
> Tom Lane wrote:
>> Doesn't anybody here pay attention to compiler warnings?
>> http://git.postgresql.org/pg/commitdiff/28858811472f316f73eba0e564837088fc8c6ccd
> I don't get a warning on this with either of these compilers,
> either with or without asserts enabled:
Per
Add the notion of REPLICA IDENTITY for a table.
Pending patches for logical replication will use this to determine
which columns of a tuple ought to be considered as its candidate key.
Andres Freund, with minor, mostly cosmetic adjustments by me
Branch
--
master
Details
---
http://git.p
Tom Lane wrote:
> Kevin Grittner writes:
>> I don't get a warning on this with either of these compilers,
>> either with or without asserts enabled:
>
> Perhaps you built with -O0? At least in older versions of gcc, you need
> at least -O1 to get uninitialized-variable warnings. (I've heard
Kevin Grittner writes:
> Tom Lane wrote:
>> Kevin Grittner writes:
>>> I don't get a warning on this with either of these compilers,
>>> either with or without asserts enabled:
>> Perhaps you built with -O0? At least in older versions of gcc, you need
>> at least -O1 to get uninitialized-v
Fix pg_isolation_regress to work outside its build directory.
This makes it possible to, for example, use the isolation tester to
test a contrib module.
Andres Freund
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9b4d52f2095be96ca238ce41f6963ec56376491f
Modified
doc: Clarify under what circumstances pg_dump needs superuser access.
Inspired by, but different from, a patch from Ivan Lezhnjov IV
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/636b868f17a6d38c0f9e099ea8f389a555403f9e
Modified Files
--
doc/src/sgml/b
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Fix race condition in GIN posting tree page deletion.
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results
Tom Lane wrote:
> That is a serious compiler bug which you should file with your
> distro forthwith.
I distilled it down to the simplest case I could find which failed
to produce the warning; attached. Do you agree that it is a
compiler bug that this generates no warning?
Compile lines used:
g
Kevin Grittner wrote:
> I distilled it down to the simplest case I could find which
> failed to produce the warning; attached.
For a compiler which seems to like to generate warnings for really
esoteric cases, clang falls down rather badly on uninitialized
variables -- at least on the package fo
24 matches
Mail list logo
