Re: [HACKERS] Why format() adds double quote?
2016-01-24 8:04 GMT-02:00 Tatsuo Ishii :
>> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule
>> wrote:
>>>> If we would go this way, question is if we should back patch this or
>>>> not since the patch apparently changes the existing
>>>> behaviors. Comments? I would think we should not.
>>>
>>> I am sure, so we should not backport this change. This can breaks customer
>>> regress tests - and the current behave isn't 100% correct, but it is safe.
>>
>> Quite. This is not a bug fix. It's a behavior change, perhaps for the
>> better.
>
> Added to the commitfest 2016-03.
Hi,
I gone ahead a little and tested this patch and it works like was
proposed, I agree that it's not a bug fix but a new behavior so -1 for
backport.
While applying patch against master
(1129c2b0ad2732f301f696ae2cf98fb063a4c1f8) it offsets two hunks.
Since format() has regression tests I suggest that one should be added
to cover this. It could worth to add the new behavior to the docs,
since there no explicit example for %I.
I performed the follow tests that works as expected using some Portuguese words:
postgres=# create table test (nome varchar, endereço text, "UF"
varchar(2), título varchar);
CREATE TABLE
Time: 80,769 ms
postgres=# select format('%I', attname) from pg_attribute join
pg_class on (attrelid = oid) where relname = 'test';
format
--
"UF"
cmax
cmin
ctid
endereço
nome
tableoid
título
xmax
xmin
(10 rows)
Time: 1,728 ms
postgres=# select format('%I', 'endereco');
format
--
endereco
(1 row)
Time: 0,098 ms
postgres=# select format('%I', 'endereço');
format
--
endereço
(1 row)
Time: 0,088 ms
postgres=# select format('%I', 'あああ');
format
あああ
(1 row)
Time: 0,072 ms
postgres=# select format('%I', 'título');
format
título
(1 row)
Time: 0,051 ms
postgres=# select format('%I', 'título e');
format
"título e"
(1 row)
Time: 0,051 ms
postgres=# select format('%I', 'título_e');
format
------
título_e
(1 row)
Time: 0,051 ms
postgres=# select format('%I', '_título');
format
-
_título
(1 row)
Time: 0,047 ms
postgres=# select format('%I', '1_título');
format
"1_título"
(1 row)
Time: 0,046 ms
Thank you for this!
Best regards,
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why format() adds double quote?
2016-01-26 5:29 GMT-02:00 Tatsuo Ishii : > > I assume you used UTF-8 encoding database. Yes, I do. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why format() adds double quote?
2016-01-26 18:00 GMT-02:00 Daniel Verite :
> ...
> create table abc(U&"foo\2003" int);
>
> U+2003 is 'EM SPACE', in Unicode's General Punctuation block.
>
> With the current version, format('%I', attname) on this column is:
> "foo "
>
> With the patched version, it produces this:
> foo
>
> So the visual hint that there are more characters at the end is lost.
Thanks for advocate, I see here that it even produces that output with
simple spaces.
postgres=# create table x ("aí " text);
CREATE TABLE
postgres=# \d x
Tabela "public.x"
Coluna | Tipo | Modificadores
--+--+---
aí | text |
This will break copy&paste user actions and scripts that parses that output.
Maybe the patch should consider left/right non-printable chars to
choose whether to show or not the " ?
[]s
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why format() adds double quote?
2016-01-26 23:40 GMT-02:00 Tatsuo Ishii :
>> Thanks for advocate, I see here that it even produces that output with
>> simple spaces.
>>
>> postgres=# create table x ("aí " text);
>> CREATE TABLE
>> postgres=# \d x
>> Tabela "public.x"
>> Coluna | Tipo | Modificadores
>> --+--+---
>> aí | text |
>>
>>
>> This will break copy&paste user actions and scripts that parses that output.
>>
>> Maybe the patch should consider left/right non-printable chars to
>> choose whether to show or not the " ?
>
> This is a totally different story from the topic discussed in this
> thread. psql never adds double quotations to column name even with
> upper case col names.
Indeed, you are right.
> If you want to change the existing psql's behavior, propose it
> yourself.
It could be interesting, maybe using a \pset quote_columns_char, I'll
think about, thank you.
Best regards.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Ununsed member in printQueryOpt
I found the following code in src/bin/psql/print.h:155 (master 1d0c3b3f8a) boolquote; /* quote all values as much as possible */ That code was there since: commit a45195a191eec367a4f305bb71ab541d17a3b9f9 Author: Bruce Momjian Date: Thu Nov 4 21:56:02 1999 + Major psql overhaul by Peter Eisentraut. But I didn't found any other references to that "quote" and, after removing that line, the code still compiles without any error/warning. Did I overlook something? Best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] raw output from copy
2015-07-07 3:32 GMT-03:00 Pavel Stehule : > > Hi > > previous patch was broken, and buggy > > Here is new version with fixed upload and more tests > > The interesting is so I should not to modify interface or client - so it > should to work with any current driver with protocol support >= 3. Hi Pavel, Here are some thoughts: 1) from docs: "only row data in network byte order are exported or imported." Should it be "only raw data"? 2) from docs "Because this format doesn't support any delimiter, only one value can be exported or imported. NULL values are not allowed." That "only one value can be exported or imported" is a little sad for someone with a table with more than one column that accepts bytea. The implemented feature doesn't covers the use-case where a table 'image' has columns: id integer, image bytea, thumbnail bytea, and I want to import binary data in that. We could put here the cases where we have NOT NULL columns. Since these are expected and the error messages complain about that couldn't them be covered in docs more explicitly? 3) from code: "bool row_processed; /* true, when first row was processed */" Maybe rename the variable to something like `first_row_processed` and rip off the comment? 4) from code: if (cstate->raw) format = 2; else if (cstate->binary) format = 1; else format = 0; Maybe create a constant for code readability? If by one side this feature does not covers a more generalized case, by other is a nice start, IMHO. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
Hello hackers, * Description This patch is a proposal to allow the use of word 'semester' to extract it from date in functions like EXTRACT, DATE_PART, etc and adds the letter 'S' to format the date output in to_char. ** Example SELECT EXTRACT(semester FROM DATE '2015-07-07'); date_part --- 2 * Motivation The term is used in a school or college to represent a half-year. Actually it could be evaluated from a date using some math with 'quarter' but could not be extracted from date since the API to define a "reserved word" for EXTRACT is in the core, rather than in SQL. * Syntax I'm using the word 'semester' since it is common in college and school but I wondering if it should be other word (like 'halfyear', for example) Is this a feature that worth? BTW, I'll put this in the commit fest (2015-09). Thanks! -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
2015-08-14 20:58 GMT-03:00 Dickson S. Guedes : > Hello hackers, > > * Description > > This patch is a proposal Now patch attached, sorry. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br allow_semester_in_extract_data_part_to_char.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
2015-08-14 21:32 GMT-03:00 Gavin Flower :
...
> So semesters don't appear to align with normal half year boundaries.
Interesting links, thanks!
Which sounds better for a native English: 'half', 'halfyear'?
For example:
> SELECT date_trunc('halfyear', current_date);
date_trunc
2015-07-01 00:00:00-03
(1 row)
Thanks!
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
2015-08-14 21:40 GMT-03:00 David G. Johnston : > On Friday, August 14, 2015, Dickson S. Guedes wrote: >> >> >> The term is used in a school or college to represent a half-year. >> Actually it could be evaluated from a date using some math with >> 'quarter' but could not be extracted from date since the API to define >> a "reserved word" for EXTRACT is in the core, rather than in SQL. >> > > If this is wanted a more consistent word would be "half" since we already > accept quarter. In your opinion: "half" or "halfyear" ? > I quite dislike semester because of its connotations in education and the > fact that actual semesters do not align with calendar halves. I agree, my native language is pt_BR, and it is very common to use "semestre" ( "semester" ), but reading some text around the Internet I see "half-year" more often. Thank you. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
2015-08-15 0:55 GMT-03:00 Tom Lane :
> I don't think we should accept a patch along this line, because it assigns
> a very specific meaning to "semester" that does not square all that well
> with real-world usage.
I agree that "semester" was not nice, the real meaning is "half" or
"halfyear" as mentioned in other messages. That's it, I was proposing
the extraction of the first or second half year using a specific word
like in:
select extract('halfyear' from date '2015-08-15')); or
select date_trunc('halfyear', date '2015-08-15');
rather than trying to overloading `date_part` with a UDF or
calculating half like:
select ceil(date_part('quarter', date '2015-08-15') / 2);
BTW, I feel that I have enough feedback to set patch as rejected.
Thank you for your time.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better LWLocks with compare-and-swap (9.4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 13-05-2013 09:50, Heikki Linnakangas escreveu: > I've been working on-and-off on the WAL-insert scaling patch. It's > in pretty good shape now, and I'll post it shortly, but one thing I > noticed is that it benefits a lot from using an atomic > compare-and-swap instruction for the contention-critical part. > > I realized that we could also use compare-and-swap to make LWLocks > scale better. The LWLock struct is too large to compare-and-swap > atomically, but we can still use CAS to increment/decrement the > shared/exclusive counters, when there's no need to manipulate the > wait queue. That would help with workloads where you have a lot of > CPUs, and a lot of backends need to acquire the same lwlock in > shared mode, but there's no real contention (ie. few exclusive > lockers). > > pgbench -S is such a workload. With 9.3beta1, I'm seeing this > profile, when I run "pgbench -S -c64 -j64 -T60 -M prepared" on a > 32-core Linux machine: > > - 64.09% postgres postgres [.] tas - tas - 99.83% > s_lock - 53.22% LWLockAcquire + 99.87% GetSnapshotData - 46.78% > LWLockRelease GetSnapshotData + GetTransactionSnapshot + 2.97% > postgres postgres [.] tas + 1.53% postgres > libc-2.13.so [.] 0x119873 + 1.44% postgres postgres > [.] GetSnapshotData + 1.29% postgres [kernel.kallsyms] [k] > arch_local_irq_enable + 1.18% postgres postgres [.] > AllocSetAlloc ... I'd like to test this here but I couldn't reproduce that perf output here in a 64-core or 24-core machines, could you post the changes to postgresql.conf and the perf arguments that you used? Thanks! []s - -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://github.net/guedes - twitter: @guediz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRltDJAAoJEBa5zL7BI5C7UQkH/Au8p90pTMl1qvbft3q1Gtxp a4PV8fjOrzQou2I+9Sxu5W1ql3qyVmfFare+bJVKg5L3LmvACjZ6bbw9oKBEnPGB vzE9nB6+3F3eyo464Niq19cTVgmyRQBcuOT/Ye88Uh2mrrgUYB+lGfk9M2Af7on1 nUZI5YsWWXt/bm9wf6rRCzDs76fS7ity943V0aSg2AHryjfcB8o4oBhJBnrRfnm7 v+SxLg0xDEWQPo8VOCQlIw5IhoxNokHjMAt8Ho7o0dXJRR91vSerdulK4Uxkz13Q E9GlDBDBzZsHmqHCGECNSglqVegXRA5g2i/o3tmQ/lEKzCF9OiX7GBSkXN+gEsc= =nGJ5 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal 9.4. Explain on signal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 16-05-2013 07:52, Pavel Stehule escreveu: > 2013/5/16 Thom Brown : >> On 16 May 2013 11:09, Pavel Stehule >> wrote: >>> Hello >>> >>> I proposed a some months log plans of cancelled queries >>> http://www.postgresql.org/message-id/cafj8pra-duzkmdtu52ciugb0p7tvri_b8ltjmjfwcnr1lpt...@mail.gmail.com >>> >> >> >>> What a neat idea. So the original plan of EXPLAINing cancelled >> queries... does this cater for that? Can cancelled queries >> automatically invoke the EXPLAIN functionality as part of this >> feature? >> > > I would to get EXPLAIN of long queries without waiting on end. > > So it is possible for manual cancelation (not for timeout) > > SELECT pg_explain_backend(xx); SELECT pg_cancel_backend(xx); BTOH, we could provide a pg_cancel_backend(pid, boolean) so when that boolean is true it will do that job. Particularly I'm not a fan of this kind of boolean flag and appreciate the two function above, so +1. BTW, if somebody wants an explain-and-cancel behavior he could creates a function and call both function pg_(explain|cancel)_backend(..) consecutively. []s - -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://github.net/guedes - twitter: @guediz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRl3thAAoJEBa5zL7BI5C74voIAJ0PhUlnRz/MEyS3ckeQPNEp 6ZT1f4zddkP+oC626+uv9Gb34lokg6Y+5JrMYFcKm3Pq+3mIiKaq2yY08GW3pkBk 7zbvTSKCQdNO7PprhR9EUjyJ5IZrwkG8nNZJm+98ohkv5dZiHqLl0ovGJGg2yeLd kkRTmQOOmPalBado1i8SARaEq6apelpmPETl7fkutXAMhq4MSfsB0x0ZofT9/RDA H18/kssql7BVtm7Rw9uJJe37vnpJJgrsjf8qHzJFZcyhxDjMDHAyzViacfKtd8Mv WPbZcVTQ5jHHmyReIPECAPseQ/m9eV8gM66X2elO4MDyCZ0hB9xaqZCixnx1844= =AL0R -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Road map to study about fetching a set of tuples - novice!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 18-05-2013 11:40, Atri Sharma escreveu: > On 18-May-2013, at 20:01, Soroosh Sardari > wrote: > >> Hi >> >> I was tracing a simple SELECT query to find how pg works for >> fetching tuples. but I'm totally lost in the code. Could you >> help me to understand under the hood? I know about parsing and >> planning parts, my actual problem is executer. If you show me a >> road map to study, I would appreciate it. >> >> > > You can probably try: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/executor/README;h=8afa1e3e4a7596475cbf19a76c88d48a04aeef02;hb=HEAD > There > > is a cool flowchart too: http://www.postgresql.org/developer/backend/ []s - -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://github.net/guedes - twitter: @guediz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRl5wHAAoJEBa5zL7BI5C7C+wH/2dO5t5G4ygLUE2jlHOgpbkZ wcXxED5h5TvQel2N2c1WmmMuxPeTJwjxoUOoO9v4sA+pf2YmOphrv77rQN5DIMW8 iKxZQpe+c7cblgQpZx0gTuswRrbPIhMSAF0zP2SS2GFxPKEWD4Oe3QbkNnkZTD0X xZfSRiSnTe3d7mO9ok41BUndTQdvIz6bV/1v7CMV/YKlM6N0uMMVYORJBGw9kKK4 lxuFek2vpR5Np7DeDIeHoFk8fKJbJFcqBHi5Hs8f3AGoF4u4MMxPMoYK6dZmj7Tr YeHkWP8UEx06OBSm+k3BCRb3A7lnsObtLnykU8r4VUK9X1fwpz1Atx4mGwQucus= =GPkw -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better LWLocks with compare-and-swap (9.4)
Em Dom, 2013-05-19 às 09:29 +0300, Heikki Linnakangas escreveu: > On 18.05.2013 03:52, Dickson S. Guedes wrote: > >> pgbench -S is such a workload. With 9.3beta1, I'm seeing this > >> profile, when I run "pgbench -S -c64 -j64 -T60 -M prepared" on a > >> 32-core Linux machine: > >> > >> - 64.09% postgres postgres [.] tas - tas - 99.83% > >> s_lock - 53.22% LWLockAcquire + 99.87% GetSnapshotData - 46.78% > >> LWLockRelease GetSnapshotData + GetTransactionSnapshot + 2.97% > >> postgres postgres [.] tas + 1.53% postgres > >> libc-2.13.so [.] 0x119873 + 1.44% postgres postgres > >> [.] GetSnapshotData + 1.29% postgres [kernel.kallsyms] [k] > >> arch_local_irq_enable + 1.18% postgres postgres [.] > >> AllocSetAlloc ... > > > > I'd like to test this here but I couldn't reproduce that perf output > > here in a 64-core or 24-core machines, could you post the changes to > > postgresql.conf and the perf arguments that you used? > > Sure, here are the non-default postgresql.conf settings: Thank you for your information. > While pgbench was running, I ran this: > > perf record -p 6050 -g -e cpu-clock > > to connect to one of the backends. (I used cpu-clock, because the > default cpu-cycles event didn't work on the box) Hum, I was supposing that I was doing something wrong but I'm getting the same result as before even using your test case and my results is still different from yours: + 71,27% postgres postgres [.] AtEOXact_Buffers + 7,67% postgres postgres [.] AtEOXact_CatCache + 6,30% postgres postgres [.] AllocSetCheck + 5,34% postgres libc-2.12.so [.] __mcount_internal + 2,14% postgres [kernel.kallsyms][k] activate_page It's a 64-core machine with PGDATA in a SAN. vendor_id : GenuineIntel cpu family : 6 model : 47 model name : Intel(R) Xeon(R) CPU E7- 4830 @ 2.13GHz stepping: 2 cpu MHz : 1064.000 cache size : 24576 KB physical id : 3 siblings: 16 core id : 24 cpu cores : 8 apicid : 241 initial apicid : 241 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt aes lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid bogomips: 4255.87 clflush size: 64 cache_alignment : 64 address sizes : 44 bits physical, 48 bits virtual power management: Would you like that I test some other configuration to try to simulate that expected workload? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Better LWLocks with compare-and-swap (9.4)
Em Seg, 2013-05-20 às 14:35 +0200, Andres Freund escreveu: > On 2013-05-20 09:31:15 -0300, Dickson S. Guedes wrote: > > Hum, I was supposing that I was doing something wrong but I'm getting > > the same result as before even using your test case and my results is > > still different from yours: > > > > > > + 71,27% postgres postgres [.] AtEOXact_Buffers > > + 7,67% postgres postgres [.] AtEOXact_CatCache > > + 6,30% postgres postgres [.] AllocSetCheck > > + 5,34% postgres libc-2.12.so [.] __mcount_internal > > + 2,14% postgres [kernel.kallsyms][k] activate_page > > That looks like you have configured with --enable-cassert and probably > also --enable-profiling? The former will give completely distorted > performance results... Ah! Wrong PATH, so wrong binaries. Thanks Andres. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: This is a digitally signed message part
[HACKERS] Apparently deprecated code in planner.c
Hi all, I'm wondering whether the #ifdef FORCE_PARALLEL_MODE code [1] was deprecated: * * FIXME: It's assumed that code further down will set parallelModeNeeded * to true if a parallel path is actually chosen. Since the core * parallelism code isn't committed yet, this currently never happens. */ #ifdef FORCE_PARALLEL_MODE glob->parallelModeNeeded = glob->parallelModeOK; #else glob->parallelModeNeeded = false; #endif [1] http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/optimizer/plan/planner.c;h=147c4deef3bb708ebb32b6781330f6ed980fc90c;hb=HEAD#l245 []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_ctl idempotent option
2013/1/14 Tom Lane : > Alvaro Herrera writes: >> Tom Lane wrote: >>> Peter Eisentraut writes: >>>> Here is a patch to add an option -I/--idempotent to pg_ctl, the result >>>> of which is that pg_ctl doesn't error on start or stop if the server is >>>> already running or already stopped. > >>> Idempotent is a ten-dollar word. Can we find something that average >>> people wouldn't need to consult a dictionary to understand? > >> --no-error perhaps? > > Meh, that's probably going too far in the direction of imprecision. > The point of this patch is that only very specific errors are > suppressed. > > I don't have a better idea though. It'd be easier if there were > separate switches for the two cases, then you could call them > --ok-if-running and --ok-if-stopped. But that's not very workable, > if only because both would want the same single-letter abbreviation. --ignore-status --ignore-status-start --ignore-status-stop ? Regards -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Parallel query execution
2013/1/16 Bruce Momjian : > Wiki updated: > > https://wiki.postgresql.org/wiki/Parallel_Query_Execution Could we add CTE to that opportunities list? I think that some kind of queries in CTE queries could be easilly parallelized. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages
2013/1/18 Amit kapila : > Please find the rebased Patch for Compute MAX LSN. The function 'remove_parent_refernces' couldn't be called 'remove_parent_references' ? Why not an extension in PGXN instead of a contrib? Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages
2013/1/20 Amit kapila : > On Sunday, January 20, 2013 4:04 AM Dickson S. Guedes wrote: > 2013/1/18 Amit kapila : >>> Please find the rebased Patch for Compute MAX LSN. > >>The function 'remove_parent_refernces' couldn't be called >>'remove_parent_references' ? > > Shall fix this. > >> Why not an extension in PGXN instead of a contrib? > > This functionality has similarity to pg_resetxlog, so we thought of putting > it either in bin or in contrib. > Finally based on suggestions from other community members, we have added to > contrib. Indeed. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Fix NULL checking in check_TSCurrentConfig()
2013/1/20 Xi Wang : > The correct NULL check should use `*newval'; `newval' must be non-null. [... cutting code ...] Please see [1] to know how is our submit patch process. [1] http://wiki.postgresql.org/wiki/Submitting_a_Patch regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch to add \watch to psql
2013/1/17 Daniel Farina : > I realized while making my adjustments that I pointlessly grew some input > checking in the inner loop. I just hoisted it out in this version. Since psql uses libreadline, what do you think about to call rl_clear_screen() inside that "while (true)" loop? Obviously we should test #if we have readline enabled to use it, but when we have it a nice output will bring to us. BTW, I don't know how this will behaves on OSX or Windows. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Event Triggers: adding information
2013/1/21 Robert Haas : > Another thing is that we might want to document that if a command > errors out, ddl_command_end will never be reached; and perhaps also > that if ddl_command_start errors out, the command itself will never be > reached. Perhaps this is so obvious as to not bear mentioning, I > don't know, but the thought crossed my mind that someone might fail to > realize it. I think that should be a mention about that in docs, someone could expect that ddl_command_end be reached even when ddl_command_start erros out, and try to use it in some way. Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Prepared statements fail after schema changes with surprising error
2013/1/21 Peter van Hardenberg : > A user reported an interesting issue today. After restoring a dump created > with --clean on a running application in his development environment his > application started complaining of missing tables despite those tables very > clearly existing. > > After a little thinking, we determined that this was due to the now-default > behaviour of Rails to create prepared statements for most queries. The > prepared statements error out because the old relation they point to is > missing, but this gives a misleading report thus: > > PG::Error: ERROR: relation "xxx" does not exist Isn't that something with search_path? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql: small patch to correct filename formatting error in '\s FILE' output
2013/1/22 Tom Lane : > Why should \s, and \s alone, > need to remind you where you're cd'd to? Why not just get rid of that prefixed cd'd path in \s? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fix JSON examples in docs
Hi, This patch fix the wrong examples in funcs.sgml introduced by the commit: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a570c98d7fa0841f17bbf51d62d02d9e493c7fcc regards -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br fix_json_docs.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch to add \watch to psql
2013/4/3 Will Leinweber : > Here is an updated patch that addresses several of the points brought up so > far, such as the sleep, internationalization banner, and zero wait check, > and it removes the premature input check. > > Unfortunately rl_clear_screen() is not included at all in libedit, causing > compilation to fail, and I was completely unable to find a way to > distinguish libedit from readline on OS X. It tries extraordinarily hard to > pretend that it's readline. Instead falling back to simple control > characters to clear the screen worked very well on both linux and OS X. I don't have access to an OSX box ATM but term_clear_screen(), in libedit, didn't help? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Reassign variable value in XLogReadRecord
Hello,
While walking in the code I see the following code in
src/backend/access/transam/xlogreader.c:177-191
XLogRecord *
XLogReadRecord(XLogReaderState *state, XLogRecPtr RecPtr, char **errormsg)
{
XLogRecord *record;
XLogRecPtr targetPagePtr;
boolrandAccess = false; <=== assign
uint32 len,
total_len;
uint32 targetRecOff;
uint32 pageHeaderSize;
boolgotheader;
int readOff;
randAccess = false; <== reassign
/* reset error state */
Do I am missing something or the last one is unnecessary?
Best regards.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] introduction
2013/4/9 Bert : > So I'll just monitor the mailing list a bit, pick some patches and test > them. I think this is the best way to learn to know the code, and is > probably helpful for everyone? Plus to that you can start reading some information about development process [1]. There you'll see that we have a TODO list [2] that could be a start point to code, but IMHO a better start point is reviewing another's code, you can find some information about that in [3]. Another place is the IRC channel #postgresql on irc.freenode.net where you can find Postgres users and developers chatting. [1] http://wiki.postgresql.org/wiki/Development_information [2] http://wiki.postgresql.org/wiki/Todo [3] http://wiki.postgresql.org/wiki/Reviewing_a_Patch Best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [BUGS] BUG #8049: Incorrect results when using ORDER BY and query planner options
2013/4/9 : > I've got a strange problem with a query that produces more results than > expected. I tested this [1] and saw that 9.1 don't has the behavior then I started bisect from REL9_1_9 to HEAD and found that commit 5b7b5518d0e [2] introduced it. I'm putting a copy to -hacker list in a hope that this help some one with more experience on that code to go further. [1] http://www.postgresql.org/message-id/CAHHcrepFavBPnTSE9Ho3=8fgxh8cir7bykymgmbddfldpwf...@mail.gmail.com [2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5b7b5518d0ea56c422a197875f7efa5deddbb388 []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Viewing new 9.3 error fields
Em Qui, 2013-04-11 às 14:08 -0400, Bruce Momjian escreveu: > This blog entry displays the new 9.3 error fields, schema/table/constraint: > > > http://www.depesz.com/2013/03/07/waiting-for-9-3-provide-database-object-names-as-separate-fields-in-error-messages/ > > $ INSERT INTO t (i) VALUES (1); > psql:z.sql:16: ERROR: 23505: duplicate key value violates unique > constraint "t2_pkey" > DETAIL: Key (i)=(1) already exists. > CONTEXT: SQL statement "INSERT INTO t2 (i) VALUES (NEW.i)" > PL/pgSQL function copy_value() line 4 at SQL statement > --> SCHEMA NAME: public > --> TABLE NAME: t2 > --> CONSTRAINT NAME: t2_pkey > LOCATION: _bt_check_unique, nbtinsert.c:398 > > However, I am unable to see this in psql: > > CREATE TABLE ledger (id SERIAL, balance NUMERIC(10,2) unique); > > SET log_error_verbosity = 'verbose'; > > INSERT INTO ledger VALUES (DEFAULT, 1); > > INSERT INTO ledger VALUES (DEFAULT, 1); > ERROR: duplicate key value violates unique constraint > "ledger_balance_key" > DETAIL: Key (balance)=(1.00) already exists. > --> > > What am I missing? Isn't it on log output? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Analyzing bug 8049
Em Sex, 2013-04-12 às 10:58 -0400, Tom Lane escreveu: > Robert Haas writes: > > On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane wrote: > >> The plan I'm considering is to get this written and committed to HEAD > >> in the next week, so that it can go out in 9.3beta1. After the patch > >> has survived a reasonable amount of beta testing, I'd be more comfortable > >> about back-patching into 9.2. > > > I'm not very sanguine about the chances that back-patching this won't > > provoke any screams of agony ... but I don't have a better idea, > > either. Letting queries return wrong answers isn't a superior > > solution, for sure. > > The only alternative I can see is to make a back-patch that just teaches > get_eclass_for_sort_expr() to compute valid nullable_relids for the sort > expression. In my tests, after ANALYZE _bug_header and _bug_line, the query plan changes and query results returns as expected. Is this a chance that things isn't too bad? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: This is a digitally signed message part
Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS
2012/8/16 Fabrízio de Royes Mello : > The attached patch implement this feature: > > CREATE SCHEMA [ IF NOT EXISTS ] schema_name [ AUTHORIZATION user_name ] [ > schema_element [ ... ] ] > CREATE SCHEMA [ IF NOT EXISTS ] AUTHORIZATION user_name [ schema_element [ > ... ] ] > > Now, PostgreSQL don't trow an error if we use "IF NOT EXISTS" in "CREATE > SCHEMA" statement. I started testing this, but I didn't see regression tests for it. Could you write them?. Best. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS
2012/8/17 Fabrízio de Royes Mello : > > 2012/8/17 Alvaro Herrera >> >> Excerpts from Fabrízio de Royes Mello's message of vie ago 17 09:16:30 >> -0400 2012: >> >> > The attached patch contains regression tests for it. >> >> I think you're missing support in copyfuncs.c and equalfuncs.c for the >> new field in the node. > > You're completely right, thanks... > > The attached patch add support for the new field in the node in > "copyfuncs.c" and "equalfuncs.c". Maybe I'm missing something but shouldn't it being handled in extension.c too? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS
Hello, I reviewed this v5 of patch: - https://commitfest.postgresql.org/action/patch_view?id=907 The patch is small and implements a new syntax to CREATE SCHEMA that allow the creation of a schema be skipped when IF NOT EXISTS is used. It was applied to 483c2c1071c45e275782d33d646c3018f02f9f94 with two hunks offset, was compiled without errors or new warnings and pass all tests, even the tests that covers the expected results for it self. The docs was updated with the information about the expected behavior. I tested against ambiguity, i. e. creating a schema with name 'if' and got the expected results when try to create it if not exists. Two questions: - Should this patch implements others INEs like ADD COLUMN IF NOT EXISTS? - Should pg_dump or pg_restore support some kind of flag to use a CREATE SCHEMA IF NOT EXISTS ... instead CREATE SCHEMA ...? Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype/twitter: guediz ~ github.com/guedes http://guedesoft.net ~ http://www.postgresql.org.br create_schema_if_not_exists_v5.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS
2012/8/28 David E. Wheeler : > On Aug 28, 2012, at 8:19 AM, Fabrízio de Royes Mello wrote: > >>> - Should this patch implements others INEs like ADD COLUMN IF NOT EXISTS? >> >> If this feature is important I believe we must implement it. >> >> Exists several "CREATE" statements without "IF NOT EXISTS" option too, so we >> can discuss more about it and I can implement it in this patch or in another. > > I don't think any of them have to be a part of *this* patch. There can be > patches for each of them. Probably simpler that way. Yes, agreed. Other implementations should be in their own distinct patches. BTW, it could be interesting search the archive for past discussions about CINE. I changed the status of this patch to "Ready for Committer". Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype/twitter: guediz ~ github.com/guedes http://guedesoft.net ~ http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] caracara failing to bind to localhost?
2010/2/27 Tom Lane : > Buildfarm member caracara has been failing the last few days because of > this: > > LOG: could not bind socket for statistics collector: Cannot assign requested > address > LOG: disabling statistics collector for lack of working socket > > That code hasn't changed recently, AFAIK, so I'm thinking something's > broken in the machine's environment. Any ideas? Firewall or that ipv6's issues when ::1 for localhost is enabled in /etc/hosts or that cases when there is an ipv4 address and an ipv6 alias in the same eth0? Was the tcpip_socket variable changed on caracara's host? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: avoid heavyweight locking on hash metapage
2012/5/30 Robert Haas : > I tested the effect of this by setting up a series of 5-minute > read-only pgbench run at scale factor 300 with 8GB of shared buffers > on the IBM POWER7 machine. I know it doesn't matter, but out of curiosity what OS you used? best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SQL standard changed behavior of ON UPDATE SET NULL/SET DEFAULT?
2012/6/16 Tom Lane : > I wrote: >> Have the SQL committee simply failed to notice that in >> whacking this text around they changed the meaning? Which behavior is >> actually implemented by other RDBMSes? > > If anyone is up for actually trying this, here is a script to test the > behavior in question: > > create table pp (f1 int, f2 int, primary key (f1,f2)); > create table cmssn (f1 int, f2 int, > foreign key (f1,f2) references pp(f1,f2) on update set null); > create table cmfsn (f1 int, f2 int, > foreign key (f1,f2) references pp(f1,f2) match full on update set null); > create table cmssd (f1 int default 0, f2 int default 0, > foreign key (f1,f2) references pp(f1,f2) on update set default); > create table cmfsd (f1 int default 0, f2 int default 0, > foreign key (f1,f2) references pp(f1,f2) match full on update set default); > > insert into pp values (11, 22); > insert into pp values (11, 0); > insert into pp values (0, 0); > > insert into cmssn values (11, 22); > insert into cmfsn values (11, 22); > insert into cmssd values (11, 22); > insert into cmfsd values (11, 22); > > update pp set f2 = f2 + 1 where f2 > 0; > > select * from cmssn; > select * from cmfsn; > select * from cmssd; > select * from cmfsd; > > In Postgres this produces > > f1 | f2 > + > 11 | > (1 row) > > f1 | f2 > + > | > (1 row) > > f1 | f2 > + > 11 | 0 > (1 row) > > f1 | f2 > + > 0 | 0 > (1 row) > > which shows that we are self-consistent but not actually compliant with > either old or new wordings of the spec :-( > > The only other SQL DB I have handy is mysql 5.5.24, which shows up > pretty unimpressively: it gives a syntax error on the cmssd definition, > which would be all right because the manual says the innodb storage > engine doesn't support SET DEFAULT, except it *doesn't* give a syntax > error for creating cmfsd. Then, the update fails claiming that cmfsn's > FK constraint is violated, so they evidently don't implement that case > correctly. After removing cmfsn, the update fails again claiming that > cmfsd's FK constraint is violated, so yeah they are telling the truth > when they say SET DEFAULT doesn't work. The upshot is that only the > MATCH SIMPLE SET NULL case works at all in current mysql, and that > produces the result > > mysql> select * from cmssn; > +--+--+ > | f1 | f2 | > +--+--+ > | NULL | NULL | > +--+--+ > 1 row in set (0.00 sec) > > so they are nulling all the referencing columns in this case, which > matches the more recent specs but is clearly contrary to SQL92. > > Anybody have DB2, or something else that might be thought to be pretty > close to spec-compliant? I tryed in a MS SQL Server 2012 via SQLFiddle [1]. I could only create 'cmssn' and 'cmssd' tables because as I can see in [2] MS SQL Server 2012 doesn't supports MATCH syntax. The result was: select * from cmssn; F1 | F2 (null) | (null) select * from cmssd; F1 |F2 0 | 0 The test is in [3], and there you can try other RDBMS, just create the schema on the left panel and testing selects on the right. [1] http://sqlfiddle.com [2] http://msdn.microsoft.com/en-us/library/ms174979.aspx [3] http://sqlfiddle.com/#!6/ac7db/1 Regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Broken system timekeeping breaks the stats collector
2012/6/16 Tom Lane : [... cut ...] > (1) In backend_read_statsfile, make an initial attempt to read the stats > file and then read GetCurrentTimestamp after that. If the local clock > reading is less than the stats file's timestamp, we know that some sort > of clock skew or glitch has happened, so force an inquiry message to be > sent with the local timestamp. But then accept the stats file anyway, > since the skew might be small and harmless. The reason for the forced > inquiry message is to cause (2) to happen at the collector. > > (2) In pgstat_recv_inquiry, if the received inquiry_time is older than > last_statwrite, we should suspect a clock glitch (though it might just > indicate delayed message receipt). In this case, do a fresh > GetCurrentTimestamp call, and if the reading is less than > last_statwrite, we know that the collector's time went backwards. > To recover, reset these variables as we do at startup: > last_statrequest = GetCurrentTimestamp(); > last_statwrite = last_statrequest - 1; > to force an immediate write to happen with the "new" local time. > > (1) is basically free in terms of the amount of work done in non-broken > cases, though it will require a few more lines of code. (2) means > adding some GetCurrentTimestamp calls that did not occur before, but > hopefully these will be infrequent, since in the absence of clock > glitches they would only happen when a backend's demand for a new stats > file is generated before the collector starts to write a new stats file > but not received till afterwards. > > Comments? Anyone see a flaw in this design? Or want to argue that > we shouldn't do anything about such cases? What happens when Daylight saving time ends? Or it doesn't matter in this scenario? regards -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgsql_fdw in contrib
2012/6/18 Merlin Moncure : > I can't help but wonder (having been down the contrib/core/extension > road myself) if it isn't better to improve the facilities to register > and search for qualified extensions (like Perl CPAN) so that people > looking for code to improve their backends can find it. That way, > you're free to release/do xyz/abandon your project as you see fit > without having to go through -hackers. This should also remove a lot > of the stigma with not being in core since if stock postgres > installations can access the necessary modules via CREATE EXTENSION, I > think it will make it easier for projects like this to get used with > the additional benefit of decentralizing project management. What about PGXN? BTW, I'm with Robert about "we want to have at least one FDW in core that actually talks to some other database server, rather than just to a file, and it seems like pgsql_fdw is the obvious choice". We have dblink as contrib, why not pgsql_fdw too? Other FDWs could be available at PGXN, pgFoundry, Github, etc. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Release versioning inconsistency
2012/6/20 Magnus Hagander : > On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote: >> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander >> wrote: >>> (I do believe that using the v9.2.0beta marker is >>> *better*, because then it sorts properly. But likely not enough much >>> better to be inconsistent with previous versions) >> >> Good point. Maybe that's a reason to change the versioning scheme and >> stick with "9.2.0betaX" everywhere. Including calling the final >> release "9.2.0" instead of simply "9.2"? > > That might actually be a good idea. We can't really change the way we > named the betas, but it's not too late to consider naming the actual > release as 9.2.0... May be a symlink could be created just do fit the same pattern that other versions do and keeps the actual links (for beta) working. I'm using the same pattern in `pgvm` [1] and it is failing to fetch beta versions :( [1] https://github.com/guedes/pgvm/blob/master/include/sites regards -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Release versioning inconsistency
2012/6/21 Magnus Hagander : > On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes > wrote: >> 2012/6/20 Magnus Hagander : >>> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote: >>>> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander >>>> wrote: >>>>> (I do believe that using the v9.2.0beta marker is >>>>> *better*, because then it sorts properly. But likely not enough much >>>>> better to be inconsistent with previous versions) >>>> >>>> Good point. Maybe that's a reason to change the versioning scheme and >>>> stick with "9.2.0betaX" everywhere. Including calling the final >>>> release "9.2.0" instead of simply "9.2"? >>> >>> That might actually be a good idea. We can't really change the way we >>> named the betas, but it's not too late to consider naming the actual >>> release as 9.2.0... >> >> >> May be a symlink could be created just do fit the same pattern that other >> versions do and keeps the actual links (for beta) working. > > That we can do - in fact, done. It works fine here, thanks! []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COMMUTATOR doesn't seem to work
2012/6/23 D'Arcy Cain : > On 12-06-23 12:17 AM, Tom Lane wrote: >> >> "D'Arcy Cain" writes: >>> >>> On 12-06-22 07:09 PM, Robert Haas wrote: >>>> >>>> I think DirectionFunctionCall2 is what you want. >> >> >>> Can you elaborate? I could not find a single hit in Google or the >>> documentation search on the PG site and it does not appear anywhere >>> in the source distribution. >> >> >> He meant DirectFunctionCall2 > > > Still nothing in the documentation. At least the search box doesn't > find it. Try in the search box of postgres doxygen documentation [1].. [1] http://doxygen.postgresql.org/ []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL 9.1 beta1 disponível para testes.
Olá povo, tudo bem? Que tal ajudarmos a testar esta versão candidata? Visite [1] e [2] para mais informações [1] http://www.postgresql.org/developer/beta [2] http://wiki.postgresql.org/wiki/HowToBetaTest -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: PostgreSQL 9.1 beta1 disponível para testes.
Sorry, wrong list.. apologizes. Em 2 de maio de 2011 13:56, Dickson S. Guedes escreveu: > Olá povo, tudo bem? > > Que tal ajudarmos a testar esta versão candidata? > > Visite [1] e [2] para mais informações > > [1] http://www.postgresql.org/developer/beta > [2] http://wiki.postgresql.org/wiki/HowToBetaTest -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A small step towards more organized beta testing
2011/5/2 Josh Berkus : > Hackers, > > I've replaced test-report-by-email with a GoogleDocs application for Beta1. > > The form for submitting test reports is here: > > https://spreadsheets.google.com/viewform?hl=en&formkey=dEh3WEwzOFhKWWw4dHdRS2VQTExRdVE6MQ&ifq [... cut ...] It's very good Josh. For filter purpose, could have the form a 32bits/64bits choice? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch for new feature: Buffer Cache Hibernation
2011/5/4 Greg Stark : > On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI > wrote: >> Postgres usually starts with ZERO buffer cache. By saving the buffer >> cache data structure into hibernation files just before shutdown, and >> loading them at startup, postgres can start operations with the saved >> buffer cache as the same condition as just before the last shutdown. > > Offhand this seems pretty handy for benchmarks where it would help get > reproducible results. It could have an option to force it or not at start of postgres. This could helps on benchmarks scenarios. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Don't use "cp -i" in the example WAL archive_command.
2011/6/18 Thom Brown : [.. cut ..] > And on a Mac (so through Darwin 10.7.0 a BSD version too): > > toucan:tmp thom$ touch x y > toucan:tmp thom$ cp -i x y; echo $? > overwrite y? (y/n [n]) n > not overwritten > 1 On AIX 5.3 bash-3.00$ touch x y bash-3.00$ cp -i x y; echo $? overwrite y? n 0 -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to use CreateFunctionStmt's RETURN TABLE?
2011/7/26 _石头 :
[... cut ...]
> I do not know how to use the second syntax:RETURNS TABLE '('
> table_func_column_list ')' createfunc_opt_list opt_definition.
> May someone help me to write a simple example of this syntax!
> Thank you very much. Looking forward for your help!
(I'm supposing that you are talking about the syntax of 'CREATE
FUNCTION' itself and not about the bison entry in that file.)
See the docs [1] and this post [2]. They could help you.
[1] http://www.postgresql.org/docs/current/static/sql-createfunction.html
[2] http://www.postgresonline.com/journal/archives/201-returns-table.html
Best regards,
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feature proposal: www_fdw
2011/9/28 Florian Pflug : > On Sep28, 2011, at 15:32 , Alexander Soudakov wrote: >> Here you can find www_fdw feature documentation: >> http://wiki.postgresql.org/wiki/WWW_FDW > > Certainly looks useful (as a third-party extension, as others have already > pointed out) +1. > What I didn't quite understand is how one would pass (dynamic) parameters for > a GET request. For example, not too long ago I needed to access the Google > Maps API from postgres. I ended up using pl/python, and now wonder if your > FDW would support that use-case. I'm working on a google_contacts_fdw to google contacts api [1] but stopped in the authentication design. As you can see in [2], for google api, you should get an authorization token and store the "Auth" value to use latter on the same "session". I'm wondering how the best way to "cache" this value as long as possible, because actually, when you need authentication for a FDW, you use the fdw_routine->BeginForeignScan call function but, in this situation, each SELECT to foreign table will do the handshake and some APIs could block this. Many client libraries work fine, caching the Auth value. How WWW_FDW could play with behaviors like that, since other Web APIs has the a authorization system like this [2]? [1] http://code.google.com/apis/contacts/docs/3.0/developers_guide.html [2] http://code.google.com/apis/gdata/articles/using_cURL.html Regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feature proposal: www_fdw
2011/9/29 Florian Pflug : > You could use a hash table, allocated in the top-level memory context, > to store one authentication token per combination of server and local user. In fact I started something in this way, with ldap_fdw, stashing the connection away using memory context and something using es_query_cxt from EState, just testing until now. How do this from PlanForeignScan I couldn't figure out yet. > I suggest you look at the MySQL FDW (https://github.com/dpage/mysql_fdw) > - they presumably re-use the same connection over multiple foreign scans, > which seems to be a problem similar to yours. >From what I understand they re-use between BeginForeignScan and the subsequent IterateForeignScans and freeing at end. In my tests, there is a (re)connection for each SELECT * FROM ... I'm wondering that would be nice to have some built-in facilities (like this kind of "cache" between calls) provided by www_fdw, for that WWW API based FDWs. Regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separating bgwriter and checkpointer
2011/10/2 Simon Riggs : > On Thu, Sep 15, 2011 at 11:53 PM, Simon Riggs wrote: > >> Current patch has a bug at shutdown I've not located yet, but seems >> likely is a simple error. That is mainly because for personal reasons >> I've not been able to work on the patch recently. I expect to be able >> to fix that later in the CF. > > Full patch, with bug fixed. (v2) > > I'm now free to take review comments and make changes. Hi Simon, I'm trying your patch, it was applied cleanly to master and compiled ok. But since I started postgres I'm seeing a 99% of CPU usage: guedes@betelgeuse:/srv/postgres/bgwriter_split$ ps -ef | grep postgres guedes 14878 1 0 19:37 pts/000:00:00 /srv/postgres/bgwriter_split/bin/postgres -D data guedes 14880 14878 0 19:37 ?00:00:00 postgres: writer process guedes 14881 14878 99 19:37 ?00:03:07 postgres: checkpointer process guedes 14882 14878 0 19:37 ?00:00:00 postgres: wal writer process guedes 14883 14878 0 19:37 ?00:00:00 postgres: autovacuum launcher process guedes 14884 14878 0 19:37 ? 00:00:00 postgres: stats collector process Best regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separating bgwriter and checkpointer
2011/10/3 Simon Riggs : > On Sun, Oct 2, 2011 at 11:45 PM, Dickson S. Guedes > wrote: >> I'm trying your patch, it was applied cleanly to master and compiled >> ok. But since I started postgres I'm seeing a 99% of CPU usage: > > Oh, thanks. I see what happened. I was toying with the idea of going > straight to a WaitLatch implementation for the loop but decided to > leave it out for a later patch, and then skipped the sleep as well. > > New version attached. Working now but even passing all tests for make check, the regress_database's postmaster doesn't shutdown properly. $ make check ... ... == creating temporary installation== == initializing database system == == starting postmaster== running on port 57432 with PID 20094 == creating database "regression" == ... == shutting down postmaster == pg_ctl: server does not shut down pg_regress: could not stop postmaster: exit code was 256 $ uname -a Linux betelgeuse 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC 2011 i686 i686 i386 GNU/Linux $ grep "$ ./configure" config.log $ ./configure --enable-debug --enable-cassert --prefix=/srv/postgres/bgwriter_split Best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separating bgwriter and checkpointer
s, average=1.561 s LOG: database system is shut down Then I started the server again and it ran properly. Well, all the tests was running with the default postgresql.conf in my laptop but I'll setup a more "real world" environment to test for performance regression. Until now I couldn't notice any significant difference in TPS before and after patch in a small environment. I'll post something soon. Best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Fix little typo in docs in func.sgml
Hello all, This is a little patch to fix a typo in docs. In the length function should be a space between "string" and "bytea". Best regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index bedd8ba..45b9956 *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 1587,1593 !length(stringbytea, encoding name ) int --- 1587,1593 !length(string bytea, encoding name ) int -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separating bgwriter and checkpointer
2011/10/18 Simon Riggs : > On Wed, Oct 5, 2011 at 8:02 AM, Simon Riggs wrote: >> On Wed, Oct 5, 2011 at 5:10 AM, Dickson S. Guedes >> wrote: >> >>> Ah ok! I started reviewing the v4 patch version, this is my comments: >> >> ... >> >>> Well, all the tests was running with the default postgresql.conf in my >>> laptop but I'll setup a more "real world" environment to test for >>> performance regression. Until now I couldn't notice any significant >>> difference in TPS before and after patch in a small environment. I'll >>> post something soon. >> >> Great testing, thanks. Likely will have no effect in non-I/O swamped >> environment, but no regression expected either. > > > Any reason or objection to committing this patch? I didn't see any performance regression (as expected) in the environments that I tested. About the code, I prefer someone with more experience to review it. Thanks. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separating bgwriter and checkpointer
2011/10/19 Fujii Masao : > On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs wrote: >> Any reason or objection to committing this patch? > > The checkpointer doesn't call pgstat_send_bgwriter(), but it should. > Otherwise, some entries in pg_stat_bgwriter will never be updated. Yes, checkpoints_req, checkpoints_timed and buffer_checkpoint are not being updated with this patch. > If we adopt the patch, checkpoint is performed by checkpointer. So > it looks odd that information related to checkpoint exist in > pg_stat_bgwriter. We should move them to new catalog even if > it breaks the compatibility? Splitting pg_stat_bgwriter into pg_stat_bgwriter and pg_stat_checkpointer will break something internal? With this modification we'll see applications like monitoring tools breaking, but they could use a view to put data back together in a compatible way, IMHO. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autovacuum workers warning
2011/10/26 Euler Taveira de Oliveira : > I'm not saying that is not the right direction, I'm arguing that a hint is > better than nothing. Right now the only way to know if it is out of workers > is to query pg_stat_activity frequently. The currently number of autovaccum workers could be in the errmsg only instead errhint, then errhint could be omited from patch if there isn't a good hint to report. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/5 Josh Kupershmidt : > I'd like to propose a "concise mode" for psql, which users might turn > on via a \pset option. Concise mode would affect only the output of > psql's backslash commands. For output results which have some all-NULL > columns, as in: > > test=# \d+ foo > Table "public.foo" > Column | Type | Modifiers | Storage | Stats target | Description > +-+---+-+--+- > a | integer | | plain | | > b | integer | | plain | | > Has OIDs: no > > Concise mode would simply omit the all-NULL columns, so that the > output would look like this: > > test=# \d+ foo > Table "public.foo" > Column | Type | Storage > +-+- > a | integer | plain > b | integer | plain > Has OIDs: no Using your example, what if column 'b' has a comment and 'a' not? How the above output will be displayed? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/8 Alvaro Herrera : > What I've imagined for a long time is psql being able to display each > row in more than one line; for example something like > > \df > > Listado de funciones > Esquema | Nombre | Tipo de dato de salida | Tipo > Tipos de datos de argumentos > -+---++-- > public | bt_metap | record | normal > relname text, OUT magic integer, OUT version integer, OUT root integer, OUT > level integer, OUT fastroot integer, OUT fastlevel integer > -+---++-- > public | bt_page_items | SETOF record | normal > relname text, blkno integer, OUT itemoffset smallint, OUT ctid tid, OUT > itemlen smallint, OUT nulls boolean, OUT vars boolean, OUT data text > -+---++-- Isn't that what pagers like 'less' and 'more' do already? May be we could provide a pager more specific to psql output as a contrib or extension. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/8 Alvaro Herrera : > Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011: >> Isn't that what pagers like 'less' and 'more' do already? May be we >> could provide a pager more specific to psql output as a contrib or >> extension. > > Well, now that you mention it, all pagers I know are line-based. If you > want to figure out how to make a pager that's record-based instead, be > my guest. It sounds very useful for this sort of use case. Yes, it could be a good homework for me to do later, then I'll wait for more opinions about the original Josh's proposal to avoid duplicate work. > Nice to see you in PGBR by the way. Nice to see you too! :) Best regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
2011/11/10 Jan Kundrát :
> On 11/10/11 03:47, Robert Haas wrote:
>> It does this already, without this patch. This patch is about CHECK
>> constraints, not UNIQUE ones.
>
> That's right. This is how to check what the patch changes:
>
> jkt=> CREATE TABLE tbl (name TEXT PRIMARY KEY, a INTEGER CHECK (a>0));
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "tbl_pkey" for table "tbl"
> CREATE TABLE
> jkt=> INSERT INTO tbl (name, a) VALUES ('x', 10);
> INSERT 0 1
> jkt=> UPDATE tbl SET a = -a;
> ERROR: new row for relation "tbl" violates check constraint "tbl_a_check"
> DETAIL: New row with data (x, -10) violates check constraint "tbl_a_check".
>
> The last line, the detailed error message, is added by the patch.
The patch uses 'New row with data ' but it was an UPDATE, if you
go further with this patch, IMO the message should be fixed too.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-11-2011 21:42, Josh Kupershmidt wrote:
> On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
>> Have you tried \d+ with this psql mode:
>>
>>\pset format wrapped
>>
>> It wraps the data so it fits on the screen --- it is my default in my
>> .psqlrc.
>
> I think that's one of the many psql features I haven't experimented
> with, thanks for the suggestion. It looks OK for some things, but I
> find the column-wrapping behavior can be rather illegible, e.g.
>
> create table test (
> some_column_name serial PRIMARY KEY,
> another_column_name integer NOT NULL,
> another_col integer, username text
> );
>
> tmp=# \d+ test
> Table "public.test"
> Column | Type | Modifiers | Storage | Stats target |
> Description
> +-+--+-+--+-
> some_column_na.| integer | not null def.| plain | |
> .me | |.ault nextval.| | |
> | |.('test_some_.| | |
> | |.column_name_.| | |
> | |.seq'::regcla.| | |
> | |.ss) | | |
> another_column.| integer | not null | plain | |
> ._name | | | | |
> another_col| integer | | plain | |
> username | text| | extende.| |
> | | |.d | |
>
>
>
> That wrapping is pretty ugly, and the culprit is all the wasted
> horizontal space for "Stats Target" and "Description" in this case
> (and probably for many users, who never set either column modifier).
> That output might be much nicer if, instead of "Modifiers", "Column",
> and "Storage" getting squeezed, the empty "Stats Target" and
> "Description" column headers got squeezed instead, giving the
> populated columns more horizontal space.
I'm not convinced yet, because a single comment in only one column is
enough to show the "Description"'s column again.
IMHO it seems to me that the only gain of this new proposed behaviour
only happens when there is no especial information about the columns,
like comments or stat target, and I don't know if this is a common
situation.
[]s
- --
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://github.net/guedes - twitter: @guediz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOvGpeAAoJEBa5zL7BI5C7V6cH/3chliawlBO0Sf0HB2DSmHeK
AyfA+LPiKRa9Egnlt7jHIAqdiplVkfUkaP8P2L2OryexStb8eXtAWeRJjHdR11di
X15M6551vHf7fqwmCpHtNebACXDdrQefHuw9MFtPYe4jaJwy1kU7IyLQcpRjNA0s
mvPJKrH08WqdFIw0DgiZi1+EFZE2Swr/zAKbNU2snGhKA0w2juHpoBOHmlfxmXQq
Z2zWvins8nqG1lpAhhD1QZzImGpWf/W7hiXDoP2BGo9wYjU38obbVdZJHNAey75B
9C4f75vQH4MRGy/wWYEPxttLoBerQaVedfEFPyHIOoqUOpIMJeLLqbk6mY5AIDM=
=5Oez
-END PGP SIGNATURE-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Common Table Expressions applied; some issues remain
Hi all,
While i'm testing the HEAD version of CVS with this new feature, i
found a possible bug and like that more persons could try it in you
own box.
The attached file is a log of my test and I'm using a unprivileged
user to do it.
Thanks.
--
[]s
Dickson S. Guedes
-
Projeto Colmeia - Florianopolis, SC
(48) 3322-1185 ramal: 27
http://makeall.wordpress.com/
http://pgcon.postgresql.org.br/
http://planeta.postgresql.org.br/
[EMAIL PROTECTED]:/srv/postgresql/HEAD/bin$ /srv/postgresql/HEAD/bin/psql
psql (8.4devel)
Type "help" for help.
postgres=# SELECT version();
version
---
PostgreSQL 8.4devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.3
(Ubuntu 4.2.3-2ubuntu7)
(1 row)
postgres=# CREATE USER blog;
CREATE ROLE
postgres=# CREATE DATABASE blo
postgres=# CREATE DATABASE blog OWNER
postgres=# CREATE DATABASE blog OWNER blog;
CREATE DATABASE
postgres=# \c blog blog
psql (8.4devel)
You are now connected to database "blog" as user "blog".
blog=> CREATE SCHEMA hr;
CREATE SCHEMA
blog=> CREATE TABLE hr.person(
blog(> nro_doc numeric(10) primary key,
blog(> name varchar(50) not null,
blog(> nro_doc_parent numeric(10) references hr.person(nro_doc)
blog(> );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "person_pkey"
for table "person"
CREATE TABLE
blog=> SET search_path TO public,hr;
SET
blog=> \dt
List of relations
Schema | Name | Type | Owner
++---+---
hr | person | table | blog
(1 row)
blog=> \d person
Table "hr.person"
Column | Type | Modifiers
+---+---
nro_doc| numeric(10,0) | not null
name | character varying(50) | not null
nro_doc_parent | numeric(10,0) |
Indexes:
"person_pkey" PRIMARY KEY, btree (nro_doc)
Foreign-key constraints:
"person_nro_doc_parent_fkey" FOREIGN KEY (nro_doc_parent) REFERENCES
person(nro_doc)
Referenced by:
"person_nro_doc_parent_fkey" IN person FOREIGN KEY (nro_doc_parent)
REFERENCES person(nro_doc)
blog=> INSERT INTO hr.person VALUES
blog-> (1234567890,'JOAO DA SILVA',NULL),
blog-> (0987654321,'MARCO ANTONIO DE SOUZA',NULL),
blog-> (0192837465,'MARIA ANTONIETA DA SILVA',1234567890),
blog-> (0987612345,'LUIZ ANTONIO MARCOS',1234567890),
blog-> (0912219083,'ALTAZIGIO FERREIRA MARCOS',0987612345);
INSERT 0 5
blog=> WITH RECURSIVE parents(son_name,son_doc,parent_name,parent_doc) AS
blog-> (
blog(> SELECT name, nro_doc, '' as parent_name, 0 as parent_doc FROM
hr.person WHERE nro_doc_parent is null
blog(> UNION ALL
blog(> SELECT a.name as son_name,
blog(> a.nro_doc as son_doc,
blog(> b.parent_name,
blog(> b.parent_doc
blog(> FROMhr.person a INNER JOIN parents b ON a.nro_doc_parent =
b.parent_doc
blog(> )
blog-> SELECT * from filiacao order by 1,2;
TRAP: FailedAssertion("!(Node*)(cte->ctequery))->type) == T_Query))", File:
"parse_target.c", Line: 307)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: LOG: server process
(PID 7055) was terminated by signal 6: Aborted
LOG: terminating any other active server processes
FATAL: the database system is in recovery mode
Failed.
!> LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2008-10-05 17:28:57 BRT
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/498380
LOG: redo is not required
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
!> \q
[EMAIL PROTECTED]:/srv/postgresql/HEAD/bin$ /srv/postgresql/HEAD/bin/psql -U
blog
psql (8.4devel)
Type "help" for help.
blog=> WITH RECURSIVE parents(son_name,son_doc,parent_name,parent_doc) AS
(
SELECT name, nro_doc, '' as parent_name, 0 as parent_doc FROM hr.person
WHERE nro_doc_parent is null
UNION ALL
SELECT a.name as son_name,
a.nro_doc as son_doc,
b.parent_name,
b.parent_doc
FROMhr.person a INNER JOIN parents b ON a.nro_doc_parent =
b.parent_doc
)
SELECT * from filiacao order by 1,2;
TRAP: FailedAssertion("!(Node*)(cte->ctequery))->type) == T_Query))", File:
Re: [HACKERS] WITH RECURSIVE ... simplified syntax?
Josh Berkus escreveu:
All,
I was discussing WITH RECURSIVE the other day, and realized that one thing
which we're not getting with this patch is a simplest-case simple syntax
which 75% of users are looking for. You know, the ones with simple
proximity trees who just want to find all children of one parent.
Would it be a worth it for us to implement a non-standard simple syntax
sugar on top of WITH RECURSIVE? Or, at least, something like
CONNECT_BY()
Yes Josh,
I was discussing WITH RECURSIVE with some students that I'm teaching and
they ask me exactly this:
"Why not use a syntax like...
SELECT level, lpad(' ', level*4) || last_name as last_name
FROM employee
START WITH employee_id = 10
CONNECT BY PRIOR employee_id = manager_id;
... that is rewrite (or aliased) in:
WITH RECURSIVE employee_rec(level, employee_id, last_name) AS
(SELECT 1, employee_id, last_name)
FROM employee
WHERE employee_id = 10
UNION ALL
SELECT employee_rec.level + 1, emp.employee_id, emp.last_name
FROM employee as emp, employee_rec
WHERE employee_rec.employee_id = emp.manager_id)
SELECT level, lpad(' ', level*4) || last_name FROM employee_rec;" ?
In my opnion, it will be more simple to understand too.
--
[]s
Dickson S. Guedes
Administrador de Banco de Dados
Projeto Colmeia - Florianópolis, SC
(48) 3322-1185, ramal: 26
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Simple postgresql.conf wizard
Hannu Krosing escreveu: On Sat, 2008-11-01 at 22:02 -0400, Greg Smith wrote: Possible feedback topics: -Setting the next round of values requires asking the user for some input before making recommendations. Is it worth building a curses-based interface to updating the values? That would be really helpful for people with only ssh access to their server, but barring something like WCurses I'm not sure it would help on Windows. -How about a GUI one with Python's Tkinter interface? Now Windows isn't a problem, but people using ssh aren't going to be as happy. You could have it in two parts - an agent running on the server, started over ssh and GUI interface running on users workstation which talk to said agent. And I'd suggest you use wxPython for GUI part if you want a relatively modern look. Or the GUI could be a part of pgAdmin. -- []s Dickson S. Guedes Administrador de Banco de Dados Projeto Colmeia - Florianópolis, SC (48) 3322-1185, ramal: 26 http://planeta.postgresql.org.br http://makeall.wordpress.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments to Synchronous replication patch v3
Fujii Masao escreveu: (...) Even if we need to have the database in real, I'd like to use another name for it. The name 'walsender' seems to be an internal module name but it should be a feature name (ex. 'replication'). Agreed. The name 'replication' is more suitable, I also think. Any other ideas? 'walsender' should be a schema in the 'replication' database. Other modules, in replication feature, could be placed there too. []s -- Dickson S. Guedes Administrador de Banco de Dados Confesol - Projeto Colmeia Florianopolis, SC, Brasil (48) 3322-1185, ramal: 26 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO item: Have psql show current values for a sequence
Hi all, These patch implements the TODO item: Have psql show current values for a sequence. Comments are welcome. * Credits The original patch were developed by Euler Taveira de Oliveira <[EMAIL PROTECTED]> but how he is a little busy, he sends it to me and I made some changes to satisfy the TODO item above. * Discussions http://archives.postgresql.org/pgsql-hackers/2007-12/msg00102.php http://archives.postgresql.org/pgsql-hackers/2007-12/msg00605.php * Outputs # \d foo_bar_seq Sequence "public.foo_bar_seq" +---+-+-+ |Column | Type |Value| +---+-+-+ | sequence_name | name| foo_bar_seq | | last_value| bigint | 11 | | start_value | bigint | 1 | | increment_by | bigint | 1 | | max_value | bigint | 9223372036854775807 | | min_value | bigint | 1 | | cache_value | bigint | 1 | | log_cnt | bigint | 31 | | is_cycled | boolean | f | | is_called | boolean | t | +---+-+-+ # \d+ foo_bar_seq Sequence "public.foo_bar_seq" +---+-+-+-+ |Column | Type |Value| Description | +---+-+-+-+ | sequence_name | name| foo_bar_seq | | | last_value| bigint | 11 | | | start_value | bigint | 1 | | | increment_by | bigint | 1 | | | max_value | bigint | 9223372036854775807 | | | min_value | bigint | 1 | | | cache_value | bigint | 1 | | | log_cnt | bigint | 31 | | | is_cycled | boolean | f | | | is_called | boolean | t | | +---+-+-+-----+ -- []s Dickson S. Guedes -- Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ psql-show-current-values-for-sequence-v2.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] TODO item: Have psql show current values for a sequence
On Sat, May 24, 2008 at 2:25 AM, daveg <[EMAIL PROTECTED]> wrote: > On Sat, May 24, 2008 at 12:27:16AM -0300, Dickson S. Guedes wrote: >> Hi all, >> >> These patch implements the TODO item: Have psql show current values >> for a sequence. >> Comments are welcome. >> >> Sequence "public.foo_bar_seq" >> +---+-+-+ >> |Column | Type |Value| >> +---+-+-+ >> | sequence_name | name| foo_bar_seq | >> | last_value| bigint | 11 | >> | start_value | bigint | 1 | >> | increment_by | bigint | 1 | >> | max_value | bigint | 9223372036854775807 | >> | min_value | bigint | 1 | >> | cache_value | bigint | 1 | >> | log_cnt | bigint | 31 | >> | is_cycled | boolean | f | >> | is_called | boolean | t | >> +---+-+-+ > > Is it now the style to draw a complete box around /d* displays? Or can we > dispense with the top and bottom rows of dashes? Hi Dave, This box around the display is because I'm using \pset border 2. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Hi all, There is a TODO Item to allow pg_hba.conf to specify host names along with IP addresses. I'd like to work on this feature, if nobody is working too and no objection exists. Thanks. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Fri, Jun 13, 2008 at 4:30 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> The reason it wasn't done years ago was that there was disagreement on >> the way it should work. And the TODO actually lists several alternatives: > > IIRC, the major reason there was disagreement was the prospect of > unacceptable performance from any of the easy or obvious > implementations. As Andrew S notes, you can't just do the lookups > once at postmaster start; but resolving a pile of hostnames during > each connection is pretty unpleasant, especially if the DNS server > isn't local. (And then there are the effective-DOS implications if > the DNS server is down altogether.) Yes, if DNS server is down during a init connection, or server startup, we can have problems. > The attraction of the reverse-lookup approach is that you do only > one lookup, on the actual connection IP, rather than having to > resolve every hostname in the file to see if it matches. SSH uses an approach like that. > However that way had disadvantages of its own, which I don't recall at the > moment. I think at least some of the issues had to do with security, > ie how much can you trust an answer from a remote DNS server. > Check the archives before you start implementing ... I'm seeing alternatives and studing the code and the email replies, but not start coding yet. Thanks Tom. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Thanks for all yours suggestions, use cases and opinion about this thread, I saw that there are more things to consider than I was thinking and this make me consider that it is a hard work to do for now. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO item: Have psql show current values for a sequence
On Sat, May 24, 2008 at 12:27 AM, Dickson S. Guedes <[EMAIL PROTECTED]> wrote: > Hi all, > > These patch implements the TODO item: Have psql show current values > for a sequence. Hi all, There are some comments or suggestions about this patch? Thanks all. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Thu, Jun 26, 2008 at 6:04 PM, Josh Berkus <[EMAIL PROTECTED]> wrote: > On Wednesday 25 June 2008 17:52, Dickson S. Guedes wrote: >> Thanks for all yours suggestions, use cases and opinion about this >> thread, I saw that there are more things to consider than I was >> thinking and this make me consider that it is a hard work to do for >> now. > > Huh? You should get started on it ... it will just take longer than you > thought. Hi Josh, Yes it will take longer, in realy now I'm studyng how other softwares (like SSH, Apache ...) do that to plan a way to implement it in the backend, less impactant as possible. I'll send to list the implementation plan for suggestions. Thanks. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 64 bit PostgreSQL 8.3.6 build on AIX 5300 with GCC 4.2.0 - fail on pg_regress
Hi all, I'm compiling PostgreSQL 8.3.6 on AIX 5.3.0.0 with GCC 4.2.0 and it is working. But, after message "All of PostgreSQL successfully made. Ready to install.", when it starts regression test, some unexpected (?) occurs. First I doing only a *make* and it is doing *make install* instead just "make" Second, there is a "pg_regress" execution that fails trying to connect in a pg instance that is not in there, is should (must?) be there? The steps I'm following, with some cuts, is: --- postg...@db01 $ uid=204(postgres) gid=1(staff) postg...@db01 $ export CC="gcc" postg...@db01 $ export CFLAGS="-maix64" postg...@db01 $ export LDFLAGS="-maix64 -Wl,-bbigtoc" postg...@db01 $ export OBJECT_MODE=64 postg...@db01 $ export AR="ar -X64" postg...@db01 $ ./configure --enable-integer-datetimes --prefix=/srv/postgresql/8.3.6 postg...@db01 $ make ... ... gmake[1]: Leaving directory `/srv/postgresql/work/postgresql-8.3.6/config' All of PostgreSQL successfully made. Ready to install. ... ... gmake[3]: Leaving directory `/srv/postgresql/work/postgresql-8.3.6/contrib/spi' rm -rf ./testtablespace mkdir ./testtablespace ./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --srcdir=/srv/postgresql/work/postgresql-8.3.6/src/test/regress --temp-port=55432 --schedule=./parallel_schedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == == starting postmaster== running on port 55432 with pid 348354 == creating database "regression" == CREATE DATABASE ALTER DATABASE == installing plpgsql == CREATE LANGUAGE == running regression test queries== ... ... ... == shutting down postmaster == server stopped === All 114 tests passed. === ... ... ... gmake[3]: Leaving directory `/srv/postgresql/work/postgresql-8.3.6/contrib/spi' rm -rf ./testtablespace mkdir ./testtablespace ./pg_regress --psqldir=/srv/postgresql/8.3.6/bin --schedule=./serial_schedule --srcdir=/srv/postgresql/work/postgresql-8.3.6/src/test/regress --multibyte=SQL_ASCII --load-language=plpgsql (using postmaster on Unix socket, default port) == dropping database "regression" == psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? command failed: "/srv/postgresql/8.3.6/bin/psql" -X -c "DROP DATABASE IF EXISTS \"regression\"" "postgres" gmake[2]: *** [installcheck] Error 2 gmake[2]: Leaving directory `/srv/postgresql/work/postgresql-8.3.6/src/test/regress' gmake[1]: *** [installcheck] Error 2 gmake[1]: Leaving directory `/srv/postgresql/work/postgresql-8.3.6/src/test' gmake: *** [installcheck] Error 2 make: 1254-004 The error code from the last command is 2. Stop. --- I'm wrong in anything? Thanks! -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cbrt() broken in AIX
2009/3/4 André Volpato : > I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration > error that I presume its related to this [1] thread. > > Here´s some info: > - Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits > - AIX 5.3.0 > - Postgresql 8.3.6 > - gcc version 4.2.0 > - GNU Make 3.80 > (...) Here: postg...@db01 $ id uid=204(postgres) gid=1(staff) postg...@db01 $ export CC="gcc" postg...@db01 $ export CFLAGS="-maix64" postg...@db01 $ export LDFLAGS="-Wl,-bbigtoc" postg...@db01 $ export OBJECT_MODE=64 postg...@db01 $ export AR="ar -X64" postg...@db01 $ ./configure --enable-integer-datetimes --prefix=/srv/postgresql/8.3.6 postg...@db01 $ make ... ... And all is done fine. Course, all above is for 64 bits compilling. How you are trying that? []s Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cbrt() broken in AIX
2009/3/5 André Volpato : > Guedes my friend, that doesnt work either. ":( > First, I put back only the "define my_cbrt" line in float.c, and then tryed > to configure with all the flags above. > > The "Undefined symbols" errors keep coming. > > As Thomas pointed out, I think my AIX is missing libm. > > I will try to install it and post again when I have some news. Please, install the linuxtoolbox for AIX, try compile again and tell us. It means that somethings is missing in your box. []s Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ERROR: "failed to locate grouping columns"
Hi all, I'm sending this to -hackers because i don't now if it is a bug or a expected behavior. I have the view bellow (if the selects bellow shows unformated in this email, i put this in http://guedesoft.net/txt/vw_error.txt too. ): CREATE OR REPLACE VIEW vw_my_test AS SELECT DISTINCT cv.cv_cdct AS cdct, -- returns a int4 cv.cv_cdcp AS cdcp, -- returns a numeric ( SELECT cp.cp_nmfts FROM cptv cp WHERE cp.cp_cdcp = cv.cv_cdcp) AS nmfts, -- returns a varchar epr.epr_nrctn AS nrctn,-- returns a numeric cv.cv_tpvnc AS tpvnc, -- returns a int4 ( SELECT rg.rg_dsc FROM rgst rg WHERE rg.rg_idrg = cv.cv_tpvnc) AS dsc_vnc, -- returns a varchar cv.cv_ndcdv AS ndcdv_prnc, -- returns a varchar ( SELECT ps.ps_nm FROM pss ps WHERE ps.ps_nrdc = cv.cv_ndcdv) AS nmdvprnc, -- returns a varchar cvd.cvd_nmdvsld AS ndcdv_sld, -- returns a varchar ( SELECT ps.ps_nm FROM pss ps WHERE ps.ps_nrdc = cvd.cvd_nmdvsld) AS nmdvsld, -- returns a varchar cv.cv_vltt AS vltt,-- returns a numeric(18,2) ( SELECT max(oc.oc_dtagn) AS max FROM ocr oc WHERE oc.oc_cdct = ev.ev_cdct) AS dtagn, -- returns a date ( SELECT CASE WHEN abs(min(pe.pe_dtvnc) - date(now())) <= 15 THEN 1231230 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 16 AND abs(min(pe.pe_dtvnc) - date(now())) <= 30 THEN 1341231 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 31 AND abs(min(pe.pe_dtvnc) - date(now())) <= 45 THEN 2345342 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 46 AND abs(min(pe.pe_dtvnc) - date(now())) <= 60 THEN 654653 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 61 AND abs(min(pe.pe_dtvnc) - date(now())) <= 90 THEN 45254 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 91 AND abs(min(pe.pe_dtvnc) - date(now())) <= 180 THEN 13425 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 181 AND abs(min(pe.pe_dtvnc) - date(now())) <= 360 THEN 12346 ELSE 13417 END AS "case" FROM pcep pe WHERE pe.pe_nrcntr = ev.ev_nrcntr) AS dsatr, cv.cv_stc AS stc, rg.rg_cdrgs AS cdrgs, rg.rg_dsc AS dsc_stc FROM epvnc ev JOIN ctvn cv ON cv.cv_cdct = ev.ev_cdct JOIN eptm epr ON epr.epr_nrcntr = ev.ev_nrcntr JOIN rgst rg ON cv.cv_stc = rg.rg_idrg LEFT JOIN cvdvsld cvd ON cvd.cvd_cdct = cv.cv_cdct ; And bellow is the select that returns: "ERROR: failed to locate grouping columns" when no rows is returned by the View above, but it runs well when one or more rows is returned by same view. --- SELECT cdcp, nmfts, nrctn, tpvnc, dsc_vnc, ndcdv_prnc, nmdvpr, ndcdv_sld, max(vltt) FROM vw_my_test_ GROUP BY cdcp, nmfts, nrctn, tpvnc, dsc_vnc, ndcdv_prnc, nmdvpr, ndcdv_sld; --- If i group only by the *int* or *numeric* fields the error don't occurs, it only shows if i use a varchar in group by and the view returns 0 records If i change the view above to use JOINs then all works fine... meaning the problem is something in SUBSELECTs and VARCHAR used in that way. Is this a bug or a expected behavior? best regards. -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERROR: "failed to locate grouping columns"
Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu: > "Dickson S. Guedes" writes: > > And bellow is the select that returns: "ERROR: failed to locate grouping > > columns" > > when no rows is returned by the View above, but it runs well when one or > > more > > rows is returned by same view. > > I really have a hard time believing that whether you get that error is > contingent on whether the view returns some rows or not. That's a > planner message and couldn't possibly have to do with what happens > at runtime. And I was really confused when I've tested. I've seen that it's a planner message, then I discard SUBSELECTs and use JOINs and it works. > Would you put together a complete example, instead of leaving us to > guess what's underlying the view? Ok, I'll prepare a full test and send it. > And what PG version is this? Oh! I forgot to say, the version is 8.3.6. Thanks. -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERROR: "failed to locate grouping columns"
Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu: > I really have a hard time believing that whether you get that error is > contingent on whether the view returns some rows or not. That's a > planner message and couldn't possibly have to do with what happens > at runtime. Well, today I have more time to study the environment and I'd see that was a coincidence in the fact that when the grouping by in the view works fine and it was returning values, it was tested in a 8.1.4 PG version. Now I made a complete test in 8.1.4 and 8.3.6. In the first the error not occurs, in the last yes. > Would you put together a complete example, instead of leaving us to > guess what's underlying the view? And what PG version is this? Attached there is a dump with the tables and views related: vw_cnt_vnc_tst -> is my view before I changed sub-selects to JOIN vw_that_works - an example view that works without grouping some columns vw_that_not_works -> an example view that throws an error thanks. -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br test_error_failed_to_locate_grouping_columns.dmp.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sampling Profler for Postgres
Em Seg, 2009-03-09 às 13:55 +0900, ITAGAKI Takahiro escreveu: > Therefore, I'd like to propose an profiler with sampling approach in 8.5. > The attached patch is an experimental model of the profiler. > Each backends reports its condtion in PgBackendStatus.st_condition > and the stats collector process does polling them every seconds. Hi Takahiro! Compiled and Works fine here on Ubuntu 8.04 2.6.25.15-bd-mod #1 SMP PREEMPT Thu Nov 27 10:05:44 BRST 2008 i686 GNU/Linux d...@analise3:/srv/postgresql/HEAD$ ./bin/pgbench -i -s3 d...@analise3:/srv/postgresql/HEAD$ ./bin/pgbench -i -s3 -d postgres transaction type: TPC-B (sort of) scaling factor: 3 query mode: simple number of clients: 4 duration: 60 s number of transactions actually processed: 3730 tps = 62.090946 (including connections establishing) tps = 62.112183 (excluding connections establishing) d...@analise3:/srv/postgresql/HEAD$ ./bin/psql -c "SELECT * FROM pg_diff_profiles" -d postgres profid | profname | percent +--+- 15 | Network:Recv | 50.45 16 | Network:Send | 24.55 32 | Lock:Transaction |7.14 3 | CPU |5.80 20 | XLog:Flush |3.13 31 | Lock:Tuple |2.68 7 | CPU:Execute |1.79 6 | CPU:Plan |1.79 46 | LWLock:WALWrite |1.34 11 | CPU:Commit |0.89 19 | XLog:Write |0.45 (11 rows) Two questions here: 1) How will be this behavior in a syncrep environment? I don't have one here to test this, yet. 2) I couldn't find a clear way to disable it. There is one in this patch or are you planning this to future? Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sampling Profler for Postgres
Em Ter, 2009-03-10 às 10:23 +0900, ITAGAKI Takahiro escreveu: > Thanks for testing. Network (or communication between pgbench and postgres) > seems to be a bottleneck on your machine. Yes, it is a very poor machine for quicktest. I'll test other environments tomorrow. > > Two questions here: > > > > 1) How will be this behavior in a syncrep environment? I don't have one > > here to test this, yet. > > I think it has relation with hot-standby, but not syncrep. > Profiling is enabled when stats collector process is running. > We already run the collector during warm-standby, so profiling would > be also available on log-shipping slaves. OK. Thanks. > > 2) I couldn't find a clear way to disable it. There is one in this patch > > or are you planning this to future? > > Ah, I forgot sampling should be disabled when track_activities is off. > I'll fix it in the next patch. Also, I'd better measure overheads > by the patch. Will be very nice if I could on/off it. When done, please send us. I'd like to test it in some stress scenarios, enabling and disabling it on some environment and comparing with my old benchmarks. Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax
Em Ter, 2009-04-21 às 17:20 +0530, Kedar Potdar escreveu: > Hi , > > We are working on a patch to automate partitioning in PostgreSQL. Nice. ":) > For Range partitions, we have proposed the syntax which is as > follows > > (...) > PARTITION BY RANGE (emp_id) > ( > emp_500 (START 1 END 500), > emp_1500 (START 500 END 1500), > emp_4000 (START 1520 END 4000) > ); What if I need more columns to set the partitions? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax
Vacuum, I guess you forgot to reply-to-all. ":) Em Ter, 2009-04-21 às 16:05 +0200, vac...@quantentunnel.de escreveu: > why not partitions by "conditions"? > > you can do that in similar way how "case when then " works .. > > CREATE PARTITIONS ON > SWITCH > CASE THEN , > CASE THEN , > CASE THEN , > DEFAULT emp_default; > > with a difference to case: may not be a boolean expression > > or you can do it as CASE works > > forinstance: > > CREATE PARTITIONS ON emp ( > CASE WHEN THEN emp_xxx, > CASE WHEN THEN emp_yyy, > CASE WHEN emp_zzz, > ELSE emp_default > END CASE; > ); > > Original-Nachricht > > Datum: Tue, 21 Apr 2009 10:46:41 -0300 > > Von: "Dickson S. Guedes" > > An: Kedar Potdar , pgsql-hackers@postgresql.org > > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > > > Em Ter, 2009-04-21 às 17:20 +0530, Kedar Potdar escreveu: > > > Hi , > > > > > > We are working on a patch to automate partitioning in PostgreSQL. > > > > Nice. ":) > > > > > For Range partitions, we have proposed the syntax which is as > > > follows > > > > > > (...) > > > PARTITION BY RANGE (emp_id) > > > ( > > > emp_500 (START 1 END 500), > > > emp_1500 (START 500 END 1500), > > > emp_4000 (START 1520 END 4000) > > > ); > > > > What if I need more columns to set the partitions? > > > > > > []s > > -- > > Dickson S. Guedes > > mail/xmpp: gue...@guedesoft.net - skype: guediz > > http://guedesoft.net - http://planeta.postgresql.org.br > -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax
Em Ter, 2009-04-21 às 19:33 +0530, Kedar Potdar escreveu: (...) > You can have multiple columns as partition key attributes and values > for these attributes should appear in the order specified. How would be the behavior if the partition keys are foreing key with ON UPDATE CASCADE? I'm thinking in the scenario that this is allowed we can do a update that don't satisfies the actual partition rule but another in other partition, so the data will be moved? This make senses? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Patch to fix search_path defencies with pg_bench
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu: > Greg Smith writes: > > I once did some pgbench testing on a system that included a real > > "accounts" table in a named schema. "pgbench -i" will execute "drop table > > if exists accounts". It had already accidentally wiped out the copy of > > the accounts table on the system during an earlier test, before the schema > > policy was in place, leaving everyone wary of it. > > Seems like the right policy for that is "run pgbench in its own > database". A text warning about this could be shown at start of pgbench if the target database isn't named "pgbench", for examplo, or just some text could be added to the docs. regards. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Patch to fix search_path defencies with pg_bench
Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu: > Alvaro Herrera writes: > > I think it would be better that the schema is specified on the command > > line. > > Surely that's more work than the issue is worth. It's also inconvenient > to use, because you'd have to remember to give the switch both for the > -i run and the normal test runs. So, in my opinion, the Joshua alternative is a good little change that let "pgbench" runs in a more flexible way. But, there is the possibility that someone are using an automated script that could be broken by this change? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Patch to fix search_path defencies with pg_bench
Em Qua, 2009-05-06 às 13:49 -0700, Joshua D. Drake escreveu: > On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote: > > Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu: > > > Alvaro Herrera writes: > > > > I think it would be better that the schema is specified on the command > > > > line. > > > > > > Surely that's more work than the issue is worth. It's also inconvenient > > > to use, because you'd have to remember to give the switch both for the > > > -i run and the normal test runs. > > > > So, in my opinion, the Joshua alternative is a good little change that > > let "pgbench" runs in a more flexible way. > > > > But, there is the possibility that someone are using an automated script > > that could be broken by this change? > > Only if the role pgbench is using as an explicit search_path set. So, in a way to avoid the scenario where a ROLE has an explicit search_path set to schemes that already have tables named same as the pgbench's tables, doesn't makes sense also create a "pgbench_" suffix for them? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
[HACKERS] WIP patch for TODO Item: Add prompt escape to display the client and server versions
This is a WIP patch (for the TODO item in the subject) that I'm putting in the Commit Fest queue for 8.5. regards... -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br psql_escape_client_server_version.patch.bz2 Description: application/bzip signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] WIP patch for TODO Item: Add prompt escape to display the client and server versions
Em Qui, 2009-05-07 às 10:11 +0300, Peter Eisentraut escreveu: > On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote: > > This is a WIP patch (for the TODO item in the subject) that I'm putting > > in the Commit Fest queue for 8.5. > > How about you just put the values in a variable and use the existing facility > to put those variables in the prompt? Change all "pset.version calculations" in "case 'V'" to something like "case 'v'" is doing with PG_VERSION? Yes, could be better. The specific code used to %V and %v in this patch was "inspired" in the code in connection_warnings function in commands.c, so should this be "refactored" too? Thanks. Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
[HACKERS] PATCH to fix two little typo in charset.sgml
Hi all, Attached is a patch to fix a command line example in charset.sgml. I hope it is correct. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br fix_typo_lc_collatein_charset_sgml.patch.bz2 Description: application/bzip signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] PATCH to fix two little typo in charset.sgml
Em Qui, 2009-05-14 às 09:35 +0300, Heikki Linnakangas escreveu: > Dickson S. Guedes wrote: > > Hi all, > > > > Attached is a patch to fix a command line example in charset.sgml. > > No, the options really are called LC_COLLATE and LC_CTYPE now. They were > renamed on 6th of April, just before beta1 Oops! Sorry, my fault, forget it. ":/ I was missed that and my local version of repository wasn't updating rightly ":( I did a cvs update from scratch now and it is working as expected. Thanks... -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
[HACKERS] generate_series from now to infinity...
Hi all
Is a simple "SELECT generate_series(now(), CAST('infinity'::date AS
timestamp), interval '1 hour');" working forever, an expected
behavior?
regards...
--
Dickson S. Guedes
-
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] generate_series from now to infinity...
Em Sáb, 2009-05-16 às 23:40 -0400, Tom Lane escreveu:
> "Dickson S. Guedes" writes:
> > Is a simple "SELECT generate_series(now(), CAST('infinity'::date AS
> > timestamp), interval '1 hour');" working forever, an expected
> > behavior?
>
> Uh, what were you expecting it to do?
Perhaps, a HINT?
> Actually, I believe it will fail eventually when the repeated additions
> overflow ... in 294277 AD. So you've got about 2 billion timestamp
> additions to wait through.
A customer are porting his application to 8.4, and are using a query
like that. Someone unintentionally included a "infinity" date and that
query have been running until they see the test server memory at 99% and
cpu at 100%.
I suggested him to use LIMIT.
[]s
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
signature.asc
Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] generate_series from now to infinity...
Em Dom, 2009-05-17 às 19:22 +0200, hubert depesz lubaczewski escreveu:
> it doesn't for this query:
>
> SELECT i from generate_series(now(), CAST('infinity'::date AS
> timestamp), interval '1 hour') as x (i) limit 3;
>
> which (as far as i understand it) should be the same.
>
> why is it not limiting generate_series in the second example? is it
> intentional?
The EXPLAIN output differ between both.
postgres=# EXPLAIN SELECT generate_series(now(), CAST('infinity'::date
AS timestamp), interval '1 hour') limit 3;
QUERY PLAN
Limit (cost=0.00..0.02 rows=1 width=0)
-> Result (cost=0.00..0.02 rows=1 width=0)
postgres=# explain SELECT i from generate_series(now(),
CAST('infinity'::date AS timestamp), interval '1 hour') as x (i) limit
3;
QUERY PLAN
Limit (cost=0.00..0.05 rows=3 width=8)
-> Function Scan on generate_series x (cost=0.00..17.50 rows=1000
width=8)
signature.asc
Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Synchronous replication: status of standby side
Where can I find a more recent version of syncrep patch. The last one that I've here is synch_rep_0428 and I'm getting segfault with it ":(. In Wiki [1] the last is syncrep_0305 [1] http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] Synchronous replication: status of standby side
Em Sex, 2009-06-05 às 16:19 +0900, Fujii Masao escreveu: > BTW. Which kind of status should be detectable when combining replication > with Hot Standby? There are several statuses. For example, the last commit > transaction in the primary server has been; > > 1) not sent to the standby server yet. > 2) sent to the standby, but not written there yet. > 3) sent and written, but not fsynced yet. > 4) sent, written and fsynced, but not applied yet. > 5) etc.. We could have some kind of "table of replication status code" and a "last status code" or a "history of status codes", which is used by clients (psql, pgadmin, etc) to shows the replication status. > And, which server should we ask the status, the primary or the standby server? Is expected that this information resides in both? For example, take a status code like "2) sent to the standby, but not written there yet.", if we expect this in primary, in the stand by must have something like "2) received from primary, but not written here yet." as status code? I guess that would be a good way to check whether and how replication is working in both servers. I agree with you that this feature should be postponed. Best Regards, -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [HACKERS] First CommitFest: July 15th
Em Thu, 02 Jul 2009 00:26:14 -0300, Brendan Jurd escreveu: I imagine that "migration" would basically be converting the wiki data into SQL, so I would need the database schema underlying the new CF app. How about parsing wiki content and create a "migration script" based on pgcommitfest tables sctructure [1]? [1] http://git.postgresql.org/gitweb?p=pgcommitfest.git;a=blob;f=etc/table.sql;h=c60a298c863ef3e88dcfd16572781d2b435ca629;hb=HEAD -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
