On Mon, 2025-07-14 at 14:30 -0400, Tom Lane wrote:
> (I have a vague idea that there are system-level security hazards,
> not specific to Postgres, if mount-point directories are publicly
> writable. Don't feel like researching that though.)
Well, if you are using an ext? file system, there is a
On Monday, July 14, 2025, Laurenz Albe wrote:
> On Mon, 2025-07-14 at 12:19 -0700, Rich Shepard wrote:
> > On Mon, 14 Jul 2025, David G. Johnston wrote:
> >
> > > The error indicates your script file is at least 127 lines long and you
> > > are showing like 9...also do you usually name your scrip
On Mon, 2025-07-14 at 12:19 -0700, Rich Shepard wrote:
> On Mon, 14 Jul 2025, David G. Johnston wrote:
>
> > The error indicates your script file is at least 127 lines long and you
> > are showing like 9...also do you usually name your script files with a
> > .txt extension?
>
> Agh! No the filen
Dear Abrahim,
> Hi Hayato and Shlok, I confirmed that it is related of Citus, everytrhing
> worked
> after remove the Citus instalation from the docker image.
Thanks for the confirmation. I also feel that the issue is related with Citus.
I recommend
to report the Citus's community [1] to solve
On Mon, 14 Jul 2025, David G. Johnston wrote:
Yeah, you need both to read up on aggregate queries and correlated
subqueries which is typically how one makes uses of exists (it's called a
semi-join in this formulation)
David,
Thanks. I wasn't sure what to read.
Not tested, but:
select c.ind
On Mon, Jul 14, 2025 at 12:59 PM Rich Shepard
wrote:
>
> The current version of the script:
>
> select c.company_nbr, c.company_name, c.industry
> from companies as c
> where exists (
>select e.company_nbr
>from enforcement as e
>)
> group by c.industry
> order by c.industry;
>
> And
On Mon, Jul 14, 2025 at 12:54 PM Adrian Klaver
wrote:
> On 7/14/25 12:51, veem v wrote:
> > So I want to
> > understand the experts' opinion on this which I believe will be
> > crucial during design itself.
>
> It is spelled out here:
>
> https://www.postgresql.org/docs/current/datatype-json.htm
On Mon, 14 Jul 2025, Adrian Klaver wrote:
That does not matter, that is more for user convenience in figuring out what
the files are for.
Adrian,
Okay.
I still have issues with the script. I want a count of companies with
regulatory enforcement actions by industry. Since not all regulated
co
On Mon, Jul 14, 2025 at 12:45 PM Adrian Klaver
wrote:
> >
> > I mistyped the script's extension as .txt rather than .sql.
>
> That does not matter, that is more for user convenience in figuring out
> what the files are for.
>
>
I think all that is being said is the error was a simple typo, choosi
On 7/14/25 12:51, veem v wrote:
Hi,
It's postgres 15+. And need guidance on JSON types, (for both on premise
vanilla postgres installation and AWS cloud based RDS/aurora postgres
installations).
I have never worked on a JSON data type in the past. But now in one of
the scenarios the team wan
Hi,
It's postgres 15+. And need guidance on JSON types, (for both on premise
vanilla postgres installation and AWS cloud based RDS/aurora postgres
installations).
I have never worked on a JSON data type in the past. But now in one of the
scenarios the team wants to use it and thus want to understa
On 7/14/25 12:38, Rich Shepard wrote:
Reply to list also.
Ccing list.
On Mon, 14 Jul 2025, Adrian Klaver wrote:
The above looks like the format 'aligned' output from a query.
Adrian,
I mistyped the script's extension as .txt rather than .sql.
That does not matter, that is more for user c
On 7/14/25 12:12, Rich Shepard wrote:
I have the following script:
select c.company_nbr, c.company_name, i.industry, from companies as c,
industry as i, enforcement as e
where exists (
select c.company_nbr, count(e.action_date), sum(e.penalty_amt)
from e.enforcement
where c.company_nb
On Mon, 14 Jul 2025, David G. Johnston wrote:
The error indicates your script file is at least 127 lines long and you
are showing like 9...also do you usually name your script files with a
.txt extension?
David J.,
Agh! No the filename extension is .sql. But I was using the \o psql option
to
On Mon, Jul 14, 2025 at 12:12 PM Rich Shepard
wrote:
> I have the following script:
>
> select c.company_nbr, c.company_name, i.industry,
> from companies as c, industry as i, enforcement as e
> where exists (
>select c.company_nbr, count(e.action_date), sum(e.penalty_amt)
>from e.enforce
I have the following script:
select c.company_nbr, c.company_name, i.industry,
from companies as c, industry as i, enforcement as e
where exists (
select c.company_nbr, count(e.action_date), sum(e.penalty_amt)
from e.enforcement
where c.company_nbr = e.company_nbr
)
group by industry
or
Benjamin Wang writes:
> I am not sure whether PostgreSQL depends on system call `fsyncdata` to
> sync data to disk. If yes, then I don't think it's safe to use NFS.
Well, that's a whole other discussion. The point about mount
directories applies to any sort of dismountable storage.
(But I too
On Mon, Jul 14, 2025 at 12:02 PM Benjamin Wang
wrote:
> I am not sure whether PostgreSQL depends on system call `fsyncdata` to
> sync data to disk.
>
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-SYNC-METHOD
David J.
I am not sure whether PostgreSQL depends on system call `fsyncdata` to
sync data to disk. If yes, then I don't think it's safe to use NFS.
When `fsyncdata` returns success, it doesn't mean the data has
really been synced to disk. But if PostgreSQL crashes right after
it returns success to clients.
Greg Hennessy writes:
>> Postgres has chosen to use only a small fraction of the CPU's I have on
>> my machine. Given the query returns an answer in about 8 seconds, it may be
>> that Postgresql has allocated the proper number of works. But if I wanted
>> to try to tweak some config parameters to
"Peter J. Holzer" writes:
> On 2025-07-14 10:07:20 -0400, Tom Lane wrote:
>> That is primarily for safety reasons: if for some reason the
>> filesystem gets dismounted, or hasn't come on-line yet during
>> a reboot, you do not want Postgres to be able to write on the
>> underlying mount-point dire
Setting those values to zero (not something I'd want to do in production)
changes the number of workes
from 10 to 13. At least something, but if anyone knows where discussion
about how to use
large numbers of CPU's in postgresql are being held I'd appreciate learning
about it.
Greg
On Fri, Jul 1
On 2025-07-14 10:07:20 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > It is not a good idea to have a mount point be the data directory.
>
> ^^^ This. ^^^
>
> That is primarily for safety reasons: if for some reason the
> filesystem gets dismounted, or hasn't come on-line yet during
> a reboo
On Mon, 2025-07-14 at 18:32 +0530, Amol Inamdar wrote:
> > The data directory can either be created by "initdb", in which case
> > the mount point must allow the PostgreSQL user to create a directory.
> > You could set the group of the mount point to the group of the
> > PostgreSQL user and use per
Laurenz Albe writes:
> It is not a good idea to have a mount point be the data directory.
^^^ This. ^^^
That is primarily for safety reasons: if for some reason the
filesystem gets dismounted, or hasn't come on-line yet during
a reboot, you do not want Postgres to be able to write on the
underly
Thanks Laurenz,
The data directory can either be created by "initdb", in which case
the mount point must allow the PostgreSQL user to create a directory.
You could set the group of the mount point to the group of the
PostgreSQL user and use permissions 1770, which should be perfectly safe.
This e
Hi Laurenz
Thanks for the reply,
If I am not mistaken, below is my understanding of your suggestion.
Suppose that My mount point on the NFS server is say /nfs-mount/postgres/
and you are suggesting to have a data directory as say
/nfs-mount/postgres/db or something like that ?
and assign this va
On Mon, 2025-07-14 at 17:59 +0530, Amol Inamdar wrote:
> If I am not mistaken, below is my understanding of your suggestion.
>
> Suppose that My mount point on the NFS server is say /nfs-mount/postgres/
> and you are suggesting to have a data directory as say /nfs-mount/postgres/db
> or somethi
On Mon, 2025-07-14 at 11:19 +0530, Amol Inamdar wrote:
> I'm currently running PostgreSQL version 16.6 inside a Docker container
> (base image: UBI 9), using Docker Compose. The PostgreSQL data directory
> is mounted from an NFS volume hosted on a z/OS NFS server.
>
> The environment has a few con
Dear PostgreSQL Community,
I'm currently running PostgreSQL version 16.6 inside a Docker container
(base image: UBI 9), using Docker Compose. The PostgreSQL data directory
is mounted from an NFS volume hosted on a z/OS NFS server.
The environment has a few constraints:
- The NFS server runs on z
30 matches
Mail list logo
