public inbox for [email protected]  
help / color / mirror / Atom feed
Re: UTC is not a time zone?
6+ messages / 3 participants
[nested] [flat]

* Re: UTC is not a time zone?
@ 2024-05-13 18:17  Tom Lane <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Tom Lane @ 2024-05-13 18:17 UTC (permalink / raw)
  To: Christophe Pettus <[email protected]>; +Cc: Adrian Klaver <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>

Christophe Pettus <[email protected]> writes:
> On May 13, 2024, at 10:48, Adrian Klaver <[email protected]> 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 TIMEZONE TO 'UTC'; ` before the failure.

The underlying cause is likely roughly similar, to wit failure to read
/usr/share/zoneinfo/UTC (or the Postgres-private equivalent file).
The parent process would long since have cached the zone data in its
memory, but this error is in a parallel worker process, which'd have
to read the file for itself during startup.

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 :-(

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: UTC is not a time zone?
@ 2024-05-13 18:18  Christophe Pettus <[email protected]>
  parent: Tom Lane <[email protected]>
  0 siblings, 2 replies; 6+ messages in thread

From: Christophe Pettus @ 2024-05-13 18:18 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Adrian Klaver <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>



> On May 13, 2024, at 11:17, Tom Lane <[email protected]> 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.)





^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: UTC is not a time zone?
@ 2024-05-13 18:26  Adrian Klaver <[email protected]>
  parent: Christophe Pettus <[email protected]>
  1 sibling, 1 reply; 6+ messages in thread

From: Adrian Klaver @ 2024-05-13 18:26 UTC (permalink / raw)
  To: Christophe Pettus <[email protected]>; Tom Lane <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]>



On 5/13/24 11:18 AM, Christophe Pettus wrote:
> 
> 
>> On May 13, 2024, at 11:17, Tom Lane <[email protected]> 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.)

If I am understanding this correctly:

"The parent process would long since have cached the zone data in its
memory, but this error is in a parallel worker process, which'd have
to read the file for itself during startup.
"

Then this:

"As an experiment, I'm just pounding the server with a single connection 
doing nothing but SET TIMEZONEs repeatedly.  So far, no break, but it is 
*very* intermittent."

May not induce the error unless there are parallel workers involved.

-- 
Adrian Klaver
[email protected]






^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: UTC is not a time zone?
@ 2024-05-13 18:27  Christophe Pettus <[email protected]>
  parent: Adrian Klaver <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Christophe Pettus @ 2024-05-13 18:27 UTC (permalink / raw)
  To: Adrian Klaver <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>



> On May 13, 2024, at 11:26, Adrian Klaver <[email protected]> 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.







^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: UTC is not a time zone?
@ 2024-05-13 18:27  Tom Lane <[email protected]>
  parent: Christophe Pettus <[email protected]>
  1 sibling, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-05-13 18:27 UTC (permalink / raw)
  To: Christophe Pettus <[email protected]>; +Cc: Adrian Klaver <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>

Christophe Pettus <[email protected]> writes:
> On May 13, 2024, at 11:17, Tom Lane <[email protected]> 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.)

Since this is in a pretty-new process, it would have to be global FD
exhaustion, that is ENFILE not EMFILE.  (Assuming macOS even has
that concept; its BSD roots sure do, but who knows what Apple's
done to it over the years.)  You'd likely have seen more side-effects
of such a condition.

I was wondering more about permissions checks gone wrong, comparable
to the antivirus-induced misbehaviors we hear about on Windows.
Not that that's a comforting answer.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: UTC is not a time zone?
@ 2024-05-13 18:36  Tom Lane <[email protected]>
  parent: Christophe Pettus <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-05-13 18:36 UTC (permalink / raw)
  To: Christophe Pettus <[email protected]>; +Cc: Adrian Klaver <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>

Christophe Pettus <[email protected]> writes:
>> On May 13, 2024, at 11:26, Adrian Klaver <[email protected]> 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 a hash table that it will never flush (which is arguably a bug for
other reasons, since those files aren't really immutable, but that's
how it behaves today).  So you've got 0 chance of hitting this via
repeat SET TIMEZONE in a single backend.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2024-05-13 18:36 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-05-13 18:17 Re: UTC is not a time zone? Tom Lane <[email protected]>
2024-05-13 18:18 ` Christophe Pettus <[email protected]>
2024-05-13 18:26   ` Adrian Klaver <[email protected]>
2024-05-13 18:27     ` Christophe Pettus <[email protected]>
2024-05-13 18:36       ` Tom Lane <[email protected]>
2024-05-13 18:27   ` Tom Lane <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox