On 02/08/22, Robert Blayzor (rblayzor.b...@inoc.net) wrote:
> On 8/2/22 10:57, Rory Campbell-Lange wrote:
> > Special care must be taken with the "replica identity" of published
> > tables, as set out at
> > https://www.postgresql.org/docs/current/logical-replication-publication.html.
>
> We would
I wrote:
> bruno da silva writes:
>> Do you have a lot of especially long statements being tracked
>> in the pg_stat_statements view?* well, the view was showing the query
>> column null.*
>> * but looking on pgss_query_texts.stat there are very large sql
>> statements, of around ~ 400kb, multipl
bruno da silva writes:
> Do you have a lot of especially long statements being tracked
> in the pg_stat_statements view?* well, the view was showing the query
> column null.*
> * but looking on pgss_query_texts.stat there are very large sql
> statements, of around ~ 400kb, multiple thousands. *
Hello.
Are you quite sure this is a 9.5.21 version of the pg_stat_statements
extension? *I got version 1.3 from SELECT * FROM pg_extension;*
Is it possible that the pg_stat_tmp directory has been made non-writable? *hard
to tell if it was made non-writable during the outage. but now it is
writable
Do you have a lot of especially long statements being tracked
in the pg_stat_statements view?* well, the view was showing the query
column null.*
* but looking on pgss_query_texts.stat there are very large sql
statements, of around ~ 400kb, multiple thousands. *
Are there any other signs of distr
bruno da silva writes:
> After more investigation, we found that pgss_query_texts.stat of a size of
> 2.2GB. and this deployment has a 32bit pg.
Hm ... we've heard one previous report of pg_stat_statements' query text
file getting unreasonably large, but it's not clear how that can come
to be. D
Hello.
After more investigation, we found that pgss_query_texts.stat of a size of
2.2GB. and this deployment has a 32bit pg.
and this errors:
*postgresql-2022-07-12-20:07:15.log.gz:[2022-07-14 11:17:06.713 EDT]
207.89.58.230(46964) {62c87db0.8eb2} LOG: out of
memorypostgresql-2022-07-12-20
On 02/08/22, Robert Blayzor (rblayzor.b...@inoc.net) wrote:
> Is it possible to have a single subscriber table contact multiple publishers
> and just insert all of the data into a single table on the subscriber? ie:
> merge type replication. There are no primary/FK constraints, etc. The
> records
On Mon, Aug 1, 2022 at 10:16 AM Rick Otten wrote:
>
>> The other problem I ran into, which I'm still building a test case for
>> and I fear might be a bug if I can easily reproduce it,
>> is if I did the original select in a CTE, and then did a sort outside of
>> the CTE, even though the CTE foun
On Tue, 2 Aug 2022 at 19:48, Ameya Bidwalkar
wrote:
> We have a Postgresql 13 database where we have a single table with several
> millions of rows . We plan to partition it based on timestamp .
> We have been seeking advice for best practices for building this.
> This table will get lots of u
We have a Postgresql 13 database where we have a single table with
several millions of rows . We plan to partition it based on timestamp .
We have been seeking advice for best practices for building this.
This table will get lots of updates for the same rows during a short period
of time.During
11 matches
Mail list logo
