> On Aug 6, 2020, at 18:45, Jerry Sievers wrote:
> Deleting the .ready file should allow the archiver to get past the
> missing file.
Ah, excellent, yes.
--
-- Christophe Pettus
x...@thebuild.com
Christophe Pettus writes:
> I've encountered a rather unusual situation (PostgreSQL 9.6). On a
> particular server, for reasons I've not fully diagnosed, the archiver
> thinks that the current WAL segment to be archived is
> 00023B680062. This is unfortunate, because the oldest WAL
I've encountered a rather unusual situation (PostgreSQL 9.6). On a particular
server, for reasons I've not fully diagnosed, the archiver thinks that the
current WAL segment to be archived is 00023B680062. This is
unfortunate, because the oldest WAL segment that actually exists on d
On Thu, Aug 6, 2020 at 10:01:21AM -0400, David Gauthier wrote:
> Our IT dept needs to install a patch on both primary and backup servers for
> our
> Postgres Automatic Failover configured DB (version 9.6 on linux). From the
> standpoint of the DB users, can a strategy be implemented such that th
Hello,
I have experience with Microsoft SQL Server and trying to migrate to
PostGreSQL. Wanted to reach out to community experts to guide me define or
follow best practices when granting privileges to the database users.
We have a bunch of stored procedures which will be executed by the
applicati
FYI, REVOKE ALL ON SCHEMA... followed by GRANT ALL ON SCHEMA... did not change
anything
> On Aug 6, 2020, at 12:53 PM, Stephen Frost wrote:
>
> Are you 110% sure that you're actually connecting to the same instance
> in both cases (I'd say database too, but hopefully psql isn't lying to
> you about that on your prompt, but maybe double-check anyway...).
yes--double checked
> Have
Greetings,
* Scott Ribe (scott_r...@elevated-dev.com) wrote:
> when user akanzler tries to run query "SELECT * FROM zoewang.sometable...",
> it triggers this error:
>
> 2020-08-06 17:27:27.664 UTC [15914]: [3]
> user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
> permis
> On Aug 6, 2020, at 12:38 PM, Tom Lane wrote:
>
> Hmph. Any chance of getting a stack trace from the point of the error?
possibly
> Also, which PG version is this?
12.3
It is probably relevant that we cleaned up roles & privs yesterday, lots of
REVOKE & GRANT, and some DROP ROLE. I started
On 8/6/20 11:39 AM, Scott Ribe wrote:
On Aug 6, 2020, at 12:36 PM, Adrian Klaver wrote:
No triggers or FOREIGN KEYS?
No. No keys or indexes either--that was the entire table def.
echo "Hmph"
--
Adrian Klaver
adrian.kla...@aklaver.com
> On Aug 6, 2020, at 12:36 PM, Adrian Klaver wrote:
>
> No triggers or FOREIGN KEYS?
No. No keys or indexes either--that was the entire table def.
Scott Ribe writes:
> On Aug 6, 2020, at 12:22 PM, Tom Lane wrote:
>> Gonna need more context. The session-level user seems to have the
>> right privileges, but maybe something is happening inside a
>> security-definer function that doesn't have privileges?
> The only security definer function i
On Aug 6, 2020, at 12:22 PM, Tom Lane wrote:
>
> Gonna need more context. The session-level user seems to have the
> right privileges, but maybe something is happening inside a
> security-definer function that doesn't have privileges?
The only security definer function in the db is a simple pg_
On 8/6/20 11:35 AM, Scott Ribe wrote:
On Aug 6, 2020, at 12:22 PM, Adrian Klaver wrote:
Schema for the table?
Nothing relevant:
Column| Type | Collation | Nullable | Default
-+---+---+--+-
curve_name | characte
> On Aug 6, 2020, at 12:22 PM, Adrian Klaver wrote:
>
> Schema for the table?
Nothing relevant:
Column| Type | Collation | Nullable | Default
-+---+---+--+-
curve_name | character varying(30) | |
On 8/6/20 11:11 AM, Scott Ribe wrote:
when user akanzler tries to run query "SELECT * FROM zoewang.sometable...", it
triggers this error:
2020-08-06 17:27:27.664 UTC [15914]: [3]
user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
permission denied for schema zoewang at
Scott Ribe writes:
> when user akanzler tries to run query "SELECT * FROM zoewang.sometable...",
> it triggers this error:
> 2020-08-06 17:27:27.664 UTC [15914]: [3]
> user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
> permission denied for schema zoewang at character 1
when user akanzler tries to run query "SELECT * FROM zoewang.sometable...", it
triggers this error:
2020-08-06 17:27:27.664 UTC [15914]: [3]
user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
permission denied for schema zoewang at character 15
--- YET ---
risk_oltp_pro
Our IT dept needs to install a patch on both primary and backup servers for
our Postgres Automatic Failover configured DB (version 9.6 on linux). From
the standpoint of the DB users, can a strategy be implemented such that
they see zero downtime during this process as the 2 servers are taken down
19 matches
Mail list logo
