On Tue, May 17, 2022 at 4:57 AM alias wrote:
>
> My thought process:
>
>> update = delete + insert.
>> so * create policy emp_upd on emp for update to public using (true); *should
>> be ok for updating every row, let insert policy handle new row
>> *. *
>> since there is only one check_expressio
On Tue, May 24, 2022 at 7:42 AM Tom Lane wrote:
> I wrote:
> > Perhaps this should be documented more clearly, but it's not obviously
> > wrong. If the domain declaration doesn't include an explicit COLLATE
> > then casting to the domain doesn't create an explicit collation
> > requirement. (Th
På torsdag 09. juni 2022 kl. 20:24:56, skrev Joshua Drake
mailto:j...@commandprompt.com>>:
Large objects are largely considered a deprecated feature.
Though I like the idea, was there any consensus on -hackers?
Nobody seems interested in it…
--
Andreas Joseph Krogh
CTO / Partner - Visen
Large objects are largely considered a deprecated feature.
Though I like the idea, was there any consensus on -hackers?
JD
On Sun, Jun 5, 2022 at 2:23 AM Andreas Joseph Krogh
wrote:
> I started this thread 5 years ago:
> https://www.postgresql.org/message-id/flat/7c70d9bd-76fc-70fa-cfec-14f00a
Marcus,
This is probably better suited for -hackers.
JD
On Wed, Jun 8, 2022 at 8:00 PM Ma, Marcus wrote:
> Hey,
>
>
>
> I’m currently working on a parallelization optimization of the Sequential
> Scan in the codebase, and I need to share information between the workers
> as they scan a relatio
Lucas,
If you run out of OIDs you are doing something wrong. We haven't supported
user space OIDs in a lot of releases. Which release are you using?
JD
On Thu, Jun 9, 2022 at 2:11 AM Lucas wrote:
> Hello,
>
> In the company I work for, some clusters reached the OID limit (2^32) and
> we had to
Hi ,
its about xid.
u may use the following sqls for check.
---Transaction ID Exhaustion Analysis --
SELECT datname
, age(datfrozenxid)
, current_setting('autovacuum_freeze_max_age')
FROM pg_database where datallowconn = true
ORDER BY 2 DESC;
WI
On 6/9/22 02:10, Lucas wrote:
Hello,
In the company I work for, some clusters reached the OID limit (2^32)
and we had to reinstall the cluster.
Was this really about OIDs or XID wraparound?:
https://www.postgresql.org/docs/14/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
I was wondering if
Lucas writes:
> In the company I work for, some clusters reached the OID limit (2^32) and
> we had to reinstall the cluster.
Uh ... why did you think you needed to do that? The OID counter
will wrap around and things should carry on fine. There are defenses
to prevent creation of duplicate OID
There is a table full of grouped values like the following
nodeid link_type primary
11 outflowlink 1
11 inflowlink 1
11 outflowlink 2
Primary of 1 indicates a primary water course. Primary of 2 indicates a
secondary water course.
Obvio
Hello,
In the company I work for, some clusters reached the OID limit (2^32) and
we had to reinstall the cluster.
I was wondering if there is any discussion on:
* "compress" the OID space
* "warp around" the OID space
* segment a OID range for temporary tables with "wrap around"
--
Lucas
At Thu, 9 Jun 2022 16:26:24 +0900, Ian Lawrence Barwick
wrote in
> 2022年6月9日(木) 14:32 Peter Adlersburg :
> >
> > Dear fellow DBA's,
> >
> >
> > While troubleshooting one of our production replication clusters (phys.
> > streaming replication using the patroni framework)
> > I stumbled over a -
2022年6月9日(木) 14:32 Peter Adlersburg :
>
> Dear fellow DBA's,
>
>
> While troubleshooting one of our production replication clusters (phys.
> streaming replication using the patroni framework)
> I stumbled over a - at least for me - strange phenomenon in the postgres logs
> of the two cluster memb
13 matches
Mail list logo
