>
> We found out because we are monitoring long running queries, and saw it
> had been running for a month before the restart yesterday.
> I just queried pg_stat_activity and it seems to be running since then.
>
> taimusz=# SELECT pid, query_start, usename, left(query,70)
> FROM pg_stat_activity
>
On Tue, May 18, 2021 at 6:46 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > as well as the fact that 0 disables the logical replication
> > subscribing feature altogether, and precludes the background worker
> > scheduler process from launching at startup?
>
> I'd be in favor of
"David G. Johnston" writes:
> Given this, should the configuration description for this include the "This
> parameter can only be set in postgresql.conf file or on the server command
> line." comment,
Hmm, yeah, it does lack the standard boilerplate for a PGC_POSTMASTER
GUC. I wonder which
On Mon, May 17, 2021 at 7:13 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Monday, May 17, 2021, Tom Lane wrote:
> >> It looks like it won't be started if you set
> >> max_logical_replication_workers = 0.
>
> > I was wondering about that. Would you mind posting a link to the code
>
>> El día lunes, mayo 17, 2021 a las 01:27:40p. m. -, haman...@t-online.de
>> escribió:
>> >> > Hi,
>> > >> > in unicode letter ä exists in two versions - linux and windows use a
>> > >> > composite whereas macos prefers
>> > the decomposed form. Is there any way to make a semi-exact match
Hi Gianni,
many thanks for your detailed response.
It turned out that my postgresql installation is too old for normalize,so I
will probably
a) use an external script to normalize existing data
b) change application code to normalize data before inserting or searching
Regards
Wolfgang
>> On
=?UTF-8?Q?Hannes_K=c3=bchtreiber?= writes:
> Hello Tom, thanks for your answer!
> We found out because we are monitoring long running queries, and saw it
> had been running for a month before the restart yesterday.
> I just queried pg_stat_activity and it seems to be running since then.
Oh,
Hello Tom, thanks for your answer!
We found out because we are monitoring long running queries, and saw it
had been running for a month before the restart yesterday.
I just queried pg_stat_activity and it seems to be running since then.
taimusz=# SELECT pid, query_start, usename,
Hi,
I am using postgresql 12.7 on Ubunut as a datawarehouse, that is then
queried by QlikSense to produce business analytics.
One of my dataloaders, that runs multiple queries, sometimes takes about
3 hours to feed Qlik with the relevant records (about 10M records), but
sometimes goes crazy
=?UTF-8?Q?Hannes_K=c3=bchtreiber?= writes:
> We have tried logical replication in a test-setup, and it appears to
> work fine.
> However, the following statement keeps running:
> SELECT pg_catalog.set_config('search_path', '', false);
What makes you think it "keeps running"? It looks to me
Hello everybody,
not sure where to post this, general seems most appropriate.
We have tried logical replication in a test-setup, and it appears to
work fine.
However, the following statement keeps running:
SELECT pg_catalog.set_config('search_path', '', false);
It is issued by the user
G'day all,
A quick follow-up on this issue for interest's sake. The stalling we
were seeing turned out to be a Cloud SQL issue and not related to our
listen/notify usage.
Cloud SQL has an automatic storage increase process that resizes the
underlying disk as required to account for cluster
12 matches
Mail list logo
