I don't want to do use the normal backup algorithm where pg_start_backup +
pg_stop_backup will fix any fractured block and I am required to have all
archived logfiles, therefore.
I want to produce an atomic consistent disk snapshot.
I am not sure if freeze/unfreeze will be enough with default v
"Zwettler Markus (OIZ)" writes:
> I don't want to do use the normal backup algorithm where pg_start_backup +
> pg_stop_backup will fix any fractured block and I am required to have all
> archived logfiles, therefore.
> I want to produce an atomic consistent disk snapshot.
[ shrug... ] You can'
On 5/12/22 03:39, Kieran McCusker wrote:
Please reply to list also
Ccing list.
Hi
Fedora 36 is there now but it is missing pg_cron - Is that intentional?
I don't know that is something you would need to ask the packagers:
https://yum.postgresql.org/contact/
Cheers
Kieran
--
Adrian Kl
>
>
> It adds the "initially deferred" decoration to the "create constraint
> trigger" statement. This is (still) the result:
>
> INFO: trg fired. new.v = 10, n = 5
> INFO: trg fired. new.v = 20, n = 5
> INFO: trg fired. new.v = 30, n = 5
> INFO: trg fired. new.v = 40, n = 5
> INFO: trg fired.
On Thu, 12 May 2022 at 14:48, Tom Lane wrote:
> "Zwettler Markus (OIZ)" writes:
> > I don't want to do use the normal backup algorithm where pg_start_backup
> + pg_stop_backup will fix any fractured block and I am required to have all
> archived logfiles, therefore.
> > I want to produce an atom
On Wed, 11 May 2022 at 20:02, David Gauthier wrote:
> I have a table with a bytea column which, of course, contains binary data.
> After 60 days, I no longer need the binary data but want to retain the rest
> of the record. Of course it's easy to just update the bytea column to null
> for the
Hi,
Is there anyway that we can restrict a user from seeing the schema
structure. I can restrict the user from accessing the data in the schema
but the user is still able to see the table names and what all columns are
present in them.
Thanks & Regards
Neeraj
On 5/12/22 03:04, Neeraj M R wrote:
Hi,
Is there anyway that we can restrict a user from seeing the schema
structure. I can restrict the user from accessing the data in the schema
but the user is still able to see the table names and what all columns
are present in them.
No.
Thanks & Rega
Talking about fsfreeze and blocksize are not relevant in your case at all.
You can't make a backup this way any way. According your mail,
you are playing with database recovery after crash. Is pg crash proof? Yes (
https://www.postgresql.org/docs/current/wal-intro.html).
You can use this solution f
> adrian.kla...@aklaver.com wrote:
>
>> neerajmr12...@gmail.com wrote:
>>
>> Is there anyway that we can restrict a user from seeing the schema
>> structure. I can restrict the user from accessing the data in the schema but
>> the user is still able to see the table names and what all columns a
> postgres.ro...@gmail.com wrote:
>
> It adds the "initially deferred" decoration to the "create constraint
> trigger" statement. This is (still) the result:
>
> INFO: trg fired. new.v = 10, n = 5
> INFO: trg fired. new.v = 20, n = 5
> INFO: trg fired. new.v = 30, n = 5
> INFO: trg fired. ne
On 5/12/22 11:29, Bryn Llewellyn wrote:
I've prototyped this scheme. It seems to work as designed. A client that
connects with psql (or any other tool) can list the API functions and whatever
\df and \sf show. (notice that \d will reveal nothing.)But doing this reveals
only the names of the f
On Thu, May 12, 2022 at 11:44 AM Adrian Klaver
wrote:
> On 5/12/22 11:29, Bryn Llewellyn wrote:
>
> > I've prototyped this scheme. It seems to work as designed. A client that
> connects with psql (or any other tool) can list the API functions and
> whatever \df and \sf show. (notice that \d will
> david.g.johns...@gmail.com wrote:
>
>> adrian.kla...@aklaver.com wrote:
>>
>>> b...@yugabyte.com wrote:
>>>
>>> I've prototyped this scheme. It seems to work as designed. A client that
>>> connects with psql (or any other tool) can list the API functions and
>>> whatever \df and \sf show. (n
On Thu, May 12, 2022 at 7:35 PM Bryn Llewellyn wrote:
>
> However, the design decision that, way back when, leads to this outcome
> does surprise me. The principle of least privilege insists that (in the
> database regime) you can create users that can do exactly and only what
> they need to do.
Bryn Llewellyn writes:
> Maybe this entire discussion is moot when hackers can read the C code of PG's
> implementation…
Hmm ... in one way that's unrelated, but in another way perhaps it is.
Postgres' system catalogs have always been user-readable as much as
possible, excepting only cases that
> david.g.johns...@gmail.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> However, the design decision that, way back when, leads to this outcome does
>> surprise me. The principle of least privilege insists that (in the database
>> regime) you can create users that can do exactly and only what t
pá 13. 5. 2022 v 5:42 odesílatel Bryn Llewellyn napsal:
> *david.g.johns...@gmail.com wrote:*
>
> *b...@yugabyte.com wrote:*
>
> However, the design decision that, way back when, leads to this outcome
> does surprise me. The principle of least privilege insists that (in the
> database regime) y
> t...@sss.pgh.pa.us wrote:
>
>> b...@yugabyte.com writes:
>>
>> Maybe this entire discussion is moot when hackers can read the C code of
>> PG's implementation…
>
> We have pretty much no interest in revisiting that design choice, even if
> doing so wouldn't likely break a couple decades' wor
Whether or not you want to use the "normal backup algorithm" is irrelevant,
since if you try and start that snapshot Postgresql /*will*/ see the
instance as /*needing*/ to be recovered.
Having said that... our storage team does SAN snapshots of the *single LUN*
where */all/**of the Postgres* f
> laurenz.a...@cybertec.at wrote:
>
>> b...@yugabyte.com wrote:
>>
>> …I have always understood that (in Postgres and any respectable RDBMS)
>> commits in a multi-session environment are always strictly
>> serialized—irrespective of the transaction's isolation level. Am I correct
>> to assume
On Thursday, May 12, 2022, Neeraj M R wrote:
>
> Thanks for your suggestions, I would like to define my problem a little
> more.
>
> I am using pgAdmin
>
> Is there any way I can completely hide schema1 from the new user.
>
pgAdmin is a separate project. You may get a response here but they do
> neerajmr12...@gmail.com wrote:
>
> I am using pgAdmin . I have a database 'db' and it has got 2 schemas
> 'schema1' and 'schema2', I have created some views in schema2 from tables of
> schema1. I have created a new user and granted connection access to database
> and granted usage on tables
On Thu, 2022-05-12 at 22:06 -0700, Bryn Llewellyn wrote:
>
> > In the case of constraint triggers, yes. But there is no race condition for
> > primary key,
> > unique and foreign key constraints, because they also "see" uncommitted
> > data.
>
> I can't follow you here, sorry. I tried this:
>
> neerajmr12...@gmail.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> What exactly do you mean by "have created a new user and granted connection
>> access to database"? As I understand it, there's no such thing. I mentioned
>> a simple test in my earlier email that showed that any user (with no
> laurenz.a...@cybertec.at wrote:
>
> Be "seeing" I didn't mean "show to the user". I mean that the code that
> implements PostgreSQL constraints takes uncommitted data into account.
>
> The documentation describes that for the case of uniqueness in some detail:
>
> https://www.postgresql.org/d
26 matches
Mail list logo
