Re: Why not do distinct before SetOp

On Wed, 6 Nov 2024 at 12:09, Tom Lane wrote: > Of course, I might be overestimating the performance benefit we'd get. > But I'm tempted to give it a try. I'm glad. I'm curious to see if you're right about the projection overhead of the flags. If you're right, it seems like a not too difficult opt

Re: Why not do distinct before SetOp

David Rowley writes: > On Tue, 5 Nov 2024 at 04:18, Tom Lane wrote: >> A different idea that occurred to me while looking at this is: >> why have we got all this machinery to add and check a flag >> column, rather than arranging things so that the two input >> relations are "outer" and "inner" ch

Re: adsrc

On Tue, Nov 5, 2024 at 4:44 PM Ron Johnson wrote: > On Tue, Nov 5, 2024 at 4:45 PM Matt Zagrabelny wrote: > >> Greetings Pg folk, >> >> I've got a legacy app connecting to a legacy Pg database (9.4). >> >> I'd like to upgrade the database to Pg 15, but when I connect and perform >> some tasks in

Re: adsrc

On Tue, Nov 5, 2024 at 4:45 PM Matt Zagrabelny wrote: > Greetings Pg folk, > > I've got a legacy app connecting to a legacy Pg database (9.4). > > I'd like to upgrade the database to Pg 15, but when I connect and perform > some tasks in the app, I get: > > ERROR: column d.adsrc does not exist at

Re: adsrc

On Tue, Nov 5, 2024 at 2:45 PM Matt Zagrabelny wrote: > ERROR: column d.adsrc does not exist at character 331 > > Some searching online yields that adsrc was removed in Pg 12. > > Is there a way to recreate it? > > That is a base catalog table. Its removal means the data it stored is no longer

Re: adsrc

## Matt Zagrabelny (mzagr...@d.umn.edu): > I'd like to upgrade the database to Pg 15, but when I connect and perform > some tasks in the app, I get: > > ERROR: column d.adsrc does not exist at character 331 That pg_attrdef.adsrc was already marked as "historical, and is best not used" in 9.4: h

Re: Why not do distinct before SetOp

On Tue, 5 Nov 2024 at 04:18, Tom Lane wrote: > A different idea that occurred to me while looking at this is: > why have we got all this machinery to add and check a flag > column, rather than arranging things so that the two input > relations are "outer" and "inner" children of the SetOp? I've n

adsrc

Greetings Pg folk, I've got a legacy app connecting to a legacy Pg database (9.4). I'd like to upgrade the database to Pg 15, but when I connect and perform some tasks in the app, I get: ERROR: column d.adsrc does not exist at character 331 Some searching online yields that adsrc was removed i

Re: Switching to NOINHERIT user triggers #XX000 error

On Tue, Nov 5, 2024 at 7:25 PM Tom Lane wrote: > Dominique Devienne writes: > > On Tue, Nov 5, 2024 at 6:42 PM Tom Lane wrote: > >> This is probably a bug, at least to the extent that we don't like > >> XX000 errors to be easily reachable, so please let us know what > >> you find out. > > > Find

Re: Switching to NOINHERIT user triggers #XX000 error

Dominique Devienne writes: > On Tue, Nov 5, 2024 at 6:42 PM Tom Lane wrote: >> This is probably a bug, at least to the extent that we don't like >> XX000 errors to be easily reachable, so please let us know what >> you find out. > Finding where the error is thrown is easy, it's when I'm doing th

Re: Switching to NOINHERIT user triggers #XX000 error

On Tue, Nov 5, 2024 at 6:42 PM Tom Lane wrote: > Dominique Devienne writes: > > On v16 and v17 though, it works with INHERIT, but with NOINHERIT, I get: > > GRANT "...:USER" TO "ddevienne" #XX000: ERROR: no possible grantors > > Any clue to what this means, so I can start looking in the right pl

Re: Switching to NOINHERIT user triggers #XX000 error

Dominique Devienne writes: > On v16 and v17 though, it works with INHERIT, but with NOINHERIT, I get: > GRANT "...:USER" TO "ddevienne" #XX000: ERROR: no possible grantors > Any clue to what this means, so I can start looking in the right place? \errverbose in psql would help you locate what par

Switching to NOINHERIT user triggers #XX000 error

Hi. Still working on porting our stuff to v16+, with the ROLE changes. I'm facing a new issue. The same code and unit test works in v14, when the LOGIN user running the test is INHERIT or NOINHERIT. On v16 and v17 though, it works with INHERIT, but with NOINHERIT, I get: GRANT "...:USER" TO "dde

Re: Postgres listens on random port

On 11/5/24 06:22, Kal wrote: On Tue, 5 Nov 2024 at 7:42 PM, Greg Sabino Mullane > wrote: Start by seeing where the port is actually being set by running this: select setting, source, sourcefile, sourceline from pg_settings where name = 'port'; Cheer

Re: Postgres 12.21?

On Tue, Nov 5, 2024 at 8:21 AM Mark Hill wrote: > Will there be a minor version update to Postgres 12 this Thursday, > 11/7/24, going to version 12.21? > Yes. https://www.postgresql.org/support/versioning/ David J.

Re: Postgres listens on random port

Agreed - it sounds like OP found a *client *process and mistook it for a server process, which is why I wanted to know where exactly he saw this. On Tue, Nov 5, 2024 at 9:41 AM Ron Johnson wrote: > On Tue, Nov 5, 2024 at 9:22 AM Kal wrote: > >> >> On Tue, 5 Nov 2024 at 7:42 PM, Greg Sabino Mull

Postgres 12.21?

Will there be a minor version update to Postgres 12 this Thursday, 11/7/24, going to version 12.21? Thanks, Mark

Re: Postgres listens on random port

On 2024-11-05 15:22 +0100, Kal wrote: > On Tue, 5 Nov 2024 at 7:42 PM, Greg Sabino Mullane > wrote: > > > Start by seeing where the port is actually being set by running this: > > > > select setting, source, sourcefile, sourceline from pg_settings where name > > = 'port'; > > Cheers, > > Greg > >

Re: Postgres listens on random port

On Tue, Nov 5, 2024 at 9:22 AM Kal wrote: > > On Tue, 5 Nov 2024 at 7:42 PM, Greg Sabino Mullane > wrote: > >> Start by seeing where the port is actually being set by running this: >> >> select setting, source, sourcefile, sourceline from pg_settings where >> name = 'port'; >> Cheers, >> Greg >>

Re: Postgres listens on random port

Hi The netstat command did not reveal any entries on the intended port (say 5460). The 5460 port was vacant, no processes were using it. I had to crawl through the postgres processes on task manager to find the listening port. Could this be due interference from other services? But the port 546

Re: Postgres listens on random port

" But the database actually listens on some random port like 20011" How exactly did you determine this? (If you used, say, netstat, can you share its output with us?) On Tue, Nov 5, 2024 at 8:46 AM Kal wrote: > Hi > > I have a scenario in which postgres listens on a random port different > fro

Re: Postgres listens on random port

On Tue, 5 Nov 2024 at 7:42 PM, Greg Sabino Mullane wrote: > Start by seeing where the port is actually being set by running this: > > select setting, source, sourcefile, sourceline from pg_settings where name > = 'port'; > Cheers, > Greg > > Hi Greg, The query output states the source as command

Re: Postgres listens on random port

Start by seeing where the port is actually being set by running this: select setting, source, sourcefile, sourceline from pg_settings where name = 'port'; Cheers, Greg

Postgres listens on random port

Hi I have a scenario in which postgres listens on a random port different from the one which was specified in pg_ctl start command. This occurs in windows. When postgres is started on port 5460, the logs denote that postgres is started on 5460. But the database actually listens on some random por