Alexander Korotkov writes:
> On Wed, Dec 30, 2020 at 8:56 PM Tom Lane wrote:
>> Use setenv() in preference to putenv().
> Recent buildfarm failure on crake seems to be related to this commit.
Yeah, see
https://www.postgresql.org/message-id/flat/2403475.1609360967%40sss.pgh.pa.us
Hi!
On Wed, Dec 30, 2020 at 8:56 PM Tom Lane wrote:
> Use setenv() in preference to putenv().
Recent buildfarm failure on crake seems to be related to this commit.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2020-12-31%2001%3A34%3A28
pg_restore: while PROCESSING TOC:
pg_res
On Wed, Dec 30, 2020 at 4:44 AM Tom Lane wrote:
> Doc: fix up PDF build warnings from over-width table columns.
>
> Addition of multirange info to tables 8.27 and 65.1 made them start
> throwing "exceed the available area" warnings in PDF docs builds.
Thank you for fixing this!
I didn't try to bu
Get heap page max offset with buffer lock held.
On further reflection it seems better to call PageGetMaxOffsetNumber()
after acquiring a buffer lock on the page. This shouldn't really
matter, but doing it this way is cleaner.
Follow-up to commit 42288174.
Backpatch: 12-, just like commit 422881
Get heap page max offset with buffer lock held.
On further reflection it seems better to call PageGetMaxOffsetNumber()
after acquiring a buffer lock on the page. This shouldn't really
matter, but doing it this way is cleaner.
Follow-up to commit 42288174.
Backpatch: 12-, just like commit 422881
Get heap page max offset with buffer lock held.
On further reflection it seems better to call PageGetMaxOffsetNumber()
after acquiring a buffer lock on the page. This shouldn't really
matter, but doing it this way is cleaner.
Follow-up to commit 42288174.
Backpatch: 12-, just like commit 422881
Fix index deletion latestRemovedXid bug.
The logic for determining the latest removed XID for the purposes of
generating recovery conflicts in REDO routines was subtly broken. It
failed to follow links from HOT chains, and so failed to consider all
relevant heap tuple headers in some cases.
To f
Fix index deletion latestRemovedXid bug.
The logic for determining the latest removed XID for the purposes of
generating recovery conflicts in REDO routines was subtly broken. It
failed to follow links from HOT chains, and so failed to consider all
relevant heap tuple headers in some cases.
To f
Fix index deletion latestRemovedXid bug.
The logic for determining the latest removed XID for the purposes of
generating recovery conflicts in REDO routines was subtly broken. It
failed to follow links from HOT chains, and so failed to consider all
relevant heap tuple headers in some cases.
To f
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Doc: spell out comparison behaviors for the date/time types.
The behavior of cross-type comparisons among date/time data types was
not really explained anywhere. You could probably infer it if you
recognized the applicability of comments elsewhere about datatype
conversions, but it seems worthy o
Alexander Korotkov writes:
> On Wed, Dec 30, 2020 at 4:11 AM Tom Lane wrote:
>> Multiple buildfarm members are issuing similar warnings about
>> multirangetypes.c:
>> calliphoridae | 2020-12-29 23:10:11 |
>> /home/andres/build/buildfarm-calliphoridae/HEAD/pgsql.build/../pgsql/src/backend/utils/a
More fixups for pg_upgrade cross-version tests.
Commit 7ca37fb04 removed regress_putenv from the regress.so library,
so reloading a SQL function dependent on that would not work.
Fix similarly to 52202bb39.
Per buildfarm.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commit
On Wed, Dec 30, 2020 at 4:11 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > Multirange datatypes
>
> Multiple buildfarm members are issuing similar warnings about
> multirangetypes.c:
>
> calliphoridae | 2020-12-29 23:10:11 |
> /home/andres/build/buildfarm-calliphoridae/HEAD/pgsql.build/..
Refactor multirange_in()
This commit preserves the logic of multirange_in() but makes it more clear
what's going on. Also, this commit fixes the compiler warning spotted by the
buildfarm.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/2246043.1609290699%40sss.pgh.pa.us
Branch
--
mast
Use setenv() in preference to putenv().
Since at least 2001 we've used putenv() and avoided setenv(), on the
grounds that the latter was unportable and not in POSIX. However,
POSIX added it that same year, and by now the situation has reversed:
setenv() is probably more portable than putenv(), si
On Wed, Dec 30, 2020 at 11:08 AM Alexander Korotkov
wrote:
> On Wed, Dec 30, 2020 at 10:04 AM Michael Paquier wrote:
> > The buildfarm got a bit angry after this commit:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clam&dt=2020-12-30%2003%3A00%3A11
> >
> > Here is a diff from membe
Fix selectivity estimation @> (anymultirange, anyrange) operator
Attempt to get selectivity estimation for @> (anymultirange, anyrange) operator
caused an error in buildfarm, because this operator was missed in switch()
of calc_hist_selectivity(). Fix that and also make regression tests reliably
Fix up usage of krb_server_keyfile GUC parameter.
secure_open_gssapi() installed the krb_server_keyfile setting as
KRB5_KTNAME unconditionally, so long as it's not empty. However,
pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already,
leading to a troubling inconsistency: in theor
Fix up usage of krb_server_keyfile GUC parameter.
secure_open_gssapi() installed the krb_server_keyfile setting as
KRB5_KTNAME unconditionally, so long as it's not empty. However,
pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already,
leading to a troubling inconsistency: in theor
Fix up usage of krb_server_keyfile GUC parameter.
secure_open_gssapi() installed the krb_server_keyfile setting as
KRB5_KTNAME unconditionally, so long as it's not empty. However,
pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already,
leading to a troubling inconsistency: in theor
Sanitize IF NOT EXISTS in EXPLAIN for CTAS and matviews
IF NOT EXISTS was ignored when specified in an EXPLAIN query for CREATE
MATERIALIZED VIEW or CREATE TABLE AS. Hence, if this clause was
specified, the caller would get a failure if the relation already
exists instead of a success with a NOTI
Extend the output plugin API to allow decoding of prepared xacts.
This adds six methods to the output plugin API, adding support for
streaming changes of two-phase transactions at prepare time.
* begin_prepare
* filter_prepare
* prepare
* commit_prepared
* rollback_prepared
* stream_prepare
Most
In pg_upgrade cross-version test, handle lack of oldstyle_length().
This suffices for testing v12 -> v13; some other version pairs need more
changes. Back-patch to v10, which removed the function.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/60549300dfd89
In pg_upgrade cross-version test, handle lack of oldstyle_length().
This suffices for testing v12 -> v13; some other version pairs need more
changes. Back-patch to v10, which removed the function.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/52202bb396b1e96c43bf
In pg_upgrade cross-version test, handle lack of oldstyle_length().
This suffices for testing v12 -> v13; some other version pairs need more
changes. Back-patch to v10, which removed the function.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/635140ace0b84
In pg_upgrade cross-version test, handle lack of oldstyle_length().
This suffices for testing v12 -> v13; some other version pairs need more
changes. Back-patch to v10, which removed the function.
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/5c3444e31384d
In pg_upgrade cross-version test, handle lack of oldstyle_length().
This suffices for testing v12 -> v13; some other version pairs need more
changes. Back-patch to v10, which removed the function.
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/239213684d01a
In pg_upgrade cross-version test, handle postfix operators.
Commit 1ed6b895634ce0dc5fd4bd040e87252b32182cba eliminated support for
them, so drop them from regression databases before upgrading. This is
necessary but not sufficient for testing v13 -> v14 upgrades.
Discussion: https://postgr.es/m/
On Wed, Dec 30, 2020 at 10:04 AM Michael Paquier wrote:
> On Tue, Dec 29, 2020 at 11:53:14PM +0300, Alexander Korotkov wrote:
> > On Tue, Dec 29, 2020 at 11:45 PM Alexander Korotkov
> > wrote:
> >> Add support of multirange matching to the existing range GiST indexes
> >
> > I accidentally squas
35 matches
Mail list logo
