Fix crash in psql when attempting to reuse old connection
In a psql session, if the connection to the server is abruptly cut, the
referenced connection would become NULL as of CheckConnection(). This
could cause a hard crash with psql if attempting to connect by reusing
the past connection's data
Fix crash in psql when attempting to reuse old connection
In a psql session, if the connection to the server is abruptly cut, the
referenced connection would become NULL as of CheckConnection(). This
could cause a hard crash with psql if attempting to connect by reusing
the past connection's data
Fix coverity complaint about commit 40d964ec99.
The coverity complained that dividing integer expressions and then
converting the integer quotient to type "double" would lose fractional
part. Typecasting one of the arguments of expression with double should
fix the report.
Author: Mahendra Singh
On Tue, 31 Mar 2020 at 17:28, Amit Kapila wrote:
>
> On Mon, Mar 30, 2020 at 8:30 AM Mahendra Singh Thalor
> wrote:
> >
> > > > > 2077 if ((shared_balance >= VacuumCostLimit) &&
> > > > > >>> CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION)
> > > > > >>> Dividing int
psql: do file completion for \gx
This was missed when the feature was added.
Reported-by: Vik Fearing
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 10
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/comm
psql: do file completion for \gx
This was missed when the feature was added.
Reported-by: Vik Fearing
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 10
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/comm
psql: do file completion for \gx
This was missed when the feature was added.
Reported-by: Vik Fearing
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 10
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/
psql: do file completion for \gx
This was missed when the feature was added.
Reported-by: Vik Fearing
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 10
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/comm
makefile: use proper linker flags for C++ compiles
Add CFLAGS_SL flags for C++ compiles, which adds needed -fPIC linker
flag.
Reported-by: Oleksii Kliukin
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 10 only
Branch
--
REL_10_STABLE
Add -c/--restore-target-wal to pg_rewind
pg_rewind needs to copy from the source cluster to the target cluster a
set of relation blocks changed from the previous checkpoint where WAL
forked up to the end of WAL on the target. Building this list of
relation blocks requires a range of WAL segments
David Rowley writes:
> Can you share which failure you're talking about here? All of the
> ones I've looked at were failing post-ANALYZE.
It's what I posted yesterday:
diff -U3 /usr/home/tgl/pgsql/src/test/regress/expected/stats_ext.out
/usr/home/tgl/pgsql/src/test/regress/results/stats_ext.ou
On Wed, 1 Apr 2020 at 13:00, Tom Lane wrote:
>
> David Rowley writes:
> > On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
> >> Now this *IS* autovacuum interference, but it's hardly autovacuum's fault:
> >> the test script is supposing that autovac won't come in before it does a
> >> manual analyz
David Rowley writes:
> On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
>> Now this *IS* autovacuum interference, but it's hardly autovacuum's fault:
>> the test script is supposing that autovac won't come in before it does a
>> manual analyze, and that's just unsafe on its face.
> Why would that m
On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
> I've been trying to reproduce this by dint of running just the stats_ext
> script, over and over in a loop. I've not had any success on fast
> machines, but on a slow one (florican's host) I got this after a few
> hundred iterations:
I've had a 13
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: remove mention of bitwise operators as solely type-limited
There are other operators that have limited number data type support, so
just remove the sentence.
Reported-by: Sergei Agalakov
Discussion:
https://postgr.es/m/[email protected]
Backp
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify hierarchy of objects: global, db, schema, etc.
The previous wording was confusing because it wasn't in decreasing order
and had to backtrack. Also clarify role/user wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/158057750885.1123.2806779262588618...@wrigley
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
(Uses wording "rolled back to".)
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: restore wording from recent patch "rolled back to"
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 - 12
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/43e0c388cf9b61d3215fe6570384230e8a2c8c11
doc: restore wording from recent patch "rolled back to"
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 - 12
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a1e42d8cd90292ed4667b1cacfc503a1feca449f
doc: restore wording from recent patch "rolled back to"
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 - 12
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f0862643ee6ba04a719f71c1d739a5395525b812
doc: restore wording from recent patch "rolled back to"
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 - 12
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e564c17d2aa283262bc8ee5a12bdd5ce70fa2afd
doc: restore wording from recent patch "rolled back to"
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 - 12
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b9d94670c1d9b9a6604bb5cd80f77e93aee4e776
Add CREATE INDEX deduplication assertions.
Add two assertions that verify the assumptions about posting list tuple
space accounting and suffix truncation made within nbtsort.c.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7dbe290da446544a04ace7d342841070f062a0ed
On Tue, Mar 31, 2020 at 05:34:50PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > dummy commit
>
> Uh, what?
>
> Also, I disagree with your change of the wording about savepoint
> rollbacks. I agree that "if the savepoint is rolled back to"
> is a bit awkward, but I think dropping the "to"
Bruce Momjian writes:
> dummy commit
Uh, what?
Also, I disagree with your change of the wording about savepoint
rollbacks. I agree that "if the savepoint is rolled back to"
is a bit awkward, but I think dropping the "to" is flat wrong.
The savepoint is a point you roll back to, it doesn't itsel
Revert erroroneous commit 834b80464d; my apologies
Backpatch-through: master
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c2da793fd28073603c39d7abfffbc203a9bd4ac0
Modified Files
--
doc/src/sgml/mvcc.sgml | 9 +++--
1 file changed, 3 insertions(+)
My apologies for this commit; it will be reverted now.
---
On Tue, Mar 31, 2020 at 09:27:40PM +, Bruce Momjian wrote:
> dummy commit
>
> Branch
> --
> master
>
> Details
> ---
> https://git.postgresql.org/pg/
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_12_STABLE
dummy commit
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/834b80464d653c976787f5b5849fa0595678d0a0
Modified Files
--
doc/src/sgml/mvcc.sgml | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_10_STABLE
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_5_STABLE
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_6_STABLE
doc: clarify when row-level locks are released
They are released just like table-level locks. Also clean up wording.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_11_STABLE
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_12_
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_10_
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
master
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_11_
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_6_
doc: add namespace column to pg_buffercache example query
Without the namespace, the table name could be ambiguous.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_5_
doc: clarify which table creation is used for inheritance part.
Previously people might assume that the partition syntax version of
CREATE TABLE is to be used for the inheritance partition table example;
mention that the non-partitioned version should be used.
Reported-by: [email protected]
Discussio
doc: clarify which table creation is used for inheritance part.
Previously people might assume that the partition syntax version of
CREATE TABLE is to be used for the inheritance partition table example;
mention that the non-partitioned version should be used.
Reported-by: [email protected]
Discussio
doc: clarify which table creation is used for inheritance part.
Previously people might assume that the partition syntax version of
CREATE TABLE is to be used for the inheritance partition table example;
mention that the non-partitioned version should be used.
Reported-by: [email protected]
Discussio
doc: clarify which table creation is used for inheritance part.
Previously people might assume that the partition syntax version of
CREATE TABLE is to be used for the inheritance partition table example;
mention that the non-partitioned version should be used.
Reported-by: [email protected]
Discussio
Fix race condition in statext_store().
Must hold some lock on the pg_statistic_ext_data catalog *before*
we look up the tuple we aim to replace. Otherwise a concurrent
VACUUM FULL or similar operation could move it to a different TID,
leaving us trying to replace the wrong tuple.
Back-patch to v
Fix race condition in statext_store().
Must hold some lock on the pg_statistic_ext_data catalog *before*
we look up the tuple we aim to replace. Otherwise a concurrent
VACUUM FULL or similar operation could move it to a different TID,
leaving us trying to replace the wrong tuple.
Back-patch to v
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_6_STABLE
Details
---
https://g
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_11_STABLE
Details
---
https://g
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_12_STABLE
Details
---
https://g
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
master
Details
---
https://git.post
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL9_5_STABLE
Details
---
https://g
doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM
Previously the syntax and wording were unclear.
Reported-by: Alexey Bashtanov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
Branch
--
REL_10_STABLE
Details
---
https://g
Still another try at stabilizing stats_ext test results.
The stats_ext test is not expecting that autovacuum will touch
any of its tables; an expectation falsified by commit b07642dbc.
Although I'm suspicious that there's something else going on that
makes extended stats estimates not 100% reprodu
Remove header noise from test_decoding test
Use psql's expanded output to avoid a pointless header.
Kyotaro Horiguchi, after an idea of Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdif
Improve the message logged when recovery is paused.
When recovery target is reached and recovery is paused because of
recovery_target_action=pause, executing pg_wal_replay_resume() causes
the standby to promote, i.e., the recovery to end. So, in this case,
the previous message "Execute pg_wal_repl
Allow ecpg to be built stand-alone, allow parallel libpq make
This change defines SHLIB_PREREQS for the libpgport dependency, rather
than using a makefile rule. This was broken in PG 12.
Reported-by: Filip Janus
Discussion:
https://postgr.es/m/[email protected]
Allow ecpg to be built stand-alone, allow parallel libpq make
This change defines SHLIB_PREREQS for the libpgport dependency, rather
than using a makefile rule. This was broken in PG 12.
Reported-by: Filip Janus
Discussion:
https://postgr.es/m/[email protected]
Teach pg_ls_dir_files() to ignore ENOENT failures from stat().
Buildfarm experience shows that this function can fail with ENOENT
if some other process unlinks a file between when we read the directory
entry and when we try to stat() it. The problem is old but we had
not noticed it until 085b6b66
Teach pg_ls_dir_files() to ignore ENOENT failures from stat().
Buildfarm experience shows that this function can fail with ENOENT
if some other process unlinks a file between when we read the directory
entry and when we try to stat() it. The problem is old but we had
not noticed it until 085b6b66
Teach pg_ls_dir_files() to ignore ENOENT failures from stat().
Buildfarm experience shows that this function can fail with ENOENT
if some other process unlinks a file between when we read the directory
entry and when we try to stat() it. The problem is old but we had
not noticed it until 085b6b66
Teach pg_ls_dir_files() to ignore ENOENT failures from stat().
Buildfarm experience shows that this function can fail with ENOENT
if some other process unlinks a file between when we read the directory
entry and when we try to stat() it. The problem is old but we had
not noticed it until 085b6b66
Back-patch addition of stack overflow and interrupt checks for lquery.
Experimentation shows that it's not hard at all to drive the
old implementation of "ltree ~ lquery" match to stack overflow,
so throw in a check_stack_depth() call, as I just did in HEAD.
I wasn't able to make it take a long t
Back-patch addition of stack overflow and interrupt checks for lquery.
Experimentation shows that it's not hard at all to drive the
old implementation of "ltree ~ lquery" match to stack overflow,
so throw in a check_stack_depth() call, as I just did in HEAD.
I wasn't able to make it take a long t
Back-patch addition of stack overflow and interrupt checks for lquery.
Experimentation shows that it's not hard at all to drive the
old implementation of "ltree ~ lquery" match to stack overflow,
so throw in a check_stack_depth() call, as I just did in HEAD.
I wasn't able to make it take a long t
Back-patch addition of stack overflow and interrupt checks for lquery.
Experimentation shows that it's not hard at all to drive the
old implementation of "ltree ~ lquery" match to stack overflow,
so throw in a check_stack_depth() call, as I just did in HEAD.
I wasn't able to make it take a long t
Back-patch addition of stack overflow and interrupt checks for lquery.
Experimentation shows that it's not hard at all to drive the
old implementation of "ltree ~ lquery" match to stack overflow,
so throw in a check_stack_depth() call, as I just did in HEAD.
I wasn't able to make it take a long t
Fix lquery's NOT handling, and add ability to quantify non-'*' items.
The existing implementation of the ltree ~ lquery match operator is
sufficiently complex and undocumented that it's hard to tell exactly
what it does. But one thing it clearly gets wrong is the combination
of NOT symbols (!) an
Improve error messages in ltree_in and lquery_in.
Ensure that the type name is mentioned in all cases (bare "syntax error"
isn't that helpful). Avoid using the term "level", since that's not
used in the documentation. Phrase error position reports as "at
character N" not "in position N"; the lat
Improve error reporting in opclasscmds.c
This commit improves error reporting introduced by 911e702077. It puts
argument of errmsg() to the single line for easier grepping source for error
text. Also it improves wording of errhint().
Branch
--
master
Details
---
https://git.postgresql.
Fix assorted typos
Author: Daniel Gustafsson
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/087d3d0583cf292146a7385746d1f5b53eeeaee6
Modified Files
--
doc/src/sgml/ref/psql-ref.sgml | 4 ++--
src/backend/storage/ipc/procarray.c | 2 +-
src/backen
On Mon, Mar 30, 2020 at 8:30 AM Mahendra Singh Thalor
wrote:
>
> > > > 2077 if ((shared_balance >= VacuumCostLimit) &&
> > > > >>> CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION)
> > > > >>> Dividing integer expressions "VacuumCostLimit" and "nworkers",
> > > > >>>
Hi,
On March 31, 2020 12:43:47 AM PDT, Mahendra Singh Thalor
wrote:
>On Mon, 30 Mar 2020 at 09:44, Amit Kapila
>wrote:
>>
>> On Mon, Mar 30, 2020 at 4:18 AM Andres Freund
>wrote:
>> >
>> > > 2076
>> > > 2077 if ((shared_balance >= VacuumCostLimit) &&
>> > > >>> CID ...: Incorrec
On Mon, 30 Mar 2020 at 09:44, Amit Kapila wrote:
>
> On Mon, Mar 30, 2020 at 4:18 AM Andres Freund wrote:
> >
> > > 2076
> > > 2077 if ((shared_balance >= VacuumCostLimit) &&
> > > >>> CID ...: Incorrect expression (UNINTENDED_INTEGER_DIVISION)
> > > >>> Dividing integer expres
82 matches
Mail list logo
