On Tue, Feb 17, 2015 at 4:40 AM, happy times wrote:
> The first choice Tom pointed makes sense to me: adding this as eqivalent to
> setting all subsequent transactions as read only. It is useful enough in the
> scenarios where disk limit for the instance is reached, we want to block all
> write a
>?6?9Jim Nasby writes:
> On 2/14/15 3:14 PM, Robert Haas wrote:
>> Although I like the idea, it's not clear to me how to implement it.
> Throw an error in AssignTransactionId/GetNewTransactionId?
>A whole lot depends on what you choose to mean by "read only". If it
>?6?9means the same thing as "
On 2/14/15 7:24 PM, Tom Lane wrote:
> Another possibility that would be attractive for replication-related
> use-cases would be "nothing that generates WAL thank you very much".
This would be useful, as it essentially simulates a hot standby.
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On 2015-02-14 17:28:38 -0600, Jim Nasby wrote:
> Throw an error in AssignTransactionId/GetNewTransactionId? I see 4 calls to
> Get*TransactionId in logical replication, though arguably if we're fixing
> that we should look at doing something special for Slony and the
> likes.
I don't think there a
On Feb15, 2015, at 10:13 , David G Johnston wrote:
> happy times wrote
>> Sure, we can utilize the runtime parameter
>> default_transaction_read_only, however, it does not restrict user from
>> changing transaction attribute to non-readonly mode, so is not safe.
>
> ISTM that implementing a me
happy times wrote
> Sure, we can utilize the runtime parameter
> default_transaction_read_only, however, it does not restrict user from
> changing transaction attribute to non-readonly mode, so is not safe.
ISTM that implementing a means to make this setting only super-user
changeable would be
Jim Nasby writes:
> On 2/14/15 3:14 PM, Robert Haas wrote:
>> Although I like the idea, it's not clear to me how to implement it.
> Throw an error in AssignTransactionId/GetNewTransactionId?
A whole lot depends on what you choose to mean by "read only". If it
means the same thing as "all transa
On 2/14/15 3:14 PM, Robert Haas wrote:
On Fri, Feb 13, 2015 at 3:32 AM, happy times wrote:
I didn’t find any convenient way to restrict access to PostgreSQL databases
to be read-only for all users. I need it in following scenarios:
A) Planned switch-over from master to slave. We want to minimi
On Fri, Feb 13, 2015 at 3:32 AM, happy times wrote:
> I didn’t find any convenient way to restrict access to PostgreSQL databases
> to be read-only for all users. I need it in following scenarios:
>
> A) Planned switch-over from master to slave. We want to minimize impact
> within the planned swit
Hi PG Developers,
I didn’t find any convenient way to restrict access to PostgreSQL databases to
be read-only for all users. I need it in following scenarios:
A) Planned switch-over from master to slave. We want to minimize impact within
the planned switch-overs. So during the process we swit
10 matches
Mail list logo
