Thank you. Its worked out well. But a basic doubt ? is storing the DB
superuser password in .pgpass is advisable ? What other options do we have ?
#su postgres
bash-4.2$ cd
bash-4.2$ cat .pgpass
*:*:*:postgres:your_password
bash-4.2$
On Mon, Nov 20, 2023 at 4:16 PM Achilleas Mantzios - cloud <
Or row level security.
On Mon, Nov 20, 2023 at 9:25 PM Alan Hodgson
wrote:
> On Mon, 2023-11-20 at 13:44 -0800, Christophe Pettus wrote:
>
>
>
> On Nov 20, 2023, at 13:41, David Gauthier wrote:
> I want the users to be required to provide a value for ssn in the
> following query...
> "select *
On Mon, 2023-11-20 at 13:44 -0800, Christophe Pettus wrote:
>
>
> > On Nov 20, 2023, at 13:41, David Gauthier
> > wrote:
> > I want the users to be required to provide a value for ssn in the
> > following query...
> > "select * from huge_view where ssn = '106-91-9930' "
> > I never want them
On Mon, Nov 20, 2023 at 4:07 AM Laurenz Albe
wrote:
> On Sun, 2023-11-19 at 17:30 +, Simon Connah wrote:
> > I was reading about prepared statements and how they allow the server to
> > plan the query in advance so that if you execute that query multiple
> times
> > it gets sped up as the
OK, didn't think so, just checking. Thanks for verifying !
On Mon, Nov 20, 2023 at 4:45 PM Christophe Pettus wrote:
>
>
> > On Nov 20, 2023, at 13:41, David Gauthier wrote:
> > I want the users to be required to provide a value for ssn in the
> following query...
> > "select * from huge_view
> On Nov 20, 2023, at 13:41, David Gauthier wrote:
> I want the users to be required to provide a value for ssn in the following
> query...
> "select * from huge_view where ssn = '106-91-9930' "
> I never want them to query the view without specifying ssn.
> It has to do with resources and
Maybe you could create a function that has a required parameter, so rather
than 'select * from huge_view where .." they do 'select * from
function(some_ssn) [where...]' ?
That function would then query the view using the supplied ssn.
Just a thought.
Steve
On Tue, Nov 21, 2023 at 8:41 AM David
Hi:
I have a view that I want to require user specification for a specific
column before the query starts (if that makes sense).
Example
I want the users to be required to provide a value for ssn in the following
query...
"select * from huge_view *where ssn = '106-91-9930'* "
I never want them
> "ignore" may not be what you want, though. Perhaps the fact that insert
> (coming from the NOT MATCHED clause) fails (== conflicts with a tuple
> concurrently inserted in an unique or exclusion constraint) should
> transform the row operation into a MATCHED case, so it'd fire the other
>
## Matthias Apitz (g...@unixarea.de):
> 2023-11-16 20:34:13.538 CET [6250] LOG: terminating walsender process due to
> replication timeout
Besides "what Lauenz said" (especially about the horribly ooutdated
PostgreSQL version): check IO speed and saturation during backup
and make sure you're
On 11/20/23 12:31, KK CHN wrote:
list,
I am trying pgBackRest on an RHEL 7.6 and old EDB 10 database cluster(
a legacy application.)
I have installed pgbackrest through package install on RHEL7.6
But unable to get the basic stanza-creation working It throws an error.
*
list,
I am trying pgBackRest on an RHEL 7.6 and old EDB 10 database cluster( a
legacy application.)
I have installed pgbackrest through package install on RHEL7.6
But unable to get the basic stanza-creation working It throws an error.
* /etc/pgbackrest.conf as follows..*
On Sun, 2023-11-19 at 17:30 +, Simon Connah wrote:
> I was reading about prepared statements and how they allow the server to
> plan the query in advance so that if you execute that query multiple times
> it gets sped up as the database has already done the planning work.
>
> My question is
On Mon, 2023-11-20 at 07:30 +0100, Matthias Apitz wrote:
> We're facing in a customer installation (PostgreSQL 13.1 on Linux) the
> following problem for the first time and not reproducible:
13.1? Your immediate reaction should be "update to the latest minor release".
> ${BINDIR}/pg_basebackup
14 matches
Mail list logo
