Fix an asssortment of typos in brin_minmax_multi.c and mcv.c
Discussion:
https://postgr.es/m/caaphdvrbyjnopbws4ruhxghz7+tbjtdo-rzntsqzecuowno...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/55ba5973d9144a552661cf1fa4cbd228a3799212
Modified Files
Adjust new test case to set wal_keep_segments.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.1
Adjust new test case to set wal_keep_segments.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.1
Adjust new test case to set wal_keep_size.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.12709
Adjust new test case to set wal_keep_segments.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.1
Adjust new test case to set wal_keep_size.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.12709
Adjust new test case to set wal_keep_segments.
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion:
http://postgr.es/m/20210610.101240.1
Add some const decorations
One of these functions is new in PostgreSQL 14; might as well start it
out right.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b29fa951ec519bdde153465e2caa6c0b7b3bcfc3
Modified Files
--
src/backend/replication/logical/origi
Avoid ECPG test failures in some GSS-capable environments.
Buildfarm member hamerkop has been reporting that two cases in
connect/test5.pgc show different error messages than the test expects,
because since commit ffa2e4670 libpq's connection failure messages
are exposing the fact that a GSS-encry
On Mon, Mar 29, 2021 at 11:50 PM Amit Kapila wrote:
> Say, the worker (w-1) that acquires the XID (501) deletes the tuple
> (CTID: 0, 2). Now, another worker (w-2) reads that tuple (CTID: 0, 2),
> I think it would consider that the tuple is still visible to its
> snapshot but if the w-2 knows that
Shut down EvalPlanQual machinery when LockRows node reaches the end.
Previously, we left the EPQ sub-executor alone until ExecEndLockRows.
This caused any buffer pins or other resources that it might hold to
remain held until ExecutorEnd, which in some code paths means that
they are held till the
Rearrange logrep worker's snapshot handling some more.
It turns out that worker.c's code path for TRUNCATE was also
careless about establishing a snapshot while executing user-defined
code, allowing the checks added by commit 84f5c2908 to fail when
a trigger is fired in that context.
We could jus
Rearrange logrep worker's snapshot handling some more.
It turns out that worker.c's code path for TRUNCATE was also
careless about establishing a snapshot while executing user-defined
code, allowing the checks added by commit 84f5c2908 to fail when
a trigger is fired in that context.
We could jus
Rearrange logrep worker's snapshot handling some more.
It turns out that worker.c's code path for TRUNCATE was also
careless about establishing a snapshot while executing user-defined
code, allowing the checks added by commit 84f5c2908 to fail when
a trigger is fired in that context.
We could jus
Rearrange logrep worker's snapshot handling some more.
It turns out that worker.c's code path for TRUNCATE was also
careless about establishing a snapshot while executing user-defined
code, allowing the checks added by commit 84f5c2908 to fail when
a trigger is fired in that context.
We could jus
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other
Use the correct article for abbreviations
We've accumulated quite a mix of instances of "an SQL" and "a SQL" in the
documents. It would be good to be a bit more consistent with these.
The most recent version of the SQL standard I looked at seems to prefer
"an SQL". That seems like a good lead t
Change position of field "transformed" in struct CreateStatsStmt.
Resolve the disagreement with nodes/*funcs.c field order in favor of the
latter, which is better-aligned with the IndexStmt field order. This
field is new in v14.
Discussion: https://postgr.es/m/20210611045546.ga573...@rfd.leadboa
Rename PQtraceSetFlags() to PQsetTraceFlags().
We have a dozen PQset*() functions. PQresultSetInstanceData() and this
were the libpq setter functions having a different word order. Adopt
the majority word order.
Reviewed by Alvaro Herrera and Robert Haas, though this choice of name
was not unan
Improve psql tab completion for options of subcriptions and publications
The list of options provided by the tab completion was outdated for the
following commands:
- ALTER SUBSCRIPTION
- CREATE SUBSCRIPTION
- ALTER PUBLICATION
- CREATE PUBLICATION
Author: Vignesh C
Reviewed-by: Bharath Rupireddy
20 matches
Mail list logo
