Christophe Pettus writes:
>> On May 13, 2024, at 11:26, Adrian Klaver wrote:
>> May not induce the error unless there are parallel workers involved.
> Indeed. I'll see about pulling together a test case that forces that.
Right. Once a backend process has loaded a zone file, it caches that
in
> On May 13, 2024, at 11:26, Adrian Klaver wrote:
> May not induce the error unless there are parallel workers involved.
Indeed. I'll see about pulling together a test case that forces that.
Christophe Pettus writes:
> On May 13, 2024, at 11:17, Tom Lane wrote:
>> What's causing that I can't say. It doesn't look like we log the
>> errno anywhere when failing to read a zone file :-(
> File descriptor exhaustion? (Of course, that would mean something somewhere
> is leaking them, wh
On 5/13/24 11:18 AM, Christophe Pettus wrote:
On May 13, 2024, at 11:17, Tom Lane wrote:
What's causing that I can't say. It doesn't look like we log the
errno anywhere when failing to read a zone file :-(
File descriptor exhaustion? (Of course, that would mean something somewhere is
> On May 13, 2024, at 11:17, Tom Lane wrote:
> What's causing that I can't say. It doesn't look like we log the
> errno anywhere when failing to read a zone file :-(
File descriptor exhaustion? (Of course, that would mean something somewhere is
leaking them, which is another problem.)
Christophe Pettus writes:
> On May 13, 2024, at 10:48, Adrian Klaver wrote:
>> https://www.postgresql.org/message-id/1273542.1712326418%40sss.pgh.pa.us
> Thanks! Similar, but I don't think it's that. This was a sudden change in a
> long-running connection that had issued a ton of ` SET TIMEZO
> On May 13, 2024, at 11:07, Adrian Klaver wrote:
>
>
> What does pg_config --configure show for '--with-system-tzdata' ?
It's a local compile, and was built without that.
As an experiment, I'm just pounding the server with a single connection doing
nothing but SET TIMEZONEs repeatedly. S
On 5/13/24 11:02 AM, Christophe Pettus wrote:
On May 13, 2024, at 10:58, Adrian Klaver wrote:
You sure the timezone file did not get changed under the connection?
Yes (at least, nothing happened on the system that would indicate that). The
system wasn't touched during the execution (a
> On May 13, 2024, at 10:58, Adrian Klaver wrote:
>
> You sure the timezone file did not get changed under the connection?
Yes (at least, nothing happened on the system that would indicate that). The
system wasn't touched during the execution (and, as noted, it worked after as
well as befo
> On May 13, 2024, at 10:53, Erik Wienhold wrote:
> Can you trigger that error with:
>
> SET timezone = 'UTC';
No, that works correctly:
psql (16.3)
Type "help" for help.
df=> SET timezone = 'UTC';
SET
The error popped up during a long-running connection that had issued that SET
many (m
On 5/13/24 10:50 AM, Christophe Pettus wrote:
On May 13, 2024, at 10:48, Adrian Klaver wrote:
Yes:
https://www.postgresql.org/message-id/5DF49366-10D1-42A4-99BF-F9A7DC3AB0F4%40mailbox.org
Answer:
https://www.postgresql.org/message-id/1273542.1712326418%40sss.pgh.pa.us
Thanks! Similar
On 2024-05-13 19:37 +0200, Christophe Pettus wrote:
> PostgreSQL 16.3 on MacOS Sonoma. A long-running process (which held a
> connection open the entire time) failed with:
>
> 2024-05-13 09:12:44.719
> PDT,"cyan","cyan",35926,"[local]",664214f9.8c56,3,"SELECT",2024-05-13
> 06:26:17 PDT,3/60
> On May 13, 2024, at 10:48, Adrian Klaver wrote:
> Yes:
>
> https://www.postgresql.org/message-id/5DF49366-10D1-42A4-99BF-F9A7DC3AB0F4%40mailbox.org
>
> Answer:
>
> https://www.postgresql.org/message-id/1273542.1712326418%40sss.pgh.pa.us
Thanks! Similar, but I don't think it's that. This
On 5/13/24 10:37 AM, Christophe Pettus wrote:
PostgreSQL 16.3 on MacOS Sonoma. A long-running process (which held a
connection open the entire time) failed with:
2024-05-13 09:12:44.719 PDT,"cyan","cyan",35926,"[local]",664214f9.8c56,3,"SELECT",2024-05-13 06:26:17 PDT,3/60,0,ERROR,22023
PostgreSQL 16.3 on MacOS Sonoma. A long-running process (which held a
connection open the entire time) failed with:
2024-05-13 09:12:44.719
PDT,"cyan","cyan",35926,"[local]",664214f9.8c56,3,"SELECT",2024-05-13 06:26:17
PDT,3/60,0,ERROR,22023,"invalid value for parameter ""TimeZone"":
""UT
On Monday, May 13, 2024, Zwettler Markus (OIZ)
wrote:
>
>
> but I do not want to suppress errors that are related to infrastructure
> problems, i.e. "could not open file..."
>
>
The server doesn’t classify the errors it emits into scope, “application
errors” and ”infrastructure errors”, or otherwi
> Von: Tom Lane
> Gesendet: Montag, 13. Mai 2024 16:26
> An: Zwettler Markus (OIZ)
> Cc: pgsql-general@lists.postgresql.org
> Betreff: [Extern] Re: how to completely turn off statement error logging
>
> "Zwettler Markus (OIZ)" writes:
> > I don't want to log statement errors in the server logfi
"Zwettler Markus (OIZ)" writes:
> I don't want to log statement errors in the server logfile - whether the
> statement string nor the error message.
You need to set log_min_messages higher than ERROR. You might
consider using LOG or FATAL rather than PANIC, though.
> I set "log_min_error_state
On Tue, 14 May 2024 at 02:07, Dimitrios Apostolou wrote:
>
> On Tue, 14 May 2024, David Rowley wrote:
> > Parallel Append can also run in a way that the Append child nodes will
> > only get 1 worker each.
>
> How can I tell which case it is, from the EXPLAIN output (for example
> the output at [1]
On Tue, 14 May 2024 at 01:52, Dimitrios Apostolou wrote:
>
> On Tue, 14 May 2024, David Rowley wrote:
> > The query does contain an ORDER BY, so if the index is not chosen to
> > provide pre-sorted input, then something has to put the results in the
> > correct order before the LIMIT is applied.
>
On Mon, May 13, 2024 at 2:53 AM Vidyashree H S <
shreevidya...@exaleapsemi.com> wrote:
>
>- Is that multi master replication is not recommended to do ?
>
>
No, it is not recommended, as it has a very, very narrow use case, and
comes with a lot of drawbacks. Sure, you COULD configure your car t
I don't want to log statement errors in the server logfile - whether the
statement string nor the error message.
I set "log_min_error_statement = panic" according to the docs:
To effectively turn off logging of failing statements, set this parameter to
PANIC.
But error messages are still l
On Tue, 14 May 2024, David Rowley wrote:
That assumes the Append won't ever use > 1 worker per subnode, but
that's not the case for your plan as the subnodes are "Parallel".
That means all the workers could be working on the same subnode which
could result in one group being split between 2 o
On Tue, 14 May 2024, David Rowley wrote:
On Tue, 14 May 2024 at 00:41, Dimitrios Apostolou wrote:
On Sat, 11 May 2024, David Rowley wrote:
It will. It's just that Sorting requires fetching everything from its subnode.
Isn't it plain wrong to have a sort step in the plan than? The different
On Tue, 14 May 2024 at 00:46, Dimitrios Apostolou wrote:
>
> On Mon, 13 May 2024, Dimitrios Apostolou wrote:
>
> > On Sat, 11 May 2024, David Rowley wrote:
> >> If you look at [1], it says "Tuples changed in partitions and
> >> inheritance children do not trigger analyze on the parent table."
>
On Tue, 14 May 2024 at 00:41, Dimitrios Apostolou wrote:
>
> On Sat, 11 May 2024, David Rowley wrote:
> > It will. It's just that Sorting requires fetching everything from its
> > subnode.
>
> Isn't it plain wrong to have a sort step in the plan than? The different
> partitions contain different
On Tue, 14 May 2024 at 00:28, Dimitrios Apostolou wrote:
>
> On Sat, 11 May 2024, David Rowley wrote:
>
> > On Sat, 11 May 2024 at 13:33, Tom Lane wrote:
> >> I do kind of wonder why it's producing both a hashagg and a Unique
> >> step --- seems like it should do one or the other.
> >
> > It stil
On Mon, 13 May 2024, Dimitrios Apostolou wrote:
On Sat, 11 May 2024, David Rowley wrote:
On Sat, 11 May 2024 at 13:11, Dimitrios Apostolou wrote:
Indeed that's an awful estimate, the table has more than 1M of unique
values in that column. Looking into pg_stat_user_tables, I can't see the
On Sat, 11 May 2024, David Rowley wrote:
On Sat, 11 May 2024 at 13:11, Dimitrios Apostolou wrote:
Indeed that's an awful estimate, the table has more than 1M of unique
values in that column. Looking into pg_stat_user_tables, I can't see the
partitions having been vacuum'd or analyzed at all. I
On Sat, 11 May 2024, David Rowley wrote:
On Sat, 11 May 2024 at 13:33, Tom Lane wrote:
I do kind of wonder why it's producing both a hashagg and a Unique
step --- seems like it should do one or the other.
It still needs to make the duplicate groups from parallel workers unique.
Range parti
Hi,
*
Is that multi master replication is not recommended to do ?
*
If we can do, can I get any resource for implementing that on PostgreSQL which
is open-source?
Thanks,
Vidyshree H S
From: Vidyashree H S
Sent: Friday, May 10, 2024 10:48 AM
To: Bruce
31 matches
Mail list logo
