RE: [External] Simple way to simulate a bug in logical replication

Please note: I tried it also with Postgres 15.6 and the behavior is the same I'm running inside docker. I do not know if it matters... Hi All, I think I hit a bug in logical replication in version 15.2. I sync two tables of size 305MB but pg_stat_progress_copy shows that 5GB

Re: Simple way to simulate a bug in logical replication

On Tue, Mar 12, 2024 at 11:16 AM Avi Weinberg wrote: > Hi All, > > > > I think I hit a bug in logical replication in version 15.2. > But 15.6 is the latest version. Maybe it's been fixed since then.

Simple way to simulate a bug in logical replication

Hi All, I think I hit a bug in logical replication in version 15.2. I sync two tables of size 305MB but pg_stat_progress_copy shows that 5GB as bytes_processed and the sync takes forever. Is this a bug? If so, what can I do with this scenario? Thanks Create a dummy table CREATE TABLE

bug/confusion with pg_log_standby_snapshot()

Is pg_log_standby_snapshot() expected to cause a WAL segment to be emitted in an otherwise idle system? In my lab setup, the primary did not, despite invoking pg_log_standby_snapshot() on it, even when several times the archive_timeout value passed after using that function. The setup was all

Re: Postgresql BUG / Help Needed

Reply to list also. Ccing list. On 2/1/24 09:11, Johnathan Tiamoh wrote: No. I  have done any of this in the present cluster, I'm facing this issue. Do you have some sort of replication or backup system running on this cluster? -- Adrian Klaver adrian.kla...@aklaver.com

Re: Postgresql BUG / Help Needed

On 2/1/24 06:10, Johnathan Tiamoh wrote: I haven't had difficulties in this cluster recently. However I upgraded it from  version 9.5 to 14.10  about 3 weeks ago. Have you being doing any of the things that got you in trouble in this thread:

Re: Postgresql BUG / Help Needed

I haven't had difficulties in this cluster recently. However I upgraded it from version 9.5 to 14.10 about 3 weeks ago. On Thu, Feb 1, 2024 at 9:06 AM Jehan-Guillaume de Rorthais wrote: > On Thu, 1 Feb 2024 08:28:45 -0500 > Johnathan Tiamoh wrote: > > > Thank you Laurenz! > > > > Is there

Re: Postgresql BUG / Help Needed

On Thu, 1 Feb 2024 08:28:45 -0500 Johnathan Tiamoh wrote: > Thank you Laurenz! > > Is there a way of preventing this from happening ? This could either come from a hardware issue, or easily from your own actions or procedures. Did you have some difficulties with your instance lately?

Re: Postgresql BUG / Help Needed

Thank you Laurenz! Is there a way of preventing this from happening ? On Thu, Feb 1, 2024 at 2:36 AM Laurenz Albe wrote: > On Thu, 2024-02-01 at 00:48 -0500, Johnathan Tiamoh wrote: > > I am having the following issue below. Please, I need help to fix it. > > > > ERROR: could not access

Re: Postgresql BUG / Help Needed

On Thu, 2024-02-01 at 00:48 -0500, Johnathan Tiamoh wrote: > I am having the  following issue below.  Please, I need help to fix it. > > ERROR:  could not access status of transaction 756525298 > Could not open file "pg_xact/02C8": No such file or directory. That is data corruption, and you

Postgresql BUG / Help Needed

Hello, I am having the following issue below. Please, I need help to fix it. [image: User] *ERROR: could not access status of transaction 756525298* *Could not open file "pg_xact/02C8": No such file or directory.* Thank You Johnathan T

Re: Weirdness (bug?) with aggregates and subqueries

On Wed, 2023-11-08 at 16:36 -0500, Tom Lane wrote: > Laurenz Albe writes: > > I found this in a blog > > (https://buttondown.email/jaffray/archive/sql-scoping-is-surprisingly-subtle-and-semantic/): > > CREATE TABLE aa (a INT); > > INSERT INTO aa VALUES (1), (2), (3); > > CREATE TABLE xx (x

Re: Weirdness (bug?) with aggregates and subqueries

Laurenz Albe writes: > I found this in a blog > (https://buttondown.email/jaffray/archive/sql-scoping-is-surprisingly-subtle-and-semantic/): > CREATE TABLE aa (a INT); > INSERT INTO aa VALUES (1), (2), (3); > CREATE TABLE xx (x INT); > INSERT INTO xx VALUES (10), (20), (30); > SELECT

Weirdness (bug?) with aggregates and subqueries

I found this in a blog (https://buttondown.email/jaffray/archive/sql-scoping-is-surprisingly-subtle-and-semantic/): CREATE TABLE aa (a INT); INSERT INTO aa VALUES (1), (2), (3); CREATE TABLE xx (x INT); INSERT INTO xx VALUES (10), (20), (30); SELECT (SELECT sum(a) FROM xx LIMIT 1)

Re: [bug]? insert returning composite type fails

Adrian come on 來 This is a reduced example. The real usecase involves many tables with the bitemporal record However I solved using a record type ... Il ven 7 lug 2023, 01:20 Adrian Klaver ha scritto: > On 7/6/23 14:52, Lorusso Domenico wrote: > > Hello guys, > > In my db (version 15) I've

Re: [bug]? insert returning composite type fails

On 7/6/23 14:52, Lorusso Domenico wrote: Hello guys, In my db (version 15) I've defined a composite type with some domains CREATE DOMAIN my_feat.audit_record_jsonb_domain     AS jsonb     NOT NULL; ALTER DOMAIN my_feat.audit_record_jsonb_domain OWNER TO postgres; CREATE DOMAIN

Re: [bug]? insert returning composite type fails

On Thursday, July 6, 2023, Lorusso Domenico wrote: > > returning bt_info into _bt_info; > > I think it’s “returning (bt_info).* into _bt_info;” David J.

[bug]? insert returning composite type fails

l: "("[""2023-07-06 23:50:30.991122+02"",infinity)","[""2023-07-06 23:50:30.991122+02"",infinity)",,"{""user_id"": ""alpha""}",t)" SQL state: 22P02 Detail: Too many commas. It seems to be a bug, but maybe there is a workaround; any idea? -- Domenico L. per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.]

Re: bug or lacking doc hint

On Mon, Jun 26, 2023 at 4:21 PM Marc Millas wrote: > On Mon, Jun 26, 2023 at 4:05 PM Ron wrote: > >> On 6/26/23 07:22, Marc Millas wrote: >> >> On Mon, Jun 26, 2023 at 5:47 AM Avin Kavish wrote: >> >>> Sounds like the problem you are having is, the server is running out of >>> temporary

Re: bug or lacking doc hint

On Mon, Jun 26, 2023 at 4:05 PM Ron wrote: > On 6/26/23 07:22, Marc Millas wrote: > > > > On Mon, Jun 26, 2023 at 5:47 AM Avin Kavish wrote: > >> Sounds like the problem you are having is, the server is running out of >> temporary resources for the operation that users are trying to do. So >>

Re: bug or lacking doc hint

On 6/26/23 07:22, Marc Millas wrote: On Mon, Jun 26, 2023 at 5:47 AM Avin Kavish wrote: Sounds like the problem you are having is, the server is running out of temporary resources for the operation that users are trying to do. So according to Tom, on the postgres side, the

Re: bug or lacking doc hint

On Mon, Jun 26, 2023 at 5:47 AM Avin Kavish wrote: > Sounds like the problem you are having is, the server is running out of > temporary resources for the operation that users are trying to do. So > according to Tom, on the postgres side, the operation cannot be optimized > further. > > I think

Re: bug or lacking doc hint

Sounds like the problem you are having is, the server is running out of temporary resources for the operation that users are trying to do. So according to Tom, on the postgres side, the operation cannot be optimized further. I think you have few choices here, - See if increasing the resources

Re: bug or lacking doc hint

On Sun, Jun 25, 2023 at 11:48 PM Tom Lane wrote: > David Rowley writes: > > The problem is that out of the 3 methods PostgreSQL uses to join > > tables, only 1 of them supports join conditions with an OR clause. > > Merge Join cannot do this because results can only be ordered one way > > at a

Re: bug or lacking doc hint

David Rowley writes: > The problem is that out of the 3 methods PostgreSQL uses to join > tables, only 1 of them supports join conditions with an OR clause. > Merge Join cannot do this because results can only be ordered one way > at a time. Hash Join technically could do this, but it would

Re: bug or lacking doc hint

was a set > of intricate joins. > > > > > > So, either this behaviour ( postgres unable to find an appropriate plan > for join with OR clauses) > > is a true bug which is waiting to be corrected, either the doc is > lacking a chapter on which one can

Re: bug or lacking doc hint

aviour ( postgres unable to find an appropriate plan for > join with OR clauses) > is a true bug which is waiting to be corrected, either the doc is lacking a > chapter on which one can read that Postgres does NOT support that syntax as > soon as there is some data volumes. The

Re: bug or lacking doc hint

On 6/25/23 10:01, Marc Millas wrote: Hi, I have had a perf (++) pb with a join plan  cf the pb with join plan thread. I did simplify the thing up to when its a simple join between a 15M lines table and a 30k lines table. if I put in the on part something like table1.a=table2.b, Postgres does

bug or lacking doc hint

complex as the original SQL was a set of intricate joins. So, either this behaviour ( postgres unable to find an appropriate plan for join with OR clauses) is a true bug which is waiting to be corrected, either the doc is lacking a chapter on which one can read that Postgres does NOT support

Re: Is there a bug in psql? (SELECT ''';)

control-D to quit. postgres'# \q Use control-D to quit. postgres'# \q bash-5.1$ And I do another test postgres=# SELECT '''; postgres'# exit Use control-D to quit. postgres'# \q Use control-D to quit. postgres'# \q bash-5.1$ Is there a bug in psql? See https://www.postgresql.org/docs/current/sql

Re: Is there a bug in psql? (SELECT ''';)

On Wed, May 31, 2023 at 03:17:14PM +0800, Wen Yi wrote: > Hi team, > when I learn the postgres, I try to store the ' into the database, > > but something unexpected happend. > > > postgres=# CREATE TABLE test (str varchar); > CREATE TABLE > postgres=# INSERT INTO test values ('''); >

AW: Is there a bug in psql? (SELECT ''';)

You have to mask the single quote: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS Von: Wen Yi <896634...@qq.com> Gesendet: Mittwoch, 31. Mai 2023 09:17 An: pgsql-general Betreff: Is there a bug in psql? (SELECT ''';) Hi team, when I learn the postg

Is there a bug in psql? (SELECT ''';)

Use control-D to quit. postgres'# \q bash-5.1$ And I do another test postgres=# SELECT '''; postgres'# exit Use control-D to quit. postgres'# \q Use control-D to quit. postgres'# \q bash-5.1$ Is there a bug in psql? Yours, Wen Yi

Re: Possible old and fixed bug in Postgres?

Steve Rogerson writes: > That's the one. I can't see which pg version(s) this turned up in. The pg_time_t change was in 8.0, the later one to support 64-bit tzdata was in 8.4. regards, tom lane

Re: Possible old and fixed bug in Postgres?

2023年4月6日(木) 0:02 Steve Rogerson : > > On 05/04/2023 11:23, Erik Wienhold wrote: > > Judging by the commit message and changed test cases, probably: > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 > > > That's the one. I can't see

Re: Possible old and fixed bug in Postgres?

On 05/04/2023 11:23, Erik Wienhold wrote: Judging by the commit message and changed test cases, probably: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 That's the one. I can't see which pg version(s) this turned up in.

Re: Possible old and fixed bug in Postgres?

t; ... >> These seemed correct to me. I'm guessing this might have been a bug/feature >> of >> pg in the long ago. > Judging by the commit message and changed test cases, probably: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5f

Re: Possible old and fixed bug in Postgres?

>  1900-01-01 00:00:00-06 > (1 row) > > and > > select '2040-01-01 00:00:00'::timestamptz; >   timestamptz > >  2040-01-01 00:00:00-06 > > > These seemed correct to me. I'm guessing this might have been a bug/feature > of

Possible old and fixed bug in Postgres?

 2040-01-01 00:00:00-06 These seemed correct to me. I'm guessing this might have been a bug/feature of pg in the long ago. Steve

minor bug

Hi, not sure if this is known behavior. Server version is 14.6 (Debian 14.6-1.pgdg110+1). In a PITR setup I have these settings: recovery_target_xid = '852381' recovery_target_inclusive = 'false' In the log file I see this message: LOG: recovery stopping before commit of transaction 852381,

Re: possible bug

On 2022-Oct-21, Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: > >> on a diff note, is the word memoize inspired from Perl Module memoize > >> which use to do the same thing. > > > It is a general functional programming concept - not sure

Re: possible bug

On Fri, Oct 21, 2022 at 6:09 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna > wrote: > >> on a diff note, is the word memoize inspired from Perl Module memoize > >> which use to do the same thing. > > > It is a general functional programming

Re: possible bug

"David G. Johnston" writes: > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: >> on a diff note, is the word memoize inspired from Perl Module memoize >> which use to do the same thing. > It is a general functional programming concept - not sure on the history > but probably academic and

Re: possible bug

On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: > on a diff note, is the word memoize inspired from Perl Module memoize > which use to > do the same thing. > It is a general functional programming concept - not sure on the history but probably academic and thus Perl and others picked it up

Re: possible bug

on a diff note, is the word memoize inspired from Perl Module memoize which use todo the same thing.

Re: possible bug

Les writes: > As always, you hit the nail on the head. set enable_memoize = on fixes the > problem! > Version is PostgreSQL 14.1, time to upgrade... Yup, very likely fixed by c2dc7b9e1 then. > I'm sorry that I wasted your time. No need to apologize, it was a

Re: possible bug

> Which PG version is this exactly? Given the Memoize node shown > in your plan, I suppose 14.something, but is it up to date? > There were Memoize-related bug fixes in 14.2 and 14.4, and the > one in 14.2 looks particularly likely to be relevant. > > If you are on the current m

Re: possible bug

r plan, I suppose 14.something, but is it up to date? There were Memoize-related bug fixes in 14.2 and 14.4, and the one in 14.2 looks particularly likely to be relevant. If you are on the current minor release, does "set enable_memoize = off" change the behavior? regards, tom lane

Re: possible bug

> > > > So what happens if query the table directly?: > > select * from wf.workflow where head_table_id::float8::int8 = 25408438504; > > vs > > select * from wf.workflow where head_table_id = 25408438504; > > Both return lots of rows. The same number of rows. select count(*) from wf.workflow

Re: possible bug

On 10/21/22 10:57 AM, Les wrote: One of my colleagues pointed out, that they query returns a different result, if I cast the head_table_id condition to float8 and then back to int8. SELECT c.id ,     tt.code,     c.regno,     (         select count(*)         FROM

Re: possible bug

ata. The problem is 100% > > repeatable, if I query two rows from the same view, then I get different > > data for one of the rows. > > > > I suspect that this is a bug. But I might be wrong. Please help me! > > I suspect an index problem. Have you tr

Re: possible bug

The problem: value of col_3 changes for id=26643094740 if I query two rows > vs. one row. This is without changing any data. The problem is 100% > repeatable, if I query two rows from the same view, then I get different > data for one of the rows. > > I suspect that this is

Re: possible bug

| 2905|    0| The problem: value of col_3 changes for id=26643094740 if I query two rows vs. one row. This is without changing any data. The problem is 100% repeatable, if I query two rows from the same view, then I get different data for one of the rows. I suspect that this is a bug. But I might

possible bug

changes for id=26643094740 if I query two rows vs. one row. This is without changing any data. The problem is 100% repeatable, if I query two rows from the same view, then I get different data for one of the rows. I suspect that this is a bug. But I might be wrong. Please help me! The actual test

Re: BUG #17567: Unable to Set Max_Connection in Postgresql which has replicas

Hey, It is not a bug. If you are using patroni, you should change your parameters in patroni configuration yaml file, so the changes are reflected in your Distributed Configuration Store. If you would look at the Patroni documentation ( https://patroni.readthedocs.io/en/latest/SETTINGS.html) you

Re: BUG #17567: Unable to Set Max_Connection in Postgresql which has replicas

. Please advise us on the steps on how to configure and set Max_Connections in Replica DB servers. Thanks & Regards, Poornima V On Wed, Aug 3, 2022 at 4:43 PM Juan José Santamaría Flecha < juanjo.santama...@gmail.com> wrote: > > On Wed, Aug 3, 2022 at 12:48 PM PG Bug reporti

Re: postgresql bug

## m...@ft-c.de (m...@ft-c.de): > /usr/local/bin/postgres -V > ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by > "postgres" You screwd up your upgrades: that postgres binary was built against ICU 70, but as hou have shown you have ICU 71 installed: > find / -name

Re: postgresql bug

On Fri, 2022-07-08 at 12:47 +0200, m...@ft-c.de wrote: > there is a postgresql bug An error need not be a bug. > /usr/local/bin/postgres -V > ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by > "postgres" > > Installed Version: > p

postgresql bug

Hallo, there is a postgresql bug /usr/local/bin/postgres -V ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by "postgres" Installed Version: postgresql14-server-14.1 find / -name "*libicui*" /usr/local/lib/libicuio.a /usr/local/lib/libicui18n.so

Re: Unexpected result from ALTER FUNCTION— looks like a bug

On Wed, Apr 20, 2022 at 10:54 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > > > https://github.com/postgres/postgres/commit/344a225cb9d42f20df063e4d0e0d4559c5de7910 > > (I haven't figured out what the official way to reference a commit is, I > use the GitHub clone for research so

Re: Unexpected result from ALTER FUNCTION— looks like a bug

nses to mean that the testcase I > showed is considered to be evidence of a bug (i.e. there are no semantic > restrictions) and that fix(es) are under consideration. The test case was good. I made an uninformed assumption that proved to be untrue. The patch was written and applied

Re: Unexpected result from ALTER FUNCTION— looks like a bug

ase I showed is considered to be evidence of a bug (i.e. there are no semantic restrictions) and that fix(es) are under consideration. I agree that, as long as you know about the bug, it's trivial to achieve your intended effect using two successive "alter function" statements (und

Re: Re: Unexpected result from ALTER FUNCTION— looks like a bug

"David G. Johnston" writes: > Might I suggest the following: > + /* > + * For each action, modify procForm to type-safely set the new value. > + * However, because the SET clause is repeatable we handle it > + * a bit differently, modifying the underlying tuple directly. So > + * make sure to

Re: Unexpected result from ALTER FUNCTION— looks like a bug

+--+--+-+----+ > f > > >| func | invoker | {TimeZone=UTC} > > >| stable | restricted* > > > > > > This is the bug. > > > > > >

Re: Unexpected result from ALTER FUNCTION— looks like a bug

On Tue, Apr 19, 2022 at 11:06:30PM -0400, Tom Lane wrote: > Julien Rouhaud writes: > > On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote: > >> > >> AFAICT the problem is that SET / RESET part is messing with the > >> HeapTuple, so you can't use the procForm reference afterwards.

Re: Unexpected result from ALTER FUNCTION— looks like a bug

Julien Rouhaud writes: > On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote: >> >> AFAICT the problem is that SET / RESET part is messing with the >> HeapTuple, so you can't use the procForm reference afterwards. Simply >> processing parallel_item before set_items fixes the problem,

Re: Unexpected result from ALTER FUNCTION— looks like a bug

On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote: > > AFAICT the problem is that SET / RESET part is messing with the HeapTuple, so > you can't use the procForm reference afterwards. Simply processing > parallel_item before set_items fixes the problem, as in the attached. This

Re: Unexpected result from ALTER FUNCTION— looks like a bug

new status: > > > > > > > > * name | type | security |proconfig > > | volatility > > | parallel > > --+--+--+-----++ > > f > >| func | invoker | {TimeZone=UTC} > >| stable | restricted* > &

Re: Re: Unexpected result from ALTER FUNCTION— looks like a bug

"David G. Johnston" writes: > On Tue, Apr 19, 2022 at 7:07 PM Bryn Llewellyn > wrote: >> This is the bug. > While I haven't experimented with this for confirmation, what you are > proposing here (set + parallel safe) is an impossible runtime > combination (sem

Re: Unexpected result from ALTER FUNCTION— looks like a bug

-++---- > f >| func | invoker | {TimeZone=UTC} >| stable | restricted* > > This is the bug. > It has room for improvement from a user experience perspective. While I haven't experimented with this for confirmation, what you are proposing here (set + parall

Unexpected result from ALTER FUNCTION— looks like a bug

proconfig | volatility | parallel --+--+--+-++ f| func | invoker | {TimeZone=UTC} | stable | restricted This is the bug. Notice that with "alter procedure", the semantic differ

Re: FOR integer loop bug?

On 4/8/22 11:23, Ron wrote: On 4/8/22 13:07, Adrian Klaver wrote: Hmm, I'm going to have to think on this. The only thinking is: "That's a bug waiting to happen!" That was my first inclination. From here: https://www.postgresql.org/docs/current/plpgsql-control-structures.ht

Re: FOR integer loop bug?

i;     END LOOP; END; $function$ ; select for_loop_test(); NOTICE:  1 NOTICE:  0  for_loop_test --- Hmm, I'm going to have to think on this. The only thinking is: "That's a bug waiting to happen!" -- Angular momentum makes the world go 'round.

Re: FOR integer loop bug?

On 4/8/22 10:58 AM, Pavel Stehule wrote: pá 8. 4. 2022 v 19:56 odesílatel Adrian Klaver Why is the three period form allowed through and why does it produce no result? Maybe (2022-04-08 19:57:57) postgres=# select .10; ┌──┐ │ ?column? │ ╞══╡ │     0.10 │

Re: FOR integer loop bug?

pá 8. 4. 2022 v 19:56 odesílatel Adrian Klaver napsal: > Postgres 14.2 > > In commenting on a SO question I came across the below. > > Given: > > CREATE OR REPLACE FUNCTION public.for_loop_test() > RETURNS void > LANGUAGE plpgsql > AS $function$ > BEGIN > FOR i IN 1..10 LOOP >

FOR integer loop bug?

Postgres 14.2 In commenting on a SO question I came across the below. Given: CREATE OR REPLACE FUNCTION public.for_loop_test() RETURNS void LANGUAGE plpgsql AS $function$ BEGIN FOR i IN 1..10 LOOP RAISE NOTICE '%', i; END LOOP; END; $function$ ; select for_loop_test();

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

On Wed, 23 Mar 2022 at 04:03, PALAYRET Jacques wrote: > For example, in Oracle it is not possible to have a SELECT statement without > a FROM clause (using DUAL table), so maybe " ambiguous " columns are not > handled in the same way. But if your original complaint, the column was not

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

ling lists" Envoyé: Mardi 22 Mars 2022 14:04:32 Objet: Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause On Tuesday, March 22, 2022, PALAYRET Jacques < [ mailto:jacques.palay...@meteo.fr | jacques.palay...@meteo.fr ] > wrote:

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

the subquery in the manner you ascribe to them, you’ll just need to adapt to reality. Its doesn’t have to seem logical to you, but this is how it is defined to work and thus the observed behavior is not a bug. David J.

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

ards De: "Torsten Förtsch" À: "PALAYRET Jacques" Cc: "PostgreSQL mailing lists" Envoyé: Mardi 22 Mars 2022 11:16:19 Objet: Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause This is what happens: WITH elev_Tlse_Blagnac

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

On Tuesday, March 22, 2022, Torsten Förtsch wrote: > > > Note the use of aliases, w and x. You are using a correlated subquery. > Yep. There is an FAQ entry if you’d like a bit more exposition.

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

30 > (5 lignes) > > ### With CTE : > # I'm suprised by the following result, the behavior of PostgreSQL ; is > that a bug ? : > = Statement 1 : = > WITH elev_Tlse_Blagnac AS ( > SELECT elev FROM weather_stations WHERE id=31069001 > ) > SELECT id, name, elev FROM weather_station

Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

-+-- > 31069001 | TOULOUSE-BLAGNAC | 151 > 31006001 | ALBIAC AGGLOMERATION | 289 > 31010001 | LUCHON-ANTIGNAC | 599 > 50003001 | AGON-COUTAINVILLE|2 > 50195001 | GATHEMO | 330 > (5 lignes) > > ### With CTE : > # I'm suprised by t

PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause

| 289 31010001 | LUCHON-ANTIGNAC | 599 50003001 | AGON-COUTAINVILLE | 2 50195001 | GATHEMO | 330 (5 lignes) ### With CTE : # I'm suprised by the following result, the behavior of PostgreSQL ; is that a bug ? : = Statement 1 : = WITH elev_Tlse_Blagnac AS ( SELECT elev FROM

Re: PSQL bug?

At Thu, 17 Mar 2022 11:38:30 +0100, Dominique Devienne wrote in > Made a typo, using } instead of ) to test a weird table name, and got > disconnected. Normal? --DD > > ddevienne=> create table "t |" ( id int}; > ddevienne(> ); > server closed the connection unexpectedly > This

Re: PSQL bug?

čt 17. 3. 2022 v 12:06 odesílatel Dominique Devienne napsal: > > On Thu, Mar 17, 2022 at 11:38 AM Pavel Stehule > wrote: > >> Made a typo, [...], and got disconnected. Normal? --DD > > I don't see any problem on master > > OK, good. Must have been fixed already then. Or was a fluke. Thanks >

Re: PSQL bug?

On Thu, Mar 17, 2022 at 11:38 AM Pavel Stehule wrote: >> Made a typo, [...], and got disconnected. Normal? --DD > I don't see any problem on master OK, good. Must have been fixed already then. Or was a fluke. Thanks for checking. --DD

Re: PSQL bug?

Hi čt 17. 3. 2022 v 11:35 odesílatel Dominique Devienne napsal: > Made a typo, using } instead of ) to test a weird table name, and got > disconnected. Normal? --DD > > ddevienne=> create table "t |" ( id int}; > ddevienne(> ); > server closed the connection unexpectedly > This probably

PSQL bug?

Made a typo, using } instead of ) to test a weird table name, and got disconnected. Normal? --DD ddevienne=> create table "t |" ( id int}; ddevienne(> ); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the

Re: type bug?

st 6. 10. 2021 v 5:50 odesílatel napsal: > Hello, > > there is a bug with types in functions. Here is an example: > > --drop type xyz; > create type xyz as ( x numeric, y numeric, z numeric ); > > --drop table test_xyz ; > create table test_xyz ( a int

Re: type bug?

On Tuesday, October 5, 2021, wrote: > > create function test_xyz3() returns table ( b xyz) as > $$ > declare > bb xyz; > cc xyz; > begin > select b, c into bb, cc from test_xyz ; > return bb ; > end; > $$ language plpgsql ; > -- -- > > select * from test_xyz3() ; -- compiling error

Re: type bug?

On Tuesday, October 5, 2021, wrote: > > select * from test_xyz2() ; -- 3 columns, but 1 should be correct? > select b from test_xyz2() ; -- error > select x from test_xyz2() ; -- never declared column All three of these stem from:

Re: type bug?

On Wed, 2021-10-06 at 00:21 -0500, Ron wrote: > > What version of Postgresql do you think has the bug? > Where did you get the Postgresql binaries from? > What platform? FreeBSD pkg install postgresql ... Version 13.3 a friend use Debian unstable with PG version 14 and have the

Re: type bug?

What version of Postgresql do you think has the bug? Where did you get the Postgresql binaries from? What platform? On 10/5/21 10:50 PM, m...@ft-c.de wrote: Hello, there is a bug with types in functions. Here is an example: --drop type  xyz; create type xyz as ( x numeric,  y numeric,  z

type bug?

Hello, there is a bug with types in functions. Here is an example: --drop type  xyz; create type xyz as ( x numeric,  y numeric,  z numeric ); --drop table  test_xyz ; create table test_xyz (  a int,  b xyz, c xyz ); insert into  test_xyz values ( 1,(11.1, 12.3, 14.5 ), (22.2, 22.3, 24.5

Re: Behavior change in PostgreSQL 14Beta3 or bug?

On Mon, 2021-09-06 at 12:11 -0700, Peter Geoghegan wrote: > On Mon, Sep 6, 2021 at 9:21 AM Laurenz Albe wrote: > > #define BYPASS_THRESHOLD_PAGES  0.02    /* i.e. 2% of rel_pages */ > > > > So up to an additional 2% of all pages can have the all-visible bit > > unset with "index_cleanup = auto".

Re: Behavior change in PostgreSQL 14Beta3 or bug?

On Mon, Sep 6, 2021 at 7:52 AM Daniel Westermann (DWE) wrote: > >Try running vacuum with index cleanup = on. > > Thank you, Peter Thanks for testing! -- Peter Geoghegan

Re: Behavior change in PostgreSQL 14Beta3 or bug?

On Mon, Sep 6, 2021 at 8:59 AM Tom Lane wrote: > Assuming that that choice was made appropriately, I think the advice you > propose here will just cause people to waste lots of cycles on VACUUM > runs that have only marginal effects. Right. The advice that they should receive (if any) is to tune

Re: Behavior change in PostgreSQL 14Beta3 or bug?

On Mon, Sep 6, 2021 at 9:21 AM Laurenz Albe wrote: > #define BYPASS_THRESHOLD_PAGES 0.02/* i.e. 2% of rel_pages */ > > So up to an additional 2% of all pages can have the all-visible bit > unset with "index_cleanup = auto". > > That is probably not worth worrying, right? I don't think it's

Re: Behavior change in PostgreSQL 14Beta3 or bug?

On Mon, 2021-09-06 at 11:59 -0400, Tom Lane wrote: > Laurenz Albe writes: > > It is not an incompatibility that warrants a mention in the release notes, > > but perhaps somthing in > > https://www.postgresql.org/docs/14/indexes-index-only-scans.html > > and/or > >

  1   2   3   4   >