Hi,
sorry, but we have the case number 3 in with the same problem.
Also this time we do not find any linux box crash nor pg stop or restart.
The pg version is 7.4.2 on dual xeon + scsi running also RedHat 3.0 AS.
In all the cases we are running RedHat AS 3.0.
This system was running for over 1
AFAIK, the input for a timestamptz is converted and stored as UTC.
And outputing a timezonetz value converts the internally stored UTC
value to the current locale's timezone.
So there is not a way to actually store the original TZ itself,
whereas the timetz type clearly does that.
Consider a sch
Title: Message
Hi Theo,There have been 2 major changes
between the 7 and 8 versions that affect the coding in xml2. You need to
edit the source code in order for it to compile properly on 7.First,
work_mem has to be changed to SortMem (line 666).
I.e. tupstore = tuplestore_begin_heap(tr
On 2005-02-21, Achilleus Mantzios <[EMAIL PROTECTED]> wrote:
> Consider a schema designed to store internet mail.
>
> Since pgsql always converts a timestamptz to UTC, we have lost
> the information of the Sender's local timezone.
>
> Should i go with a separete date and timetz ?
No. Consider inst
O Andrew - Supernews έγραψε στις Feb 21, 2005 :
> On 2005-02-21, Achilleus Mantzios <[EMAIL PROTECTED]> wrote:
> > Consider a schema designed to store internet mail.
> >
> > Since pgsql always converts a timestamptz to UTC, we have lost
> > the information of the Sender's local timezone.
> >
> > S
If I have a table with an attribute of type "timestamp without time
zone", what is the best way to query that table for records that are
older than, say, one week.
I suppose I could get the current time in epoch seconds and the time of
the attribute in the same, and select those records where the
Brandon Metcalf wrote:
If I have a table with an attribute of type "timestamp without time
zone", what is the best way to query that table for records that are
older than, say, one week.
I suppose I could get the current time in epoch seconds and the time of
the attribute in the same, and select th
m == martin@bugs.unl.edu.ar writes:
m> El Lun 21 Feb 2005 17:00, Brandon Metcalf escribió:
m> > If I have a table with an attribute of type "timestamp without time
m> > zone", what is the best way to query that table for records that are
m> > older than, say, one week.
m> >
m> > I suppose I
El Lun 21 Feb 2005 17:00, Brandon Metcalf escribió:
> If I have a table with an attribute of type "timestamp without time
> zone", what is the best way to query that table for records that are
> older than, say, one week.
>
> I suppose I could get the current time in epoch seconds and the time of
>
pginfo <[EMAIL PROTECTED]> writes:
> sorry, but we have the case number 3 in with the same problem.
> Also this time we do not find any linux box crash nor pg stop or restart.
Hmm, well there's *something* mighty curious about the history of this
table. The xmin values span a range of almost 400,
Hi Tom,
Tom Lane wrote:
pginfo <[EMAIL PROTECTED]> writes:
sorry, but we have the case number 3 in with the same problem.
Also this time we do not find any linux box crash nor pg stop or restart.
Hmm, well there's *something* mighty curious about the history of this
tab
On Mon, Feb 21, 2005 at 16:16:04 +0200,
Achilleus Mantzios <[EMAIL PROTECTED]> wrote:
>
> Since pgsql always converts a timestamptz to UTC, we have lost
> the information of the Sender's local timezone.
>
> Should i go with a separete date and timetz ?
Someone else gave you a recommended solut
O Bruno Wolff III έγραψε στις Feb 22, 2005 :
> On Mon, Feb 21, 2005 at 16:16:04 +0200,
> Achilleus Mantzios <[EMAIL PROTECTED]> wrote:
> >
> > Since pgsql always converts a timestamptz to UTC, we have lost
> > the information of the Sender's local timezone.
> >
> > Should i go with a separete
13 matches
Mail list logo
