Re: [BUGS] converting between infinity timestamp and float8 (epoch)
TODO added: Determine how to represent date/time field extraction on infinite timestamps extract(epoch from infinity) is not 0 converting between infinity timestamp and float8 --- On Fri, Dec 30, 2011 at 12:51:56PM +1300, Gavin Flower wrote: > On 28/12/11 10:43, Phil Sorber wrote: > >On Tue, Dec 27, 2011 at 1:00 PM, Tom Lane wrote: > >>Phil Sorber writes: > >>>My search foo failed me. Someone just pointed me to a similar > >>>conversation from some months ago: > >>>http://archives.postgresql.org/pgsql-hackers/2011-07/msg00677.php > >>>I would propose that since we can't know the hour or minute of > >>>infinity that we should return null for those. I think NaN would be > >>>wrong because it is a real number, it's just unknown. If we can just > >>>pass infinity through the function, I think we should. > >>The last thread ended with a request for somebody to think through > >>the behavior for *all* extract field types and make a coherent proposal. > >>I don't think you've really advanced the discussion yet. > >> > >>I think I agree with the position that we shouldn't return 0 unless > >>the correct value actually is 0, but it's not clear to me whether > >>to use NULL or NaN to represent "indeterminate". Traditionally we > >>consider NULL to mean "unknown", but it seems like "what's the hour > >>of an infinite timestamp" is a subtly different sort of situation: > >>it's not unknown, we know perfectly well that it's indeterminate. > >>OTOH, choosing NaN would put a pretty significant dependence on > >>IEEE-float arithmetic into the external specification of timestamps, > >>and I find that a bit worrisome, even though IEEE float arithmetic > >>is nigh universal these days. So maybe splitting hairs like that > >>would be ill-advised. It probably depends also on what you expect > >>people to do with the result of extract() --- NULL would presumably > >>propagate through any additional calculation steps as-is, whereas > >>NaN might have less predictable behavior. > >> > >>There was also some support for throwing an error in the previous > >>thread, though I can't say I like that answer myself. > >> > >>regards, tom lane > >It is my understanding that NULL would be for "unknown" or "undefined" > >and NaN for "indeterminate" as well as some other cases like complex > >numbers. I believe per the standard NaN explicitly includes > >indeterminate forms. But I don't think extract(hour from > >'infinity'::timestamp) is an indeterminate form > >(http://en.wikipedia.org/wiki/Indeterminate_form). It is an > >oscillating function similar to sin(x). Limit of sin(x) as x > >approaches infinity is undefined. To me that points to NULL as the > >appropriate value. > > > >Also, like epoch, the expressions that involve year are not > >oscillating. They are monotonic. the limit of extract(millennium from > >'infinity'::timestamp) is infinity. > > > >I'm not going to claim to be a mathematician, so I concede I might be > >wrong with my thought process here. > > > >Given the preceding is true, my proposal is the following for > >extract() when passed an infinite timestamp: > > > >1) Monotonic values (century, decade, epoch, isoyear, millennium and > >year) we return 'infinity'::float8 signed appropriately. > > > >2) Oscillating values (day, dow, doy, hour, isodow, microseconds, > >milliseconds, minute, month, quarter, second and week) would return > >NULL. > > > >3) timezone, timezone_hour and timezone_minute are almost a separate > >issue since timezone is separate from the value. So we should support > >something like 'infinity-05'::timestamp with time zone. Then the > >timezone stuff would just behave normally. > > > >Currently it does this: > > > >postgres=# select 'infinity+00'::timestamp with time zone; > > timestamptz > >- > > infinity > >(1 row) > > > >postgres=# select 'infinity-05'::timestamp with time zone; > >ERROR: invalid input syntax for type timestamp with time zone: "infinity-05" > >LINE 1: select 'infinity-05'::timestamp with time zone; > >^ > > > Hmm... > > Infinity is conceptually the 'maximum' value possible - or more > pr4ecisely: a value greater than any you can specify a concrete > value for in finite time. > > So I think the appropriate value should be the maximum > representational possibility and should be the same regardless of > time zone, plus any operation such as adding or subtracting finite > values should not change it (arithmetic ops with another 'infinite' > value should be either an error or a NaN/Null). This is to > consistent that with the notion of infinity. > > I would suggest that hh:mm:ss.... > should be: 23:59:59.... > > > Cheers, > Gavin > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/
Re: [BUGS] BUG #6404: postgres account not created during unattended install
Thank you for your reply.
On Feb 3, 2012, at 9:31 AM, Dharmendra Goyal wrote:
> On Fri, Feb 3, 2012 at 10:37 PM, Mark Phillips
> wrote:
> After considering your remarks and modifying the app install script, the app
> installation completes normally with a functioning PostgreSQL installation.
> However, the errors reported previous still appear in the logs.
> If erros which you sent last tim appear even when you run the installation
> first time, it means that there was an existing installation of postgres. You
> can confirm same by checking /etc/postgres-reg.ini file.
Immediately after restoration of the vm image, there is no file
/etc/postgres-reg.ini. Perhaps it is placed elsewhere by the OS X designers. I
cannot find it with locate enabled and run as root.
The file is present after I run the postgres installer.
> To recap the questions:
> 1. are the errors reported in the postgres install log of a type to cause a
> malfunction for end users?
> Even if the error (postgres user not found) is there in the log, it will not
> cause any problem to the end user. Error is coming because installer finds a
> previous installation of PG hence tries to stop the existing pg server if it
> is running. So even if it is not able to stop any, it is not going to cause
> any issue as subsequent installation of pg goes fine.
This is good news. :-)
> 2. how can I suppress the appearance of the user account "PostgreSQL" in the
> os x login window?
> Please check /etc/postgres-reg.ini file for bindled pg installation.
Forgive me for being redundant, but I cannot locate a file named
"postgres-reg.ini" prior to running the installer.
Here is the content from the file /etc/postgres-reg.ini written by the postgres
installer:
$ cat etc/postgres-reg.ini
[PostgreSQL/9.1]
Branding=PostgreSQL 9.1
DataDirectory=/Library/PostgreSQL/9.1/data
Description=PostgreSQL 9.1
DisableStackBuilder=0
InstallationDirectory=/Library/PostgreSQL/9.1
Locale=C
Port=5432
Serviceaccount=postgres
ServiceID=postgresql-9.1
Shortcuts=1
Superuser=postgres
Version=9.1.2.1
You thoughts are most welcome.
- Mark
>
> Many thanks,
>
> - Mark
>
> On Jan 30, 2012, at 11:34 PM, Dharmendra Goyal wrote:
>
>> Hi Mark,
>>
>> Install log shows that your db installation is successful. The error which
>> you had sent is coming because your earlier installation failed to create
>> 'postgres' user and when you ran the installer again, installer read
>> /etc/postgres-reg.ini file to check any previous installation and found that
>> previous installation was done. Hence installer tries to stop the db server
>> in case it is running using postgres user. This command fails as postgres
>> user was not created in your first installation because of some reason. But
>> in latest installation (for which you have sent the log), postgres user has
>> been created successfully and installation went successfully. You need to
>> check why postgres user was not created in first go by checking logs of that
>> installation.
>>
>> You are checking return status of the installbuilder.sh command run which is
>> not 0 hence you are getting error ("install of DBMS failed".) in your
>> script. Can yu please check what is the return value in your script of
>> installbuilder.sh.
>>
>> Regards,
>>
>> On Tue, Jan 31, 2012 at 5:37 AM, Mark Phillips
>> wrote:
>>
>> On Jan 29, 2012, at 11:07 PM, Dharmendra Goyal wrote:
>>
>>> On Sat, Jan 21, 2012 at 3:01 AM, wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 6404
>>> Logged by: Mark Phillips
>>> Email address: mark.phill...@mophilly.com
>>> PostgreSQL version: 9.1.2
>>> Operating system: Mac OS X 10.7
>>> Description:
>>>
>>> for a stand alone app that uses postgres, the app installer invokes the
>>> shell script installbuilder.sh for the "unattended" install of postgres.
>>>
>>> The pg installer creates a user "PostgreSQL" that is not hidden, but does
>>> not create a hidden account "postgres". As a result, the invocation of
>>> pg_ctl fails. Error is "unknown login: postgres".
>>> pg installer creates "postgres" user which somehow seems to be failing at
>>> your machine. Can you please send installation log which can be found under
>>> /tmp/install-postgresql.log. Also if you can run
>>> installation_path/installer/server/createuser.sh script manually and check
>>> the output, it can be helpful.
>>>
>>> Thanks,
>>> --
>>> Dharmendra Goyal
>>
>> Thank you for the reply. I apologize for the delay in responding.
>>
>> File install-postgresql.log attached.
>>
>> Please review the link below to a post in the postgresql forum for a bit
>> more detail about this issue:
>>
>> http://forums.enterprisedb.com/posts/list/3042.page
>>
>> I looked into running the createuser.sh script. However, I encountered a bit
>> of new information before I could get that far so I include it here in case
>> it is relevant.
>>
>> Beginning anew
Re: [BUGS] BUG #6425: Bus error in slot_deform_tuple
We deployed the patch to one of our production slaves at 3:30 PM yesterday (so roughly 20 hours ago), and since then we have not seen any alloc errors. On Feb 2nd, the last full day in which we ran without the patch, we saw 13 alloc errors. We're going to continue monitoring this slave, but we're cautiously optimistic that the patch does address the alloc errors we've been seeing. It will take a few weeks to be able to definitively see if it fixes the segfault, too. Thanks again, Tom, for your efforts on this. We do seem to be in much better shape than we were before the patch! -B
Re: [BUGS] BUG #6425: Bus error in slot_deform_tuple
On Fri, Feb 3, 2012 at 6:45 AM, Tom Lane wrote:
> I wrote:
>> I have not gotten very far with the coredump, except to observe that
>> gdb says the Assert ought to have passed: ...
>> This suggests very strongly that indeed the buffer was changing under
>> us.
>
> I probably ought to let the test case run overnight before concluding
> anything, but at this point it's run for two-plus hours with no errors
> after applying this patch:
>
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index cce87a3..b128bfd 100644
> *** a/src/backend/access/transam/xlog.c
> --- b/src/backend/access/transam/xlog.c
> *** RestoreBkpBlocks(XLogRecPtr lsn, XLogRec
> *** 3716,3724
> }
> else
> {
> - /* must zero-fill the hole */
> - MemSet((char *) page, 0, BLCKSZ);
> memcpy((char *) page, blk, bkpb.hole_offset);
> memcpy((char *) page + (bkpb.hole_offset +
> bkpb.hole_length),
> blk + bkpb.hole_offset,
> BLCKSZ - (bkpb.hole_offset +
> bkpb.hole_length));
> --- 3716,3724
> }
> else
> {
> memcpy((char *) page, blk, bkpb.hole_offset);
> + /* must zero-fill the hole */
> + MemSet((char *) page + bkpb.hole_offset, 0,
> bkpb.hole_length);
> memcpy((char *) page + (bkpb.hole_offset +
> bkpb.hole_length),
> blk + bkpb.hole_offset,
> BLCKSZ - (bkpb.hole_offset +
> bkpb.hole_length));
>
>
> The existing code makes the page state transiently invalid (all zeroes)
> for no particularly good reason, and consumes useless cycles to do so,
> so this would be a good change in any case. The reason it is relevant
> to our current problem is that even though RestoreBkpBlocks faithfully
> takes exclusive lock on the buffer, *that is not enough to guarantee
> that no one else is touching that buffer*. Another backend that has
> already located a visible tuple on a page is entitled to keep accessing
> that tuple with only a buffer pin. So the existing code transiently
> wipes the data from underneath the other backend's pin.
>
> It's clear how this explains the symptoms
Yes, that looks like the murder weapon.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
