Re: [HACKERS] recovery.conf location

a problem if we put a trigger file and the recovery.conf gets renamed to recovery.done, no? at least that would be a problem for the standbys that still need to be standbys -- Jaime Casanova         www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Version Numbering

On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark wrote: > On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova > wrote: >> Look at other DBMSes: >> Oracle: 8i, 9i, 10g, 11g >> Informix 9, 10, 11 >> MS SQL Server 7, 2000, 2005, 2008 >> >> note the lack of dotes (

Re: [HACKERS] Version Numbering

only in version 8 so Oracle should have more features... no that i follow that reasoning but... -- Jaime Casanova         www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://

Re: [HACKERS] Per-column collation, proof of concept

On Wed, Aug 18, 2010 at 11:29 AM, Peter Eisentraut wrote: > On tis, 2010-08-17 at 01:16 -0500, Jaime Casanova wrote: >> >> creating collations ...FATAL:  invalid byte sequence for encoding >> >> "UTF8": 0xe56c09 >> >> CONTEXT:  COPY

Re: [HACKERS] Per-column collation, proof of concept

On Mon, Aug 16, 2010 at 10:56 PM, Peter Eisentraut wrote: > On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote: > >> BTW, why the double quotes? > > Because the name contains upper case letters? > why everything seems so obvious once someone else state it? :) >>

Re: [HACKERS] Per-column collation, proof of concept

2010 at 11:32 AM, Peter Eisentraut wrote: > On mån, 2010-08-02 at 01:43 -0500, Jaime Casanova wrote: >> nowadays, CREATE DATABASE has a lc_collate clause. is the new collate >> clause similar as the lc_collate? >> i mean, is lc_collate what we will use as a default? >

[HACKERS] more personal copyrights

) there's something we can/need to do about it? I can make a list if anyone is interested showing what files are still copyrighted to something different to 'PostgreSQL Global Development Group' -- Jaime Casanova         www.2ndQuadrant.com Soporte y capacitación de PostgreSQL --

Re: [HACKERS] including backend ID in relpath of temp rels - updated patch

On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas wrote: > > Just "DROP TABLE > pg_temp_2.foo" or whatever and away you go. > wow! that's true... and certainly a bug... we shouldn't allow any session to drop other session's temp tables, or is there a reason for

Re: [HACKERS] Per-column collation, proof of concept

ate locale "es_EC.utf8"" (of course, that last part was me messing the things up, but it show we shouldn't be using a file locales.txt, i think) i can attach a collate to a domain but i can't see where are we storing that info (actually it says it's not collatable): --

Re: [HACKERS] including backend ID in relpath of temp rels - updated patch

On Sun, Jul 25, 2010 at 4:32 PM, Robert Haas wrote: > On Sun, Jul 25, 2010 at 2:37 AM, Jaime Casanova wrote: >> but i have a few questions, maybe is right what you did i only want to >> understand it: >> - you added this in include/storage/smgr.h, so why is safe to assume &

Re: [HACKERS] including backend ID in relpath of temp rels - updated patch

On Fri, Jul 23, 2010 at 10:05 AM, Jaime Casanova wrote: > On Thu, Jun 10, 2010 at 3:39 PM, Robert Haas wrote: >> >> >> I believe that this patch will clear away one major obstacle to >> implementing global temporary and unlogged tables: it enables us to be >> sur

Re: [HACKERS] including backend ID in relpath of temp rels - updated patch

ertised, pass regression tests, and all tests i could think of... haven't looked the code at much detail but seems ok, to me at least... -- Jaime Casanova         www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] bg worker: overview

y. Nothing else. > so, merging this with the autovacuum will drop our hopes of having a time based autovacuum? not that i'm working on that nor i was thinking on working on that... just asking to know what the implications are, and what the future improves could be if we go this route -- Jai

Re: [HACKERS] Partitioning syntax

sy with other things... i will make a complete review in next days... -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] Partitioning syntax

On Mon, Jan 18, 2010 at 3:55 AM, Takahiro Itagaki wrote: > > Robert Haas wrote: > >> A couple of preliminary comments on this: > > Thanks. > The attached is rebased on HEAD, with additional documentation. > This one, doesn't apply to head anymore... please update

Re: [HACKERS] nvarchar notation accepted?

On Mon, Jun 7, 2010 at 2:23 AM, Peter Eisentraut wrote: > > The N'' syntax is in the SQL standard, > I didn't know that, do you know what paragraph is it? i can't find it -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent v

Re: [HACKERS] nvarchar notation accepted?

On Thu, May 13, 2010 at 11:00 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Thu, May 13, 2010 at 10:52 PM, Tom Lane wrote: >>> Actually, the lexer translates N'foo' to NCHAR 'foo' and then the >>> grammar treats that just like CHAR '

Re: [HACKERS] List traffic

'm >> good with not changing things. > > Yeah, that's because I was responding to the suggestion that 5 of our > lists should be collapsed into 'general' as the One Uber-List. > i think not all should be collapsed but at least -novice, IMHO -- Jaime Casanova

Re: [HACKERS] Snapshot Materialized Views - GSoC

DML against MV, I expect that triggers should work too > no, if you don't propagate then you don't have a view of the tables the MV comes from... error if you'll not implement propagation now -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL --

Re: [HACKERS] New buildfarm client release

little later than planned, but as >     promised almost exactly one year ago). maybe i'm not understanding but this will be able to build specific branches so we can have some experimental code running in buildfarm? -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL

Re: [HACKERS] Performance problem in textanycat/anytextcat

ecision as $$ select random() * $1; $$ language sql immutable; create index idx on t1(f1(col1)); """ then, welcome to the club... there were various conversations on this same topic -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent

Re: [HACKERS] Performance problem in textanycat/anytextcat

On Sat, May 15, 2010 at 10:21 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Sat, May 15, 2010 at 10:16 PM, Tom Lane wrote: >>> Jaime Casanova writes: >>>> On Sat, May 15, 2010 at 8:51 PM, Tom Lane wrote: >>>> Is it reasonable to fix this now,

Re: [HACKERS] Performance problem in textanycat/anytextcat

On Sat, May 15, 2010 at 10:16 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Sat, May 15, 2010 at 8:51 PM, Tom Lane wrote: >>> Is it reasonable to fix this now, and if so should I bump catversion >>> or leave it alone?  My own preference is to fix it in

Re: [HACKERS] Performance problem in textanycat/anytextcat

excessive to me, IMHO -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] List traffic

e thread and "mark as read" everything else -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] nvarchar notation accepted?

On Thu, May 13, 2010 at 10:13 PM, Takahiro Itagaki wrote: > > Jaime Casanova wrote: > >> i migrate a ms sql server database to postgres and was trying some >> queries from the application to find if everything works right... >> when i was looking to those queries i fou

Re: [HACKERS] nvarchar notation accepted?

any effect on > encoding behavior.  I think this is something Tom Lockhart put in ten or > so years back, and never got as far as making it actually do anything > helpful. > so, the N'' syntax is fine and i don't need to hunt them as a migration step? -- Jaime Casanova

[HACKERS] nvarchar notation accepted?

s actually works, is that fine? i know, we can use E'' strings but N'' ones are no where documented, so can i rely on those or i have to change those strings? """ create table t1_nvarchar(col1 text); insert into t1_nvarchar values (N'texto'); "

Re: [HACKERS] Partitioning/inherited tables vs FKs

nside that trigger will look at the entire set of tables (as long as you don't use FROM ONLY) also could be useful to put an index (even a PK) on every child to ensure uniqueness and make the SELECT more efficient, and of course a check constraint in every child emulating a partition key

Re: [HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby

On Sat, May 1, 2010 at 7:22 AM, Simon Riggs wrote: > On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote: >> On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas >> wrote: >> > >> > How many of the tests in the regular regression suite do anything useful >&

Re: [HACKERS] failed assertion and panic in standby mode

On Fri, Apr 30, 2010 at 12:03 AM, Tom Lane wrote: > Jaime Casanova writes: >> i was trying recent HS and get this when trying to start the standby, > >> TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >= >> -NLocBuffer && (metabuffer)

Re: [HACKERS] COPY is not working

On Fri, Apr 30, 2010 at 1:13 AM, Takahiro Itagaki wrote: > > Jaime Casanova wrote: > >> ah! this is because COPY doesn't follow inherited tables... should it? > > Yes. You can use "COPY (SELECT * FROM a) TO " instead to copy all tuples. > > http://de

Re: [HACKERS] COPY is not working

On Fri, Apr 30, 2010 at 12:56 AM, Takahiro Itagaki wrote: > > Jaime Casanova wrote: > >> COPY is not working on latest HEAD? >> """ >> regression=# select * from a; >>  aa >> >>  32 >>  56 >> (2 rows) >> >>

Re: [HACKERS] COPY is not working

2010/4/30 Jaime Casanova : > Hi, > > COPY is not working on latest HEAD? > """ > regression=# select * from a; >  aa > >  32 >  56 > (2 rows) > > regression=# COPY a TO '/tmp/copy_test'; > COPY 0 > """ > ah!

[HACKERS] COPY is not working

Hi, COPY is not working on latest HEAD? """ regression=# select * from a; aa 32 56 (2 rows) regression=# COPY a TO '/tmp/copy_test'; COPY 0 """ -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistem

[HACKERS] failed assertion and panic in standby mode

1000C" from archive PANIC: btree_redo: unknown op code 208 CONTEXT: xlog redo UNKNOWN LOG: startup process (PID 9264) was terminated by signal 6: Aborted LOG: terminating any other active server processes """ -- Atentamente, Jaime Casanova Soporte y capacitació

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

we aren't able to use hash indexes on the slave so we can advice to disable those indexes there the only problem is that seems like we can't put "plantuner.forbid_index='a_hash_index'" on postgresql.conf ala auto_explain, that could make this better -- Atentamente

Re: [HACKERS] Discarding the resulting rows

e the query. >> >> I would use EXPLAIN ANALYZE SELECT ... > > There's some overhead to that, of course. > he could see the "actual time" in the very first row of the EXPLAIN ANALYZE... isn't that a value that is more close to what the OP is looking for? -- At

Re: [HACKERS] Discarding the resulting rows

ave a URL? > i guess he is refering to the plpgsql's PERFORM statement, which of course he can't use outside a plpgsql function... mmm... well, IIRC, in 9.0 he will be able to do DO $$ PERFORM * FROM tabla; $$ LANGUAGE plpgsql; but i think DO is not an EXPLAINing statement -- A

Re: [HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby

erything that we need to... maybe just a new set of tests? maybe i just should make the hs_* tests use regression's database tables intead of the ones it is using? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador C

Re: [HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby

On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova wrote: > On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova > wrote: >> On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova >> wrote: >>> >> >> i think "make standbycheck" needs a little more work,

[HACKERS] improve plpgsql's EXECUTE 'select into' message with a hint

Hi, while TFM says that we can use EXECUTE 'select ' INTO instead of the non implemented EXECUTE 'select ... into ', the message in plpgsql fails to say the same thing... seems like a HINT to me -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Ases

Re: [HACKERS] including PID or backend ID in relpath of temp rels

them is because somebody else might have 'em open, so it > mightn't be necessary for temp rels. > what happens if the backend crash and obviously doesn't remove the file associated with temp rels? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarr

Re: [HACKERS] shared_buffers documentation

or more... someone can confirm the lock contention theory? this should be noticeable at checkpoint time right? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Thoughts on pg_hba.conf rejection

as anything. > > Although on further reflection, part of me feels like it might be even > simpler and clearer to simply say: > > connection not authorized > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil

[HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby

On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova wrote: > On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova > wrote: >> > > i think "make standbycheck" needs a little more work, why it isn't > accesible from top of source dir? > what i want to do. 1) make st

Re: [HACKERS] testing hot standby

On Tue, Apr 13, 2010 at 11:06 AM, Heikki Linnakangas wrote: > Jaime Casanova wrote: >> >> i will read it on the morning and the thread where it is, something >> that seems strange to me is that the patch touch twophase.c and >> twophase.h, why? > > When you

[HACKERS] hash indexes and HS was:(Re: [HACKERS] testing hot standby)

On Mon, Apr 12, 2010 at 1:23 AM, Jaime Casanova wrote: > > another point, what happened with this: > http://archives.postgresql.org/message-id/1229549172.4793.105.ca...@ebony.2ndquadrant? > Obviously we still have the problem with hash indexes, and in that > thread Tom advice was j

Re: [HACKERS] testing hot standby

On Mon, Apr 12, 2010 at 8:32 PM, Fujii Masao wrote: > On Mon, Apr 12, 2010 at 11:27 PM, Jaime Casanova > wrote: >>> 1. start the primary >>> 2. pg_start_backup() >>> 3. copy $PGDATA from the primary to the standby >>> 4. pg_stop_backup(); >>>

Re: [HACKERS] testing hot standby

On Mon, Apr 12, 2010 at 9:27 AM, Jaime Casanova wrote: > On Mon, Apr 12, 2010 at 1:48 AM, Fujii Masao wrote: >> On Mon, Apr 12, 2010 at 3:29 PM, Jaime Casanova >> wrote: >>> On Mon, Apr 12, 2010 at 1:21 AM, Fujii Masao wrote: >>>> Didn't the standby

Re: [HACKERS] testing hot standby

On Mon, Apr 12, 2010 at 1:48 AM, Fujii Masao wrote: > On Mon, Apr 12, 2010 at 3:29 PM, Jaime Casanova > wrote: >> On Mon, Apr 12, 2010 at 1:21 AM, Fujii Masao wrote: >>> Didn't the standby >>> accept connections before executing pgbench? >>> >>

Re: [HACKERS] testing hot standby

erate_series(1, 100) as i After that, the standby start accepting connections -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [HACKERS] testing hot standby

On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova wrote: > > but, my main concern is why it was asking for > "00010006"? is this normal? is this standby's way of > saying i'm working but i have nothing to do? > when that happens after a standb

Re: [HACKERS] testing hot standby

On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova wrote: > Hi, > > i'm startint to try Hot Standby & Streaming Replication, so i started > a replication: > i think "make standbycheck" needs a little more work, why it isn't accesible from top of source dir? Fo

[HACKERS] testing hot standby

when that happens after a standby restart, is normal that i have to wait until the file is created before it can accept connections? sorry, if this questions sound very simple but i haven't following all the design details :) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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 maze of twisty mailing lists all the same

On Thu, Apr 8, 2010 at 3:09 PM, Joshua D. Drake wrote: > On Thu, 2010-04-08 at 15:06 -0400, Jaime Casanova wrote: >> > >> >> if we want specific topics, then remove -general, -novice, -admin > > This will likely never fly, see the archives. > well, -novice shu

Re: [HACKERS] A maze of twisty mailing lists all the same

threads >> since they're mostly on -general anyways. Those three categories cover >> pretty much all of -general. > > Maybe we should remove -general.  :-) > > if we want specific topics, then remove -general, -novice, -admin -- Atentamente, Jaime Casanova Soporte y capa

Re: [HACKERS] A maze of twisty mailing lists all the same

On Thu, Apr 8, 2010 at 1:11 AM, Greg Stark wrote: > > Likewise I don't think we should have pgsql-performance or pgsql-sql > or pgsql-novice -- any thread appropriate for any of these would be > better served by sending it to pgsql-general anyways (with the +1 -- Atentament

Re: [HACKERS] Thoughts on pg_hba.conf rejection

t;no pg_hba.conf entry" for "connection rejected" doesn't seem like a lot more and the change could be useful for a DBA understanding what happens -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +5938

Re: [HACKERS] Autonomous transaction

ned for this. > the only side effect i can think of is that you will use another connection slot (that's because dblink will stablish a new connection) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157

Re: [HACKERS] default privileges

On Sun, Apr 4, 2010 at 9:59 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane wrote: >>> Not sure if this is good enough or we need to provide some more-obvious >>> way of dealing with it. > >> it's strange that a R

Re: [HACKERS] "pg_stat_tmp/pgstat.stat": Stale NFS file handle

-- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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_stat_tmp/pgstat.stat": Stale NFS file handle

xt2 filesystem in an external hard drive, could be fs corruption? any ideas? anything i could do to fix this without dropping my 90Gb test env? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-

Re: [HACKERS] default privileges

to make REASSIGN OWNED first). we can let it as it is, but at least we can add a HINT for use DROP OWNED BY having execute REASSIGN OWNED first... or we can make what seems more reasonable, make the REVOKE clean the mess :) if you prefer the second way i can try to prepare a patch -- Atentamente,

Re: [HACKERS] \d commands in psql 9.0

On Sat, Apr 3, 2010 at 4:46 PM, Tom Lane wrote: > Jaime Casanova writes: >> are we requiring a space between the command and it's first parameter? > > Yes. > then, something is wrong because \ddp+ should be giving an error (because that command doesn't exist and \dd

[HACKERS] default privileges

e "simplified grant", i guess it's the first one... but i try REVOKE in all combinations and nothing works... maybe the \ddp needs to show more info? or we need a CASCADE clause in the DROP ROLE? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarr

[HACKERS] \d commands in psql 9.0

Hi, Seems like \dd and \ddp+ gives the same answer... The reason this is misleading is that \ddp is a command and i was trying to get extra info with \ddp+ (which doesn't exist) are we requiring a space between the command and it's first parameter? -- Atentamente, Jaime Casanova

Re: [HACKERS] enable_joinremoval

enough. >> >>> That is exactly what I replied, though nobody felt that was a great >>> answer. >> >> Who complained about that exactly?  It seems like a perfectly >> appropriate answer to me. > > Jaime Casanova. > i'm just finishing to read an 347

Re: [HACKERS] enable_joinremoval

On Mon, Mar 29, 2010 at 11:29 AM, Robert Haas wrote: > On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova > wrote: >> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera >> wrote: >>> >>> It seems that what's really needed is some debug output to be able to

Re: [HACKERS] enable_joinremoval

ng the tables in the explain analyze? it's possible but not ideal -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] plpgsql's case bug?

n all by itself. > well actually i get here when translating the plpgsql messages and found very strange a message like "case not found", and as a last argument (a weak one, i have to admit) i will say that the hint could be innecesary if we use the same message the spec is suggesting

Re: [HACKERS] plpgsql's case bug?

On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova wrote: > Hi, > [...] > > this is based on General Rules case 1 of chapter 13.6 (case statement) > but i don't think that behaviour is the meaning of that Rule. Even if > it is, the exception should be: "case not found f

[HACKERS] plpgsql's case bug?

. c) Otherwise, an exception condition is raised: case not found for case statement, and the execution of the is terminated immediately. """ comments? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel.

Re: [HACKERS] pq_setkeepalives* functions

ction, and now they can throw errors. > >> Is this the proper way to fix the issue?  Patch attached. > > AFAICS there is no issue, and the code is fine as-is. > ah! now i see this clearer... sorry for the noise -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Ase

[HACKERS] pq_setkeepalives* functions

ditional, doesn't seems to affect anything but for consistency with the other two :) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 Index: src/backend/libpq/pqcomm.c ==

Re: [HACKERS] disabling log_min_duration_statement from pg_dump?

On Mon, Mar 8, 2010 at 4:25 PM, Tom Lane wrote: > Jaime Casanova writes: >> can we add a parameter in pg_dump and pg_dumpall to disable >> log_min_duration_statement? > > export PGOPTIONS="-c log_min_duration_statement=-1" > ah! so, that is PGOPTIONS for

[HACKERS] disabling log_min_duration_statement from pg_dump?

Hi, Every often, i analyze logs to find most slow queries... and every time i found myself trying to ignore pg_dump's generated COPY commands which could be very expensive... can we add a parameter in pg_dump and pg_dumpall to disable log_min_duration_statement? -- Atentamente, Jaime Cas

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

it is a big problem IMHO. It results in lots of slow, > broken, insecure database designs. > So, if php dev doesn't have time to learn to do things right then we have to find time to learn to do things wrong? seems like a nosense argument to me -- Atentamente, Jaime Casanova Soport

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

, not the converse. > with that reasoning, then Galileo and Copernico should had faken their tests to adjust the results to most people expections about the earth being the center of the universe and our sun orbiting us -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Ase

Re: [HACKERS] Re: [COMMITTERS] pgsql: Instead of trying (and failing) to allow <> at the end of

On Wed, Mar 3, 2010 at 1:12 AM, Tom Lane wrote: > Jaime Casanova writes: >> On Wed, Mar 3, 2010 at 1:00 AM, Tom Lane wrote: >>> No, I intentionally didn't back-patch that.  The only benefit of the >>> change is throwing a useful error message for questionable s

Re: [HACKERS] Re: [COMMITTERS] pgsql: Instead of trying (and failing) to allow <> at the end of

On Wed, Mar 3, 2010 at 1:00 AM, Tom Lane wrote: > David Fetter writes: >> On Tue, Mar 02, 2010 at 11:02:54PM -0500, Jaime Casanova wrote: >>> On Tue, Mar 2, 2010 at 8:53 PM, Tom Lane wrote: >>>> Instead of trying (and failing) to allow <> at the end of a

Re: [HACKERS] function side effects

? > Seems like that would have to be the same as the last one > i guess the safer asumption is: treat it as MODIFIES SQL DATA -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hacke

Re: [HACKERS] function side effects

On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut wrote: > On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote: >> On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote: >> > >> > There may be some value in inventing a "has no side effects" marker, but

Re: [HACKERS] Anyone know if Alvaro is OK?

't insist on this but those of you that wanna give a try can read Matthew 24:3, 7, 8 and Luke 21:11 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Correcting Error message

ERROR:  type "varchar2" does not exist > it;s probably postgres plus (the enterprisedb fork), because varchar2 it's an oracle invention -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157

Re: [HACKERS] pgbouncer + psql 9.0a4

o one postgres hacker was surprised because i have read the entire postgres documentation -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] pgbouncer + psql 9.0a4

On Fri, Feb 26, 2010 at 11:26 AM, Garick Hamlin wrote: > > I imagine this is really mostly pgbouncer's problem yes it is, but you can workaround it using "ignore_startup_parameters" parameter in pgbouncer.ini http://pgbouncer.projects.postgresql.org/doc/config.html#toc4 -

Re: [HACKERS] Allow vacuumdb to only analyze

On Thu, Feb 25, 2010 at 5:09 PM, Bruce Momjian wrote: > > This is implemented in 9.0 from vacuumdb: > >          -Z, --analyze-only              only update optimizer hints > maybe just noise, but it's not better to say "optimizer statistics" instead of "optimi

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

so while i will try it (if anyone seems like he can takle it please go for it)... maybe we can add this to the TODO if seems acceptable? specially, i'd love to hear Tom's opinion on this one... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistema

Re: [HACKERS] Determining client_encoding from client locale

client encoding based on the client operating system encoding Currently client_encoding is set in postgresql.conf, which defaults to the server encoding. * Re: [GENERAL] invalid byte sequence ? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y des

Re: [HACKERS] function side effects

s parsing and all of its state (eg schema > search path) in order to discover anything. > i agree with that, as Alvaro suggested maybe a way to ask the server about the whole query is the way to go -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarr

Re: [HACKERS] synchronous commit in dump

On Tue, Feb 23, 2010 at 4:40 AM, Magnus Hagander wrote: > 2010/2/23 Jaime Casanova : >> Hi, >> >> it's safe to set synchrounous_commit to off in a pg_dump generated >> script? if yes, would this help to the performance of restore a >> database? > > I

Re: [HACKERS] function side effects

On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote: > > There may be some value in inventing a "has no side effects" marker, but > that should not be confused with IMMUTABLE/STABLE. > a READONLY function? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL As

Re: [HACKERS] function side effects

on could be... > At least it's never been in the past, and I'm sure you'd break some > applications if you made it so in the future. > i'm sure of that too, but in this case seems reasonable to do so -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Ase

[HACKERS] synchronous commit in dump

Hi, it's safe to set synchrounous_commit to off in a pg_dump generated script? if yes, would this help to the performance of restore a database? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 --

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

launching an scheduler but also for launching other tools (ie: pgbouncer, slon daemons, etc) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

On Mon, Feb 22, 2010 at 3:08 PM, Jaime Casanova wrote: > On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote: >> >> I still haven't seen a good reason for not using cron or Task Scheduler >> or other standard tools. >> > > - marketing? don't you hate wh

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

ery easy ;) the ability to have processes that start when postmaster starts and stop when postmaster stops is just one more way to be extensible without integrating every piece of code into core -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guaya

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

> ah! fair enough! -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

On Mon, Feb 22, 2010 at 1:18 PM, Heikki Linnakangas wrote: > Jaime Casanova wrote: > >> so, is this idea (having some user processes be "tied" to postmaster >> start/stop) going to somewhere? > > I've added this to the TODO list. Now we just need someone

<    1   2   3   4   5   6   7   8   9   >