[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 <br...@momjian.us> 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] Why format() adds double quote?
2016-01-26 23:40 GMT-02:00 Tatsuo Ishii <is...@postgresql.org>:
>> 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 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
Re: [HACKERS] Why format() adds double quote?
2016-01-26 5:29 GMT-02:00 Tatsuo Ishii <is...@postgresql.org>: > > 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 <dan...@manitou-mail.org>:
> ...
> 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 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-24 8:04 GMT-02:00 Tatsuo Ishii <is...@postgresql.org>:
>> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule <pavel.steh...@gmail.com>
>> 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
[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
[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 lis...@guedesoft.net: 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
[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
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 david.g.johns...@gmail.com: On Friday, August 14, 2015, Dickson S. Guedes lis...@guedesoft.net 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 t...@sss.pgh.pa.us:
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] [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
2015-08-14 21:32 GMT-03:00 Gavin Flower gavinflo...@archidevsys.co.nz:
...
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] raw output from copy
2015-07-07 3:32 GMT-03:00 Pavel Stehule pavel.steh...@gmail.com: 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
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
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 t...@linux.com: On 16 May 2013 11:09, Pavel Stehule pavel.steh...@gmail.com 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 soroosh.sard...@gmail.com 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)
-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] Analyzing bug 8049
Em Sex, 2013-04-12 às 10:58 -0400, Tom Lane escreveu: Robert Haas robertmh...@gmail.com writes: On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane t...@sss.pgh.pa.us 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] 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] introduction
2013/4/9 Bert bier...@gmail.com: 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 t...@atsc.nl: 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
[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] patch to add \watch to psql
2013/4/3 Will Leinweber w...@heroku.com: 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] 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] psql: small patch to correct filename formatting error in '\s FILE' output
2013/1/22 Tom Lane t...@sss.pgh.pa.us: 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
Re: [HACKERS] Event Triggers: adding information
2013/1/21 Robert Haas robertmh...@gmail.com: 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 p...@pvh.ca: 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] Review: Patch to compute Max LSN of Data Pages
2013/1/20 Amit kapila amit.kap...@huawei.com: On Sunday, January 20, 2013 4:04 AM Dickson S. Guedes wrote: 2013/1/18 Amit kapila amit.kap...@huawei.com: 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 xi.w...@gmail.com: 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 dan...@heroku.com: 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] Review: Patch to compute Max LSN of Data Pages
2013/1/18 Amit kapila amit.kap...@huawei.com: 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] Parallel query execution
2013/1/16 Bruce Momjian br...@momjian.us: 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] CREATE SCHEMA IF NOT EXISTS
2012/8/28 David E. Wheeler da...@justatheory.com: 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] 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/17 Fabrízio de Royes Mello fabriziome...@gmail.com: 2012/8/17 Alvaro Herrera alvhe...@2ndquadrant.com 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
2012/8/16 Fabrízio de Royes Mello fabriziome...@gmail.com: 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] COMMUTATOR doesn't seem to work
2012/6/23 D'Arcy Cain da...@druid.net: On 12-06-23 12:17 AM, Tom Lane wrote: D'Arcy Cain da...@druid.net 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
Re: [HACKERS] Release versioning inconsistency
2012/6/21 Magnus Hagander mag...@hagander.net: On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes lis...@guedesoft.net wrote: 2012/6/20 Magnus Hagander mag...@hagander.net: On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote: On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net 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] Release versioning inconsistency
2012/6/20 Magnus Hagander mag...@hagander.net: On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote: On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net 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] pgsql_fdw in contrib
2012/6/18 Merlin Moncure mmonc...@gmail.com: 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] SQL standard changed behavior of ON UPDATE SET NULL/SET DEFAULT?
2012/6/16 Tom Lane t...@sss.pgh.pa.us: 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 t...@sss.pgh.pa.us: [... 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] patch: avoid heavyweight locking on hash metapage
2012/5/30 Robert Haas robertmh...@gmail.com: 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] Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message
2011/11/10 Jan Kundrát j...@flaska.net:
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 (a0));
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 br...@momjian.us 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] proposal: psql concise mode
2011/11/8 Alvaro Herrera alvhe...@commandprompt.com: 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 alvhe...@commandprompt.com: 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] proposal: psql concise mode
2011/11/5 Josh Kupershmidt schmi...@gmail.com: 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] autovacuum workers warning
2011/10/26 Euler Taveira de Oliveira eu...@timbira.com: 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] Separating bgwriter and checkpointer
2011/10/18 Simon Riggs si...@2ndquadrant.com: On Wed, Oct 5, 2011 at 8:02 AM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, Oct 5, 2011 at 5:10 AM, Dickson S. Guedes lis...@guedesoft.net 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 masao.fu...@gmail.com: On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs si...@2ndquadrant.com 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
[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 /row row !entryliteralfunctionlength(parameterstring/parametertypebytea/type, parameterencoding/parameter typename/type )/function/literal/entry entrytypeint/type/entry entry --- 1587,1593 /row row !entryliteralfunctionlength(parameterstring/parameter typebytea/type, parameterencoding/parameter typename/type )/function/literal/entry entrytypeint/type/entry entry -- 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
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
Re: [HACKERS] Separating bgwriter and checkpointer
2011/10/3 Simon Riggs si...@2ndquadrant.com: On Sun, Oct 2, 2011 at 11:45 PM, Dickson S. Guedes lis...@guedesoft.net 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
2011/10/2 Simon Riggs si...@2ndquadrant.com: On Thu, Sep 15, 2011 at 11:53 PM, Simon Riggs si...@2ndquadrant.com 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] Feature proposal: www_fdw
2011/9/28 Florian Pflug f...@phlo.org: 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 f...@phlo.org: 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] How to use CreateFunctionStmt's RETURN TABLE?
2011/7/26 _石头 tanji...@qq.com:
[... 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] Re: [COMMITTERS] pgsql: Don't use cp -i in the example WAL archive_command.
2011/6/18 Thom Brown t...@linux.com: [.. 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] patch for new feature: Buffer Cache Hibernation
2011/5/4 Greg Stark gsst...@mit.edu: On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI iwas...@jp.freebsd.org 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
[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 lis...@guedesoft.net 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 j...@agliodbs.com: 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=enformkey=dEh3WEwzOFhKWWw4dHdRS2VQTExRdVE6MQifq [... 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] caracara failing to bind to localhost?
2010/2/27 Tom Lane t...@sss.pgh.pa.us: 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] Duplicate key value error
Em Tue, 21 Jul 2009 02:07:47 -0300, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp escreveu: I modified the format logic to use StringInfo and don't cut off the message in 512 bytes. Key names and values will be never into '...'. I changed both both report_unique_violation() and ri_ReportViolation(). Hi Takahiro! Hum, for key names ok, but for values, wouldn't this worse the output when it is greater than 512 bytes? -- 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
Re: [HACKERS] WIP patch for TODO Item: Add prompt escape to display the client and server versions
Em Tue, 21 Jul 2009 16:52:48 -0300, Peter Eisentraut pete...@gmx.net escreveu: On Friday 17 July 2009 23:24:16 Dickson S. Guedes wrote: An use case that i can figure out is an user that connects in multiples instances in a lot of remote sites (like home-officer for example) and needs this information in the prompt to don't lost the context of your work. Is this valid? Is this and other similar cases quite enough to justify this patch? If yes I can change the patch to satisfy the Peter's suggestions, if no we can just ignore the patch and remove the item from TODO. I think there is enough support for the patch. So please adjust it to report the server version correctly. Thanks Peter, I'll adjust the patch and post a new version ASAP. 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 -- 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] Duplicate key value error
Em Fri, 03 Apr 2009 04:23:10 -0300, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp escreveu:
Vlad Arkhipov arhi...@dc.baikal.ru wrote:
Is it possible to print which key value is duplicated when 'Duplicate
key value violates unique constraint' occurs? Foreign key violation
error reports such kind of information.
I think it is not difficult from a technical standpoint.
The attached patch adds DETAIL messages to duplicate key value error:
postgres=# INSERT INTO tbl(pk1, pk2) VALUES ('A', 1);
ERROR: duplicate key value violates unique constraint tbl_pkey
DETAIL: Key (pk1,pk2)=(A,1) already exists.
If no objection, I'd like to submit the patch to the next commit-fest
(8.5).
Hi Takahiro, i'm the reviewer of your patch, and the following are my
comments about it:
The patch was applied totalty clean to CVS HEAD and compiled in Ubuntu
8.04, Ubuntu 8.10 and AIX 5.3, but failed in follow tests:
src/test/regress/expected/uuid.out
src/test/regress/expected/constraints.out
src/test/regress/expected/create_index.out
src/test/regress/expected/inherit.out
src/test/regress/expected/transactions.out
src/test/regress/expected/arrays.out
src/test/regress/expected/plpgsql.out
src/test/regress/expected/alter_table.out
src/test/regress/expected/tablespace.out
Would be good to modify the outputs to expect a new DETAIL: line.
Another comment is that the patch isn't in the standart context form, but
unified.
About the feature, it work as expected when I've INSERTed in both single
and compound-key or UPDATEd the key values to violates the constraint,
also in concurrently transactions. As expected too, when i INSERT or
UPDATE the key with a value thath overflow the 512 bytes i'm getting the
output as follow:
---
guedes=# INSERT INTO test_dup_char_key VALUES (repeat('x',1024), 'qq');
ERROR: duplicate key value violates unique constraint
test_dup_char_key_pkey
DETALHE: Key (...)=(...) already exists.
---
I'm thinking if could be better to shows Key (my_key)=(...) instead Key
(...)=(...) -- well, i don't know how much people uses a key with more
512B and how often it is to they don't know wich key it is, (just reading
a log, for example) to we consider this important.
On the other hand there is a comment by Tom [1] about to refactor this so
it's not btree-specific, but could be used by other index AMs, so could
be better trying to think about this in a way to find another alternative,
if it is possible.
[1] http://archives.postgresql.org/pgsql-hackers/2009-04/msg00234.php
Thanks for your patch!
[]s
Dickson S. Guedes
http://pgcon.postgresql.org.br
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] WIP patch for TODO Item: Add prompt escape to display the client and server versions
Em Thu, 16 Jul 2009 17:40:45 -0300, Peter Eisentraut pete...@gmx.net 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. More generally, does anyone actually need this feature? psql complains loudly enough if the version numbers are not the right ones. I don't know why this would need to be repeated in the prompt. An use case that i can figure out is an user that connects in multiples instances in a lot of remote sites (like home-officer for example) and needs this information in the prompt to don't lost the context of your work. Is this valid? Is this and other similar cases quite enough to justify this patch? If yes I can change the patch to satisfy the Peter's suggestions, if no we can just ignore the patch and remove the item from TODO. Thoughts? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://www.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] [pgsql-www] commitfest.postgresql.org
Em Thu, 09 Jul 2009 14:16:41 -0300, Tom Lane t...@sss.pgh.pa.us escreveu: I'm not particularly wedded to the wiki page history in terms of what it looks like or how it functions, but I do feel a need to know what other people have done recently. May be the new app could have a page with a filterable table log with some important columns like who do what on where and when. This could help, maybe with a RSS in that (like in git). []s Dickson S. Guedes http://pgcon.postgresql.org.br 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] Odd historical fact about Bison
Em Thu, 09 Jul 2009 19:58:01 -0300, Josh Berkus j...@agliodbs.com escreveu: The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and Solaris. What version of Bison are they shipping with? In AIX 5.3: bison (GNU Bison) 1.875 []s Dickson S. Guedes http://pgcon.postgresql.org.br 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] First CommitFest: July 15th
Em Thu, 02 Jul 2009 00:26:14 -0300, Brendan Jurd dire...@gmail.com 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
Re: [HACKERS] First CommitFest: July 15th
Em Thu, 02 Jul 2009 00:15:22 -0300, Robert Haas robertmh...@gmail.com escreveu: The main problem is that my fine software only contains test data at this point. If we have any volunteers who are available to migrate the information from the Wiki to my app (which will involve a fair amount of legwork), then I recommend that we accept their help as it will make things easier for the CommitFest management team... which I am all in favor of, especially now that I'm on that team. On the other hand, if we don't have any volunteers, then I recommend that we continue to use the Wiki for this CommitFest but make sure that all patches for the next CommitFest, and any that follow, get added via the app. So, any volunteers? I don't know if this tool will be approved yet, but I'm working on copying the Wiki entries of CommitFest to pgcommitfest. Until now i created the following CommitFest Topics based on topics in the Wiki: * Contrib modules * EXPLAIN * Error Reporting * Instrumentation * Miscellaneous * My New Topic * Performance * Replication * SQL language features * Security All the patches on Miscellaneous topic in Wiki was copied to coridan, but i couldn't copy comments of patches thath have one. Would be nice if a theres is a way to order by some column like Patch Name, Topic, Status, Author and Last Activity for example. Some descriptions was truncated because de maxsize of textbox. 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 -- 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] 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] 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] generate_series from now to infinity...
Em Sáb, 2009-05-16 às 23:40 -0400, Tom Lane escreveu:
Dickson S. Guedes lis...@guedesoft.net 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
[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] 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] 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] 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
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 gsm...@gregsmith.com 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 alvhe...@commandprompt.com 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 alvhe...@commandprompt.com 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] 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 table SWITCH any expression CASE value THEN part_1, CASE value THEN part_2, CASE value THEN part_3, DEFAULT emp_default; with a difference to case: value may not be a boolean expression or you can do it as CASE works forinstance: CREATE PARTITIONS ON emp ( CASE WHEN value THEN emp_xxx, CASE WHEN value THEN emp_yyy, CASE WHEN value emp_zzz, ELSE emp_default END CASE; ); Original-Nachricht Datum: Tue, 21 Apr 2009 10:46:41 -0300 Von: Dickson S. Guedes lis...@guedesoft.net An: Kedar Potdar kedar.pot...@gmail.com, 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] 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] 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
[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 lis...@guedesoft.net 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] cbrt() broken in AIX
2009/3/5 André Volpato andre.volp...@ecomtecnologia.com.br: 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
Re: [HACKERS] cbrt() broken in AIX
2009/3/4 André Volpato andre.volp...@ecomtecnologia.com.br: 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
[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] 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
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] 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] 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: 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 7085) was terminated by signal 6: Aborted LOG: terminating any other active server processes FATAL
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
