just testing
sorry
begin:vcard
n:Gonzalez;Hernan
x-mozilla-html:FALSE
org:Sinectis S.A.;Depto de Sistemas (Oficina Central)
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;0
fn:Hernan Gonzalez
end:vcard
I am stuck with a segmentation fault while running pg_upgrade, from 8.4.3 to
9.0.1
$ ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D /var/pgsql-9_0_1/data/ -b
/var/pgsql-8_4_3/bin/ -B /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G
debug
Running in verbose mode
Running in debug mode
PerForming Consistenc
2010/11/2 Grzegorz Jaśkiewicz
> try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
> /var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
> /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
> and when it fails, type in 'bt' and paste it here please.
>
> --
> GJ
>
Well, this is strange. I
2010/11/2 hernan gonzalez
> 2010/11/2 Grzegorz Jaśkiewicz
>
> try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
>> /var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
>> /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
>> and when it fails, type in &#
In pg_upgrade/controldata.c , putenv2 function :
char *envstr = (char *) pg_malloc(ctx, strlen(var)
+ strlen(val) + 1);
sprintf(envstr, "%s=%s", var, val);
Shouldn't it be "+ 2 " instead of "+ 1" ? (one for the '=', plus one for
the null terminating char) ?
I think that
Replacing that 1 for 2 it's enough for making it work, for me, it seems.
But it's not enough to get valgrind happy (It still reports 4 "definitely
lost" blocks, all from that putenv2 function). Perhaps that's related to the
comment:
/*
* Do not free envstr because it becomes pa
Most examples in the array documentation uses ARRAY[1,2,3] and similar.
http://www.postgresql.org/docs/9.0/interactive/functions-array.html
I think (actually I have experienced it, both in myself and others)
that this can be misleading in some cases.
For example: array_upper(ARRAY[1,2,3,4], 1)
(After dealing a while with this, and learning a little, I though of
post this as comment in the docs, but perhaps someone who knows better
can correct or clarify)
=
The issues of charset encodings
> It seems to me that postgres is trying to do as you suggest: text is
> characters and bytea is bytes, like in Java.
But the big difference is that, for text type, postgresql knows "this
is a text"
but doesnt know the encoding, as my example showed. This goes against
the concept of "text vs byt
> Umm, I think all you showed was that the to_ascii() function was
> broken. Postgres knows exactly what encoding the string is in, the
> backend encoding: in your case UTF-8.
That would be fine, if it were true; then, one could assume that every
postgresql function that returns a text gets ALW
> IMHO, the semantics of encode() and decode() are correct (the bridge
> between bytea and text ... in the backend encoding; they should be the
> only bridge), convert() is also ok (deals with bytes), but
> convert_to() and convert_from() are dubious if not broken: they imply
> texts in arbitrary e
Another example (Psotgresql 8.3.0, UTF-8 server/client encoding)
test=# create table chartest ( c text);
test=# insert into chartest (c) values ('¡Hasta mañana!');
test=# create view vchartest as
select encode(convert_to(c,'LATIN9'),'escape') as c1 from chartest;
test=# select c,octet_length(c
I'm doing some tests with date-time related fields to design my web
application.
I was already dissatisfied with Postgresql handling of timezones
concepts (issue
already discussed here - not entirely PG's fault, rather a SQL thing)
and I vehemently
reject the idea of a global server-side timezone
> There are any number of
> server-side settings that can affect the interpretation (and display)
> of your data. Datestyle for example already renders this position
> untenable.
What makes me a little uncomfortable in this assertion -and in many
parts of PG docs-
is that emphasis put on what "is
I plan to define two domains with no contraints, sort of typedefs, to
work with date-times inside my application:
CREATE DOMAIN instant AS timestamp(3) with time zone;
CREATE DOMAIN localdatetime AS timestamp(3) without time zone;
Two questions:
1. I guess that there is no performance penalty
to_timestamp() returns a TIMESTAMP WITH TIME ZONE
Perhaps an alternative that returns a TIMESTAMP WITHOUT TIME ZONE (which,
BTW, is the default TIMESTAMP)
should be provided. Elsewhere, there is no direct-robust way of parsing
a TIMESTAMP WITHOUT TIME ZONE (which
represesents a "local date-time"
There is some related discussion here
http://postgresql.1045698.n5.nabble.com/to-timestamp-returns-the-incorrect-result-for-the-DST-fall-over-time-td3327393.html
But it amounts to the same thing: TO_TIMESTAMP() is not apt for dealing with
plain TIMESTAMP
(without time zones).
Hence, there is no f
> Rather than being not viable, I'd argue that is is not correct. Rather, a
> simple direct cast will suffice:
> '2011-12-30 00:30:00'::timestamp without time zone
>
That works only for that particular format. The point is that, for example,
if I have some local date time
stored as a string in ot
On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver wrote:
> On 06/23/2011 11:40 AM, hernan gonzalez wrote:
>
>>Rather than being not viable, I'd argue that is is not correct.
>>Rather, a simple direct cast will suffice:
>>'2011-12-30 00:30:00'::ti
>
>
> Every example here starts, at its core, with to_timestamp. That function
> returns a timestamp *with* time zone so of-course the current timezone
> setting will influence it. Stop using it - it doesn't do what you want.
>
> If you cast directly to a timestamp *without* time zone you can take
nyway, from the
point of view of the app developer, it sounds strange sometimes.
BTW, I was curious to see how the JDBC client code dealt wit this, if he was
confortable and if all was clear and foolproof with these TIMESTAMP types at
that level. Well, not very - it seems. See http://goo.gl/L2Pzi , search for
"compromise". Probably JDBC is also to blame here, but anyway...
Regards
Hernan J Gonzalez
On Sat, Jun 25, 2011 at 3:56 AM, David Johnston wrote:
> First: I would suggest your use of “Local Time” is incorrect and that you
> would be better off thinking of it as “Abstract Time”. My responses below
> go into more detail but in short you obtain a “Local” time by “Localizing”
> and “Abstr
>
>
> You might want to review the Theories of Relativity, which pretty much blew
> away
> the notion of an absolute time and introduced the notion of frame of
> reference
> for time.
>
>
Well, I give up.
--
Hernán J. González
http://hjg.com.ar/
I was thinking thinking about the issue asked here, about an error in
a query causing the whole transaction to abort,
http://stackoverflow.com/questions/2741919/can-i-ask-postgresql-to-ignore-errors-within-a-transaction/2745677
which has already bothered so many postgresql users and has been
discus
(Disclaimer: I've been using Postgresql for quite a long time, I
usually deal with non-ascii LATIN-9 characters ,
but that has never been a problem, until now)
My issue summarized: when psql is invoked from a user who has a locale
different from that of the database, the tabular output
is wrong fo
It's surely not a xterm problem, I see the characters ok with just the
\x formatting. I can check also the output redirecting to a file.
My original client_encoding seems to be LATIN9 in both cases,
accorging to the \set ouput.
If I change it (for the root user) to UTF8 with " SET CLIENT_ENCODING
Mmm no: \x displays correctly for me because it sends
the raw text (in LATIN9) and I have set my terminal in LATIN9 (or ISO-8859-15)
And it's not that "xterm is misdisplaying" the text, it just that psql
is ouputting
an EMPTY (zero lenght) string for that field.
(I can even send the output to a
Sorry about a error in my previous example (mixed width and precision).
But the conclusion is the same - it works on bytes:
#include
main () {
char s[] = "ni\xc3\xb1o"; /* 5 bytes , 4 utf8 chars */
printf("|%*s|\n",6,s); /* this should pad a black */
printf("|%.*s|\n",4,s);
Wow, you are right, this is bizarre...
And it's not that glibc intends to compute the length in unicode chars,
it actually counts bytes (c plain chars) -as it should- for computing
field widths...
But, for some strange reason, when there is some width calculation involved
it tries so parse the cha
e());
statement.setString(4, cont.getNombre());
statement.setInt(5, oid);
statement.execute();
statement.close();
mDbConnector.commit();
Thanks in advance,
Hernan
ead a person who had this problem and he fixed changing th cache size but
I wasn't successful.
Any ideas?
On Tue, May 18, 2010 at 11:34 PM, Joshua Tolley wrote:
> On Tue, May 18, 2010 at 1:18 PM, Hernan Danielan
> wrote:
> > Hello! I am using postgress 8.4. I am trying to
fails most of the time. Does the JDBC has a timeOut or something? does
anybody knows another connector that i could use in order to test it?
I am really desperate because i have been with this problem for several days
now.
Thank in advance,
Hernan
On Thu, May 20, 2010 at 12:15 AM, Scott Marlowe
d, speaks of the 'pg_option' file,
and doesn't mention those settings...
Help! Am I missing something stupid?
Hernan Gonzalez
Buenos Aires, Argentina
33 matches
Mail list logo
