Re: [HACKERS] Turning off HOT/Cleanup sometimes
El 15/09/14 18:13, Simon Riggs escribió: > On 15 September 2014 17:09, Robert Haas wrote: > >> Do we really want to disable HOT for all catalog scans? > The intention of the patch is that catalog scans are treated > identically to non-catalog scans. The idea here is that HOT cleanup > only occurs on scans on target relations, so only INSERT, UPDATE and > DELETE do HOT cleanup. > > It's possible that many catalog scans don't follow the normal target > relation logic, so we might argue we should use HOT every time. OTOH, > since we now have separate catalog xmins we may find that using HOT on > catalogs is no longer effective. So I could go either way on how to > proceed; its an easy change either way. > I setup a more concurrent scenario and the difference is quite larger: Without patch: 1st concurrent with writes: tps = 5705.261620 (including connections establishing) tps = 5945.338557 (excluding connections establishing) 2nd no writes being executed: tps = 9988.792575 (including connections establishing) tps = 11059.671351 (excluding connections establishing) Patched version: 1st concurrent with writes: tps = 9476.741707 (including connections establishing) tps = 10274.831185 (excluding connections establishing) 2nd no writes being executed: tps = 12993.644808 (including connections establishing) tps = 15171.214744 (excluding connections establishing) Stats (writes have been run with a time limit, not by tx): hotcleanup=# select relname ,n_live_tup, n_dead_tup, n_tup_hot_upd from pg_stat_user_tables where relname ~ 'pgbench'; relname | n_live_tup | n_dead_tup | n_tup_hot_upd --+++--- pgbench_tellers |500 | 0 | 2044192 pgbench_accounts |5109728 | 310842 | 1969264 pgbench_history |2265882 | 0 | 0 pgbench_branches | 50 | 0 | 2237167 (4 rows) hotcleanup=# select relname ,n_live_tup, n_dead_tup, n_tup_hot_upd from pg_stat_user_tables where relname ~ 'pgbench'; relname | n_live_tup | n_dead_tup | n_tup_hot_upd --+++--- pgbench_history |2148946 | 0 | 0 pgbench_tellers |500 | 0 | 1969675 pgbench_branches | 50 | 0 | 2150655 pgbench_accounts |5098774 | 300123 | 1897484 (4 rows) I ran the regression tests over the patched version and they passed ok. -- -- Emanuel Calvo http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] printing table in asciidoc with psql
El 16/09/14 16:52, Szymon Guz escribió:
> Hi,
> I've been working a little bit on a patch for printing tables in
> asciidoc with psql.
>
> It's not finished yet, I'm not sure it there is any sense in
> supporting border types etc. The code is not cleared so far, but any
> remarks on the style not playing well with the normal postgres style
> of code are welcomed.
>
> The code just works. With extended and normal modes. With table
> columns made of funny characters, with alignment of data in table
> cells. I was trying to implement it similar to the html export
> function, however escaping of the strings was much easier, as the
> normal html-way substitution is not easy to implement in asciidoc.
>
> I'd like to ask you for any advices for this code.
>
> thanks,
> Szymon
>
>
Please add "asciidoc" in src/bin/psql/help.c[354]
354,96-103
fprintf(output, _(" format set output format
[unaligned, aligned, wrapped, html, latex, ..]\n"));
Tested the patch and worked fine.
--
--
Emanuel Calvo http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] Turning off HOT/Cleanup sometimes
El 14/09/14 17:37, Simon Riggs escribió: > On 12 September 2014 18:19, Simon Riggs wrote: >> On 12 September 2014 15:30, Tom Lane wrote: >>> After a little bit I remembered there was already a function for this. >>> So specifically, I'd suggest using ExecRelationIsTargetRelation() >>> to decide whether to mark the scan as requiring pruning. >> Sounds cool. Thanks both, this is sounding like a viable route now. > Yes, this is viable. > > Patch attached, using Alvaro's idea of use-case specific pruning and > Tom's idea of aiming at target relations. Patch uses or extends > existing infrastructure, so its shorter than it might have been, yet > with all that bufmgr yuck removed. > > This is very, very good because while going through this I notice the > dozen or more places where we were pruning blocks in annoying places I > didn't even know about such as about 4-5 constraint checks. In more > than a few DDL commands like ALTER TABLE and CLUSTER we were even > pruning the old relation prior to rewrite. > A simple performance test with the following variables: LOOP=50 CONN=60 TXSS=500 SCALE=30 Select only: WITH PATCH Average: 20716.1 tps NO PATCH Average: 19141.7 tps With writes: WITH PATCH Average: 2602.65 NO PATCH Average: 2565.32 TODO: - Consistency check. - ALTER and CLUSTER test. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: BRIN indexes (was Re: [HACKERS] Minmax indexes)
El 08/09/14 13:02, Alvaro Herrera escribió:
> Here's version 18. I have renamed it: These are now BRIN indexes.
>
> I have fixed numerous race conditions and deadlocks. In particular I
> fixed this problem you noted:
>
> Heikki Linnakangas wrote:
>> Another race condition:
>>
>> If a new tuple is inserted to the range while summarization runs,
>> it's possible that the new tuple isn't included in the tuple that
>> the summarization calculated, nor does the insertion itself udpate
>> it.
> I did it mostly in the way you outlined, i.e. by way of a placeholder
> tuple that gets updated by concurrent inserters and then the tuple
> resulting from the scan is unioned with the values in the updated
> placeholder tuple. This required the introduction of one extra support
> proc for opclasses (pretty simple stuff anyhow).
>
> There should be only minor items left now, such as silencing the
>
> WARNING: concurrent insert in progress within table "sales"
>
> which is emitted by IndexBuildHeapScan (possibly thousands of times)
> when doing a summarization of a range being inserted into or otherwise
> modified. Basically the issue here is that IBHS assumes it's being run
> with ShareLock in the heap (which blocks inserts), but here we're using
> it with ShareUpdateExclusive only, which lets inserts in. There is no
> harm AFAICS because of the placeholder tuple stuff I describe above.
Debuging VACUUM VERBOSE ANALYZE over a concurrent table being
updated/insert.
(gbd)
Breakpoint 1, errfinish (dummy=0) at elog.c:411
411ErrorData *edata = &errordata[errordata_stack_depth];
The complete backtrace is at http://pastebin.com/gkigSNm7
Also, I found pages with an unkown type (using deafult parameters for
the index
creation):
brin_page_type | array_agg
--------+---
unknown (00) | {3,4}
revmap | {1}
regular| {2}
meta | {0}
(4 rows)
>
>
--
--
Emanuel Calvo
@3manuek
[HACKERS] Patch for CREATE RULE sgml -- Was in: [DOCS]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi guys,
I realized that the output of the CREATE RULE has not a detailed
output for the "events" parameter.
But the question here is that I'm not sure which format follow:
{ INSERT | UPDATE | DELETE | SELECT}
or
INSERT
UPDATE
DELETE
SELECT
- --
I attach a patch for each one.
I sent a mail to pgsql-docs but no response has been received.
Thanks and regards,
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTLGERAAoJEIBeI/HMagHmUYcP/ibZQaTYDgLmclqgv6wbeTnT
m9d9mhYEJVhdyowGcJ5s+OSCN5tj2vGJifjxUAQ+6hW+0mzj9kqQLoWJyb9DYn1o
AbbUM6+p2Q1+P5KAUYMVZDRiGN6EqFPw2BgsXhIA2rXHT/PiSPpKvFK6wQ0rmSyX
houtfrXEl4zzLHyrmHZmWHyz6DgPyTM/jtHTd/yhAl1OxKR5V583bHEfDUz3zYEX
v6NjBiq5TY6uaXVF0B0cya8nRfW3KP240cwZTF5zRoyHZ1LNlHLPEPs2huNZPLbk
tp3UIHhdiZKl7ddJcWTTeuv4ABQXQVBLQwHWR91szMr+dz/Wsk0zmeFNzlCKCzzN
cehz5n6yewIiosS1MlD7lxOAHPN0yiXtsjiOWoQYbLaxkcTO74oUZK1iWXD025TB
vSegM0L1a1GJFNjyZhQnUgMLWELhsC5y1g7Pn7D9YkzeyicEFtFRTkGDR9eh9LmV
PNtV4w5M/hZtbappfoW7IL6tLtZnjHUA+UjPflnoae0uQ8G+MOW+3rkXt30BksdR
VXvbhXTXaKLj2cEs8cfyBuVUs8AwBGssjfX2OxkSYjvGYcHVoSN/o0cqOWUD/mMi
98ORZcLrzWk70kQ0zxW9wIXbkp4M+8uogyzL9ViveiLREHYD9SRlWMGPpgbcs/aM
fB7fgznJGvXZoRefJKdQ
=UWLa
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml
index d3212b5..22b46e2 100644
--- a/doc/src/sgml/ref/create_rule.sgml
+++ b/doc/src/sgml/ref/create_rule.sgml
@@ -24,6 +24,9 @@ PostgreSQL documentation
CREATE [ OR REPLACE ] RULE name AS ON event
TO table_name [ WHERE condition ]
DO [ ALSO | INSTEAD ] { NOTHING | command | ( command ; command ... ) }
+
+where event can be one of:
+{ INSERT | UPDATE | DELETE | SELECT}
diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml
index d3212b5..a4df024 100644
--- a/doc/src/sgml/ref/create_rule.sgml
+++ b/doc/src/sgml/ref/create_rule.sgml
@@ -24,6 +24,12 @@ PostgreSQL documentation
CREATE [ OR REPLACE ] RULE name AS ON event
TO table_name [ WHERE condition ]
DO [ ALSO | INSTEAD ] { NOTHING | command | ( command ; command ... ) }
+
+where event can be one of:
+INSERT
+UPDATE
+DELETE
+SELECT
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Additional information on log_line_prefix
Hi guys, I'm working on a quick convertion script for query reviews and I wonder if a feature request to add the following values will be possible: %D = duration %L = lock_time (lock only for this query) %E = estimated rows %R = total rows returned %B = total bytes sent %T = temporal tables used Those prefixes/values are just examples/proposals. Thanks for the hard work! -- -- Emanuel Calvo
Re: [HACKERS] Parallel pg_basebackup
That looks promising! Thanks Peter! 2013/8/24 Peter Eisentraut > On Fri, 2013-08-23 at 10:51 -0300, Emanuel Calvo wrote: > > I was wondering if there is a proposal for parallelize pg_basebackup > > There isn't one, but after some talk behind the scenes, I think we > should definitely look into it. > > -- -- Emanuel Calvo
[HACKERS] Parallel pg_basebackup
Hi guys, I was wondering if there is a proposal for parallelize pg_basebackup (sorry if there is already one, I looked into the inbox and did not find any). I made a simple test and the performance gain is pretty considerable using parallel rsync processes vs. single pg_basebackup. i.e., for 46GB of data I had the following results: Using https://gist.github.com/rcoup/5358786: rsync, parallel, including the xlogs real 18m52.674s user 33m54.728s sys 13m44.604s (-x option) real23m26.802s user0m24.392s sys 3m55.116s Actually, AWS services limits the bandwidth per process but if you have parallel processes, none of them will have the IOPS decreased which will be translated in a great improvement. Also the network bandwidth is strong between the regions. Thanks guys! -- -- Emanuel Calvo
Re: [HACKERS] [Devel 9.2] Index-only scan in count aggregation
El día 18 de abril de 2012 18:17, Robert Haas escribió: > On Wed, Apr 18, 2012 at 12:13 PM, Emanuel Calvo > wrote: >> Hi guys, >> >> I'm one of the nightly sources of 9.2devel. I was trying some simple >> queries and I realized something: >> >> stuff=# explain (analyze true, costs true, buffers true, timing true, >> verbose true) select count(i) from lot_of_values; >> QUERY >> PLAN >> --- >> Aggregate (cost=213496.00..213496.01 rows=1 width=4) (actual >> time=60400.788..60400.791 rows=1 loops=1) >> Output: count(i) >> Buffers: shared hit=2400 read=86096 >> -> Seq Scan on public.lot_of_values (cost=0.00..188496.00 >> rows=1000 width=4) (actual time=0.371..32227.791 rows=1000 >> loops=1) >> Output: i, t1, r1, r2, r3, d1 >> Buffers: shared hit=2400 read=86096 >> Total runtime: 60402.460 ms >> (7 rows) >> >> stuff=# set enable_seqscan=off; >> SET >> stuff=# explain (analyze true, costs true, buffers true, timing true, >> verbose true) select count(i) from lot_of_values; >> >> QUERY PLAN >> >> Aggregate (cost=351292.03..351292.04 rows=1 width=4) (actual >> time=63278.472..63278.475 rows=1 loops=1) >> Output: count(i) >> Buffers: shared hit=1 read=110379 >> -> Index Only Scan using lot_of_values_pkey on >> public.lot_of_values (cost=0.00..326292.03 rows=1000 width=4) >> (actual time=42.028..35217.460 rows=1000 loops=1) >> Output: i >> Heap Fetches: 1000 >> Buffers: shared hit=1 read=110379 >> Total runtime: 63278.720 ms >> (8 rows) >> >> >> I know, still development. Just wanna know if there will be an >> improvement for this in the next patches or the idea is to maintain >> this behaviour. >> >> Cheers and thanks for the amazing work you all had done! > > I'm not sure what you're unhappy about. It seems that the query > planner picked the fastest plan (a sequential scan) and then when you > disabled that it picked the second-fastest plan (an index-only scan). > > The index-only scan would have a chance of beating the sequential scan > if the table had been recently vacuumed, but not in the case where > every row is going to require a heap fetch. > Oh, I see now. Honestly, I thought it wasn't necessary to make a heap fetch. The table doesn't have any modifications, but with the vacuum the cost changed. Checking the source code, I saw what you are talking about: /* * We can skip the heap fetch if the TID references a heap page on * which all tuples are known visible to everybody. In any case, * we'll use the index tuple not the heap tuple as the data source. */ Thanks for the information! -- -- Emanuel Calvo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [Devel 9.2] Index-only scan in count aggregation
Hi guys, I'm one of the nightly sources of 9.2devel. I was trying some simple queries and I realized something: stuff=# explain (analyze true, costs true, buffers true, timing true, verbose true) select count(i) from lot_of_values; QUERY PLAN --- Aggregate (cost=213496.00..213496.01 rows=1 width=4) (actual time=60400.788..60400.791 rows=1 loops=1) Output: count(i) Buffers: shared hit=2400 read=86096 -> Seq Scan on public.lot_of_values (cost=0.00..188496.00 rows=1000 width=4) (actual time=0.371..32227.791 rows=1000 loops=1) Output: i, t1, r1, r2, r3, d1 Buffers: shared hit=2400 read=86096 Total runtime: 60402.460 ms (7 rows) stuff=# set enable_seqscan=off; SET stuff=# explain (analyze true, costs true, buffers true, timing true, verbose true) select count(i) from lot_of_values; QUERY PLAN Aggregate (cost=351292.03..351292.04 rows=1 width=4) (actual time=63278.472..63278.475 rows=1 loops=1) Output: count(i) Buffers: shared hit=1 read=110379 -> Index Only Scan using lot_of_values_pkey on public.lot_of_values (cost=0.00..326292.03 rows=1000 width=4) (actual time=42.028..35217.460 rows=1000 loops=1) Output: i Heap Fetches: 1000 Buffers: shared hit=1 read=110379 Total runtime: 63278.720 ms (8 rows) I know, still development. Just wanna know if there will be an improvement for this in the next patches or the idea is to maintain this behaviour. Cheers and thanks for the amazing work you all had done! -- -- Emanuel Calvo -- 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: [pgeu-general] REMINDER: FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers
> > Please keep in mind, that the Call for Speakers is open until December 20th. > Only a few days left. > Now it's a good time to submit your proposal ;-) > Did someone applied? -- -- Emanuel Calvo Helpame.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] [Feature Request] \dx show "options"
2011/11/14 Robert Haas : > On Mon, Nov 14, 2011 at 10:45 AM, Emanuel Calvo > wrote: >> 2011/11/10 Robert Haas : >>> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo >>> wrote: >>>>> \dew+ lists the actual options supplied to a foreign data wrapper already. >>>> >>>> Checked, but the options doesn't appear (the column exists, but is empty). >>> >>> Well, that just means that you didn't specify any options when you ran >>> CREATE FOREIGN DATA WRAPPER. >>> >>> rhaas=# create foreign data wrapper dummy options (foo 'bar'); >>> CREATE FOREIGN DATA WRAPPER >>> rhaas=# \dew+ >>> List of foreign-data wrappers >>> Name | Owner | Handler | Validator | Access privileges | FDW Options >>> | Description >>> ---+---+-+---+---+-+- >>> dummy | rhaas | - | - | | (foo 'bar') | >>> (1 row) >>> >>> I'm not sure we're talking about the same thing, though. >>> >> >> No. I thought 'options' were the parameters when you create a fdw (example: >> host, port, file, etc). > > Each FDW can make its own decisions about which options it wants to > support - the core server support doesn't know anything about how the > data will be used. You can set options on the FDW level, the server > level, the foreign table level, and maybe a few other places. > Normally I would expect things like host and port to be set on the > server level, rather than the foreign data wrapper level. > Gotcha. Thanks Robert! I must report to the fdw creator. -- -- Emanuel Calvo Helpame.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] [Feature Request] \dx show "options"
2011/11/10 Robert Haas : > On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo wrote: >>> \dew+ lists the actual options supplied to a foreign data wrapper already. >> >> Checked, but the options doesn't appear (the column exists, but is empty). > > Well, that just means that you didn't specify any options when you ran > CREATE FOREIGN DATA WRAPPER. > > rhaas=# create foreign data wrapper dummy options (foo 'bar'); > CREATE FOREIGN DATA WRAPPER > rhaas=# \dew+ > List of foreign-data wrappers > Name | Owner | Handler | Validator | Access privileges | FDW Options > | Description > ---+---+-+---+---+-+- > dummy | rhaas | - | - | | (foo 'bar') | > (1 row) > > I'm not sure we're talking about the same thing, though. > No. I thought 'options' were the parameters when you create a fdw (example: host, port, file, etc). -- -- Emanuel Calvo Helpame.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] [Feature Request] \dx show "options"
2011/11/9 Robert Haas :
> On Wed, Nov 9, 2011 at 7:57 AM, Emanuel Calvo wrote:
>> I was thinking that could be great to add a column in \dx showing the
>> available
>> options for each foreign data wrapper.
>>
>> Seems reasonable?
>
> \dx doesn't list foreign data wrappers.
>
I was confused, forget it.
> \dew+ lists the actual options supplied to a foreign data wrapper already.
>
Checked, but the options doesn't appear (the column exists, but is empty).
postgres=# \dew+
List of foreign-data wrappers
Name| Owner | Handler | Validator |
Access privileges | Options
---+--+---+-+---+-
file_fdw | postgres | file_fdw_handler | file_fdw_validator |
|
mysql_fdw | postgres | mysql_fdw_handler | mysql_fdw_validator |
|
(2 rows)
--
--
Emanuel Calvo
Helpame.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] [Feature Request] \dx show "options"
2011/11/9 Emanuel Calvo : > Hi guys, > > I was thinking that could be great to add a column in \dx showing the > available > options for each foreign data wrapper. > > Seems reasonable? > Sorry the spam guys, it necesary the sme for index collations. They appear in "\d+ table" but with "\di+" it doesn't describe or show the collation. Maybe a column or in the description field could be enough. -- -- Emanuel Calvo Helpame.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [Feature Request] \dx show "options"
Hi guys, I was thinking that could be great to add a column in \dx showing the available options for each foreign data wrapper. Seems reasonable? -- -- Emanuel Calvo Helpame.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Feature request: new column is_paused in pg_stat_replication
Hi hackers, I don't know if it's possible or not, but could be interesting to add a column in pg_stat_replication to now if the standby is paused. It could be useful if somebody has several standby servers and use this function for some tasks. I know that there is an indirect way to calculate this in the primary, just comparing the other locations with the replay one. Any toughs? -- -- Emanuel Calvo Helpame.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_basebackup
Hi all, I'm seeing the results of pg_basebackup and I saw postmaster.opts. Is not necessary, although is inoffensive. But has the name of the original cluster name inside. If it's only keep for information purposes, maybe backup_label could be the right place. Is just an idea. Thougths? -- -- Emanuel Calvo Helpame.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] uuid contrib don't compile in OpenSolaris
>> problem is that PostgreSQL uses ossp UUID which is not integrated in >> OpenSolaris. Solaris has own uuid implementation which seems to me similar >> but not same. Try man uuid_generate or less /usr/uuid/uuid.h >> > > That's really interesting. I'll try this. > >> It should be easy to port it but it needs a time :(. >> >> Zdenek >> I found that the same problem cames from 8.3.4 http://archives.postgresql.org/pgsql-general/2008-10/msg01234.php But i found too, that seems to be a bug in x86 platforms for uuid_generator. I tryed to run uuidgen, but throws a lib.so.1 absence. Seems that the problem comes more dephtly. -- Emanuel Calvo Franco Database consultant at: www.siu.edu.ar www.emanuelcalvofranco.com.ar -- 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] uuid contrib don't compile in OpenSolaris
> problem is that PostgreSQL uses ossp UUID which is not integrated in > OpenSolaris. Solaris has own uuid implementation which seems to me similar > but not same. Try man uuid_generate or less /usr/uuid/uuid.h > That's really interesting. I'll try this. > It should be easy to port it but it needs a time :(. > > Zdenek > Oh! thanks Zdenek! I could try a workaround on this, i you guys could help let me know. -- Emanuel Calvo Franco Database consultant at: www.siu.edu.ar www.emanuelcalvofranco.com.ar -- 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] uuid contrib don't compile in OpenSolaris
>> Hi all, >> >> I have some issues to compile uuid contrib of 8.4 version. >> >> Touching something i see that the gmake don't find uuid.h. >> (pfexec gmake -d) >> Touching more, i add uuid.h into the uuid directory and i had a >> error message: missing separator. > > Did you use gmake the second time? What was the exact make and compiler > error message? > Every time I execute the gmake, the error is the same (uuid.h not found). WHen i copy uuid.h in the current dir of uuid contrib, the error changes to missing separator. As I say, looking in the web i found that maybe is a bad character (a hidden tab or something like this). This occurs only in opensolaris 200906 (i didn't test on previous versions). -- Emanuel Calvo Franco www.emanuelcalvofranco.com.ar ArPug.com.ar / aosug.com.ar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] uuid contrib don't compile in OpenSolaris
Hi all,
I have some issues to compile uuid contrib of 8.4 version.
Touching something i see that the gmake don't find uuid.h.
(pfexec gmake -d)
Touching more, i add uuid.h into the uuid directory and i had a
error message: missing separator.
So i google a little and i find something:
http://www.cygwin.com/faq/faq.programming.html#faq.programming.make-spaces
I read the source and it explain that some issues were fixed into
Debian, but other
platforms didn't tested yet. If this is really, we are using 8.4
final, and it don't
sounds consistent at all.
BTW, somebody patched this ? If not, i will continue my workaround on this and
try to propose something to fix it.
--
Emanuel Calvo Franco
www.emanuelcalvofranco.com.ar
ArPug.com.ar / aosug.com.ar
--
Emanuel Calvo Franco
www.emanuelcalvofranco.com.ar
ArPug.com.ar / aosug.com.ar
--
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] PostgreSQL installation
> I am from Cambodia. I want to use PostgreSQL. But I am poor of knowledge to
> install could you please help me give some guide to install PostgreSQL on
> Solaris 10,
(+ to pgsql-general)
Try to use the general list for these cases, you could obtain better
results ;)
The documentation for Solaris are in the site #1, you will find since
installation until complex trace rutines.
Enjoy it!
#1[http://www.sun.com/software/products/postgresql/index.jsp]
Regards,
--
Emanuel Calvo Franco
ArPUG [www.arpug.com.ar] / AOSUG Member
www.emanuelcalvofranco.com.ar
--
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] problem inserting in GIN index
2009/3/10 Teodor Sigaev : >> Apparently there's a crash involved ... > > Are other indexes on that table broken? ( Just count(*) with only index scan > enabled ) > -- > Teodor Sigaev E-mail: teo...@sigaev.ru > WWW: http://www.sigaev.ru/ > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > Yes, there are some btree indexes broken. Alvaro asked him if the option fsync is off. -- Emanuel Calvo Franco Sumate al ARPUG ! (www.postgres-arg.org - www.arpug.com.ar) ArPUG / AOSUG Member Postgresql Support & Admin -- 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] problem inserting in GIN index
2009/3/9 Alvaro Herrera : > Tom Lane wrote: >> Alvaro Herrera writes: >> > A guy just reported on pgsql-es-ayuda that he's getting >> > ERROR: item pointer (543108,2) already exists >> Test case? > > Apparently there's a crash involved ... > I asked to Gabriel. The exactly version is 8.3.6. He just deleted the indexes :( > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Emanuel Calvo Franco Sumate al ARPUG ! (www.postgres-arg.org - www.arpug.com.ar) ArPUG / AOSUG Member Postgresql Support & Admin -- 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] solaris libpq threaded build fails
2009/1/12 Bruce Momjian : > > I supposed Solaris 2.5.1 (release 1996) is just too old to add > threading, and this code has been unchanged for years. > > --- > > Andrew Chernow wrote: >> for anyone interested >> >> Solaris 2.5.1 with --enable-thread-safety >> >> configure:25848: gcc -o conftest -O2 -Wall -Wmissing-prototypes >> -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels >> -fno-strict-aliasing -fwrapv -pthreads -pthreads -D_REENTRANT >> -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DIN_CONFIGURE -lgcc_s >> -lvsnprintf conftest.c -lz -lposix4 -lsocket -ldl -lm -lpthread >> -lpthread>&5 >> In file included from conftest.c:129: >> ./src/test/thread/thread_test.c: In function `main': >> ./src/test/thread/thread_test.c:179: warning: implicit declaration of >> function `mkstemp' >> ./src/test/thread/thread_test.c:188: warning: implicit declaration of >> function `gethostname' >> Undefined first referenced >> symbol in file >> gethostbyname /var/tmp//ccclix3s.o (symbol >> belongs to implicit dependency /usr/lib/libnsl.so.1) >> ld: fatal: Symbol referencing errors. No output written to conftest >> collect2: ld returned 1 exit status >> configure:25851: $? = 1 >> configure: program exited with status 1 >> configure: failed program was: >> >> so far: hpux 10.20, solaris 2.5.1 and cygwin builds all fail when thread >> safe is enable. >> Sun garantee 10 years of appilcation compatibility, now we are in 11 version. thread-safety is the only option that fails? >> -- >> Andrew Chernow >> eSilo, LLC >> every bit counts >> http://www.esilo.com/ >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Emanuel Calvo Franco ArPUG / AOSUG Member Postgresql Support & Admin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FAQ_Solaris 1.28 to spanish
This file is for add to pgsql-docs, is the translation of the FAQ_solaris. I have new things to add, specially for Open Solaris plattaform specifications. I can write a new FAQ or just concatenate to this the other features of OSolaris? Reggards, -- Emanuel Calvo Franco Syscope Postgresql DBA BaPUG Member FAQ_Solaris_spanish 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
