Re: [HACKERS] Parallel pg_restore versus old dump files

2010-06-23 Thread Magnus Hagander
On Wed, Jun 23, 2010 at 03:26, Tom Lane t...@sss.pgh.pa.us wrote:
 Andrew Dunstan and...@dunslane.net writes:
 4. Is there any value in back-porting the Windows FSEEKO support into
 8.3 and 8.2?  Arguably, not writing the data offsets is a performance
 bug.  However a back-port won't do anything for people who are dumping
 with less than the latest minor release of pg_dump, so doing this might
 be largely wasted effort.

 I doubt it's worth it, but I could be persuaded otherwise.

 I'm leaning in that direction too.  Anybody who's doing a version
 upgrade really ought to be using the newer pg_dump version anyway ...

+1 on not backpatching that stuff - it's build system related, so it's
kind of fragile on the windows side :-)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Parallel pg_restore versus old dump files

2010-06-23 Thread Greg Stark
On Wed, Jun 23, 2010 at 2:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Uh, that doesn't fix anything: if you can't seek, a TOC at the end of
 the file is useless.  And the cases where the writer can't seek are
 likely to be identically the ones where the reader can't seek, viz
 pg_dump piped to pg_restore (perhaps with some other programs between).

That seems like a tenuous leap. A typical reason for the pipe is to
transfer it to a different machine and that only has to be done once.

But I'm not convinced it's such a great idea either for the reason I
described -- It makes the case where pg_restore has to read through
the whole archive that much harder to explain to users. So I'm not
really going to argue for it too strongly. It's also a fair amount of
extra complexity for not much gain. We would still need the fallback
code anyways.


-- 
greg

-- 
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] testing plpython3u on 9.0beta2

2010-06-23 Thread Robert Haas
On Tue, Jun 22, 2010 at 10:41 PM, Chris rfu...@gmail.com wrote:
 I received two errors (described below) in installing 9.0beta2 on Kubuntu
 10.04 , RhodiumToad on IRC recommended I post them here.
 I did not have a 2.x or 3.x python dev installed, but I was really only
 interested in python3 via plython3u.
 So...
 sudo apt-get install python3-all-dev
 Configure works fine...
 ./configure --with-pgport=5433 --with-python --with-ossp-uuid --with-libxml
 --with-libxslt --with-perl
 make fails while trying to build plpython, Cannot find python.h i
 believe(I sadly did not save the text of the error and have since
 continued onward.  But it was not finding a file while building plpython.  I
 believe I would have to uninstall a few things to reproduce.)
 So I tried installing the 2.x dev.  After running sudo apt-get install
 python-all-dev then make;make check;sudo make install, it all worke fine.
 However,  when issuing a createlang plpython3u template1, I get
 createlang: language installation failed: ERROR:  could not access file
 $libdir/plpython3: No such file or directory.  But if I createlang
 plpython2u template1 first, then it will allow createlang plpython3u
 template1.
 Am I doing something incorrect, or...?
 (As an aside, functions created with LANGUAGE plpython3u appear to work.)

I can reproduce this, here.  The problem seems to be that plpython
only build either plpython2.so or plython3.so, but both languages
expect a call handler called plython_call_handler.  So once we load
the shared library for one language, the other language just grabs the
same call handler.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

2010-06-23 Thread Robert Haas
On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
 Today, I tried to cancel the change of a tablespace for a table (ALTER
 TABLE ... SET TABLESPACE). I got the Cancel request sent but the query
 continued and finally succeed. It was a big issue for my customer, and I
 wanted to look more into that issue. So, I got a look at the source code
 and found we didn't check for interrupts in this part of the code. I
 added them, and it seems to work as I wanted.

 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.

 Not sure we really want that change, and it don't feel like a bug to me.
 Should I add it to to the next commitfest?

Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
ought to be OK (though I haven't tested), but copydir() is in
src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
might cause problems.

I think that whatever portion of this we end up applying should be back-patched.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Explicit psqlrc

2010-06-23 Thread gabrielle
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas robertmh...@gmail.com wrote:
 Well, that might be a good idea, too, but my expectation is that:

 psql -f one -f two -f three

 ought to behave in a manner fairly similar to:

 cat one two three  all
 psql -f all

 and it sounds like with this patch that's far from being the case.

Correct.  Each is handled individually.

Should I continue to check on ON_ERROR_ROLLBACK results, or bounce
this back to the author?

gabrielle

-- 
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] Explicit psqlrc

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle gor...@gmail.com wrote:
 On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas robertmh...@gmail.com wrote:
 Well, that might be a good idea, too, but my expectation is that:

 psql -f one -f two -f three

 ought to behave in a manner fairly similar to:

 cat one two three  all
 psql -f all

 and it sounds like with this patch that's far from being the case.

 Correct.  Each is handled individually.

 Should I continue to check on ON_ERROR_ROLLBACK results, or bounce
 this back to the author?

It doesn't hurt to continue to review and find other problems so that
the author can try to fix them all at once, but it certainly seems
clear that it's not ready to commit at this point, so it definitely
needs to go back to the author for a rework.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] testing plpython3u on 9.0beta2

2010-06-23 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 I can reproduce this, here.  The problem seems to be that plpython
 only build either plpython2.so or plython3.so, but both languages
 expect a call handler called plython_call_handler.  So once we load
 the shared library for one language, the other language just grabs the
 same call handler.

We had better fix that --- I can definitely foresee installations
wanting to use both plpython2 and plpython3.  This'd require a change in
the default contents of pg_pltemplate, though.  Does it seem important
enough to bump catversion for?

regards, tom lane

-- 
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] testing plpython3u on 9.0beta2

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 I can reproduce this, here.  The problem seems to be that plpython
 only build either plpython2.so or plython3.so, but both languages
 expect a call handler called plython_call_handler.  So once we load
 the shared library for one language, the other language just grabs the
 same call handler.

 We had better fix that --- I can definitely foresee installations
 wanting to use both plpython2 and plpython3.  This'd require a change in
 the default contents of pg_pltemplate, though.  Does it seem important
 enough to bump catversion for?

Yeah, I think so.  As for using both plpython2 and plpython3, it looks
to me like right now you can only use one or the other.  I think if
you somehow manage to install both, you're really just getting the
same one twice (I have not tested this, however).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] access method: are disk pages mandatory?

2010-06-23 Thread Leonardo F
in bufpage.h:

all blocks written out by an access method must be disk pages

but in 
http://www.postgresql.org/docs/8.4/static/storage-page-layout.html

Actually, index access methods need not use this page format. All the 
existing index methods do use this basic format, but the data kept on
index metapages usually doesn't follow the item layout rules.

I'm not getting it: am I supposed to use the disk page format when
writing an index access method, or it's just a good practice because
it makes the handling easier? Given the docs it looks recommended,
but the comment on the code sounds more mandatory.




-- 
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

2010-06-23 Thread Hitoshi Harada
2010/6/18 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:

 Jaime Casanova ja...@2ndquadrant.com wrote:

 This one, doesn't apply to head anymore... please update

 Thank you for reviewing my patch!

 I attached an updated patch set for partitioning syntax.

Isn't this linked from the RF web app??

Regards,

-- 
Hitoshi Harada

-- 
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] access method: are disk pages mandatory?

2010-06-23 Thread Heikki Linnakangas

On 23/06/10 18:17, Leonardo F wrote:

in bufpage.h:

all blocks written out by an access method must be disk pages

but in
http://www.postgresql.org/docs/8.4/static/storage-page-layout.html

Actually, index access methods need not use this page format. All the
existing index methods do use this basic format, but the data kept on
index metapages usually doesn't follow the item layout rules.

I'm not getting it: am I supposed to use the disk page format when
writing an index access method, or it's just a good practice because
it makes the handling easier? Given the docs it looks recommended,
but the comment on the code sounds more mandatory.


It's recommened because it makes life easier. Even if you don't use the 
normal page format, I think you need to have the LSN at the beginning of 
the page. The rest is up to you.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Partitioning syntax

2010-06-23 Thread Kevin Grittner
Hitoshi Harada umi.tan...@gmail.com wrote: 
 2010/6/18 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
 
 I attached an updated patch set for partitioning syntax.
 
 Isn't this linked from the RF web app??
 
It should have been.  Neither the reviewer nor the author updated
the CF web page (as they should have done).  I've just made the
entries to bring the patch it up to date in the web app.
 
I apologize for not picking up on the emails earlier.
 
-Kevin

-- 
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] dividing money by money

2010-06-23 Thread Kevin Grittner
Andy Balholm a...@balholm.com wrote:
 On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
 
 The only issue is with the general guideline to make the new code
 blend in with existing code:
 
 I deleted the excess comments and moved some lines around. Here it
 is with the changes.
 
I ran pgindent to standardize the white space.  (No changes of
substance.)  Patch attached.
 
I'll mark it Ready for Committer.
 
Thanks, Andy!
 
Note to committer: I'm not set up to generate docs, so I just
eyeballed the sgml.
 
-Kevin



dividing-money-2.diff
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] Partitioning syntax

2010-06-23 Thread Jaime Casanova
On Wed, Jun 23, 2010 at 10:41 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:

 It should have been.  Neither the reviewer nor the author updated
 the CF web page (as they should have done).  I've just made the
 entries to bring the patch it up to date in the web app.


Yeah! sorry i got bussy 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] access method: are disk pages mandatory?

2010-06-23 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 On 23/06/10 18:17, Leonardo F wrote:
 I'm not getting it: am I supposed to use the disk page format when
 writing an index access method, or it's just a good practice because
 it makes the handling easier? Given the docs it looks recommended,
 but the comment on the code sounds more mandatory.

 It's recommened because it makes life easier. Even if you don't use the 
 normal page format, I think you need to have the LSN at the beginning of 
 the page. The rest is up to you.

The bufpage.h comment is ancient and might not be 100% gospel anymore.
However, I believe the buffer manager does assume that any page in
shared buffers has a standard page header including LSN.  It definitely
assumes there's an LSN, and I think we have validity checks on the other
page header fields somewhere inside ReadBuffer.  You don't however need
to use the item-and-item-pointer-array structure if it's not useful to
you.

regards, tom lane

-- 
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] [BUGS] Server crash while trying to read expression using pg_get_expr()

2010-06-23 Thread Robert Haas
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
 On 15/06/10 10:31, Heikki Linnakangas wrote:

 You could avoid changing the meaning of fn_expr by putting the check in
 the parse analysis phase, into transformFuncCall(). That would feel
 safer at least for back-branches.

 Here's a patch using that approach.

 I grepped through PostgreSQL and pgadmin source code to find the system
 columns where valid node-strings are stored:

 pg_index.indexprs
 pg_index.indprep
 pg_attrdef.adbin
 pg_proc.proargdefaults
 pg_constraint.conbin

 Am I missing anything?

I think that pg_type.typdefaultbin is used by pg_dump.
pg_rewrite.ev_qual, pg_rewrite.ev_action, pg_trigger.tgqual also
contain nodeToString() output but I didn't have any luck using them
with pg_get_expr() so maybe they don't need to be included.

The only other thing I notice is that, obviously, the FIXME comment
needs to be FIXMEd before commit.

I'd still be in favor of inserting at least some basic error checks
into readfuncs.c, though just in HEAD.  The restrictions implemented
here seem adequate to prevent a security vulnerability, but superusers
can still invoke those functions manually, and while superusers can
clearly crash the system in any number of ways, that doesn't seem (to
me) like an adequate justification for ignoring the return value of
strtok().  YMMV, of course.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] ECPG FETCH readahead

2010-06-23 Thread Bruce Momjian
Boszormenyi Zoltan wrote:
 Hi,
 
 we improved ECPG quite a lot in 9.0 because we worked and
 still working with an Informix to PostgreSQL migration project.
 
 We came across a pretty big performance problem that can be seen in
 every naive application that uses only FETCH 1, FETCH RELATIVE
 or FETCH ABSOLUTE. These are almost the only FETCH variations
 usable in Informix, i.e. it doesn't have the grammar for fetching N rows
 at once. Instead, the Client SDK libraries do caching themselves
 behind the scenes to reduce network turnaround time.

I assume our ecpg version supports 1 fetch values, even in Informix
mode.  Does it make sense to add lots of code to our ecpg then?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + None of us is going to be here forever. +

-- 
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] Cannot cancel the change of a tablespace

2010-06-23 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.

 Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
 ought to be OK (though I haven't tested), but copydir() is in
 src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
 might cause problems.

copydir.c is already backend-specific thanks to all the ereport calls.
If we ever tried to make it usable in frontend code, we could easily
deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the
error management would be far more painful.

regards, tom lane

-- 
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] TCP keepalive support for libpq

2010-06-23 Thread Tom Lane
Fujii Masao masao.fu...@gmail.com writes:
 On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas robertmh...@gmail.com wrote:
 OK, here's a new version with several fewer bugs.

 Since valid values for keepalives parameter are 0 and 1, its field size should
 be 1 rather than 10.

Right ... although maybe it should be considered a boolean and not an
int at all?

 In this case, you can check the value of keepalives parameter by seeing
 conn-keepalives[0] instead of using strtol() in useKeepalives().

I disagree with that idea, though.  The field size has nothing to do
with most of the possible sources of the variable's value ...

regards, tom lane

-- 
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] TCP keepalive support for libpq

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 4:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Fujii Masao masao.fu...@gmail.com writes:
 On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas robertmh...@gmail.com wrote:
 OK, here's a new version with several fewer bugs.

 Since valid values for keepalives parameter are 0 and 1, its field size 
 should
 be 1 rather than 10.

 Right ... although maybe it should be considered a boolean and not an
 int at all?

Well, really, all libpq parameters are just strings, at this level.
The dispsize is just a hint for, I guess, things like PGadmin; it's
not actually used by libpq.

 In this case, you can check the value of keepalives parameter by seeing
 conn-keepalives[0] instead of using strtol() in useKeepalives().

 I disagree with that idea, though.  The field size has nothing to do
 with most of the possible sources of the variable's value ...

That is my thought also.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Cannot cancel the change of a tablespace

2010-06-23 Thread Guillaume Lelarge
Le 23/06/2010 22:54, Tom Lane a écrit :
 Robert Haas robertmh...@gmail.com writes:
 On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
 guilla...@lelarge.info wrote:
 I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
 copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
 SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.
 
 Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it
 ought to be OK (though I haven't tested), but copydir() is in
 src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there
 might cause problems.
 
 copydir.c is already backend-specific thanks to all the ereport calls.
 If we ever tried to make it usable in frontend code, we could easily
 deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the
 error management would be far more painful.
 

I'm not sure I get it right. Do I need to do something on the patch so
that it can get commited?


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.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] extensible enum types

2010-06-23 Thread Bruce Momjian
Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
  Robert Haas wrote:
  I like the idea of being able to modify enums on the fly, but I'm
  skeptical of an implementation that won't always work.  Maybe it's
  still better than what we have now, but it seems grotty.
 
  I'd be perfectly happy to hear a reasonable alternative.
 
 Insert a sort order column into pg_enum, and rearrange the values in
 that whenever the user wants to add a new value in a particular place.
 You give up cheap comparisons in exchange for flexibility.  I think lots
 of people would accept that tradeoff, especially if they could make it
 per-datatype.
 
 One point here is that you'd have to restrict the rearrangements so that
 the relative sort order of existing values never changes, else you break
 (for example) indexes on columns of that type.

Sorry to be commenting late, but don't most people want to add to the
end or beginning of the enum list, rather than in the middle, and can't
we support that already?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + None of us is going to be here forever. +

-- 
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] extensible enum types

2010-06-23 Thread Tom Lane
Bruce Momjian br...@momjian.us writes:
 Sorry to be commenting late, but don't most people want to add to the
 end or beginning of the enum list, rather than in the middle, and can't
 we support that already?

We could allow adding a value, but we couldn't guarantee where it would
appear in the type's sort ordering.  Depending on the current OID
counter it would usually show up either at the end or the beginning.
I think the general feeling is that this is too implementation-dependent
to be acceptable.

regards, tom lane

-- 
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] extensible enum types

2010-06-23 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Sorry to be commenting late, but don't most people want to add to the
  end or beginning of the enum list, rather than in the middle, and can't
  we support that already?
 
 We could allow adding a value, but we couldn't guarantee where it would
 appear in the type's sort ordering.  Depending on the current OID
 counter it would usually show up either at the end or the beginning.
 I think the general feeling is that this is too implementation-dependent
 to be acceptable.

Well, we don't need the enum value to map into the entire oid range. 
Can't we just add one to the top-most value and see if there is a
conflict?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + None of us is going to be here forever. +

-- 
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] extensible enum types

2010-06-23 Thread Tom Lane
Bruce Momjian br...@momjian.us writes:
 Well, we don't need the enum value to map into the entire oid range. 
 Can't we just add one to the top-most value and see if there is a
 conflict?

If you don't use the OID counter to generate the new value, you're going
to have problems with race conditions.  There's also that small chance
that there is no free value before 2^32.

The bottom line here is not wanting a feature that usually works but
fails once in awhile on the basis of conditions the user can't control.

regards, tom lane

-- 
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] extensible enum types

2010-06-23 Thread Andrew Dunstan



Tom Lane wrote:

Bruce Momjian br...@momjian.us writes:
  
Well, we don't need the enum value to map into the entire oid range. 
Can't we just add one to the top-most value and see if there is a

conflict?



If you don't use the OID counter to generate the new value, you're going
to have problems with race conditions.  There's also that small chance
that there is no free value before 2^32.

The bottom line here is not wanting a feature that usually works but
fails once in awhile on the basis of conditions the user can't control.

  


Yeah, what I'm now hoping to be able to do, following good suggestions 
from Tom, is to provide a way to get virtually no degradation in bulk 
comparison performance in the common case where any additions have been 
made at the end of the list with no oid wraparound, and acceptable 
performance otherwise, but provide for an ability to add new values at 
arbitrary places in the ordering, with no limit.


If we can do that why would we want less?

cheers

andrew

--
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] Explicit psqlrc

2010-06-23 Thread Mark Wong
On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:

 On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
 On Mon, Jun 21, 2010 at 7:51 PM, gabrielle gor...@gmail.com wrote:
 On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
 How does it play with ON_ERROR_STOP/ROLLBACK?
 
 With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
 stops processing the file that contains the error, and then continues
 to process any remaining files.
 
 That would be undesirable.
 
 I'm still investigating ON_ERROR_ROLLBACK.  I need to tinker with it
 some more before I say anything concrete.
 
 On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
 Also, how does it play with --single-transaction.
 That was buried in our original report :) BEGIN-COMMIT statements
 within the files cause warnings when the command is wrapped in a
 transaction with the -1 switch (as specified in the patch submission)
 
 To expand upon that a bit:  when psql encounters a file that contains
 a BEGIN statement, you get the expected WARNING: there is already a
 transaction in progress message.  The COMMIT at the end of that file
 (assuming the user doesn't forget it) generates a COMMIT.  Commands
 after that commit, or in any remaining files to be processed, are
 dealt with according to the user's autocommit settings:
 - if autocommit is ON, statements in the remaining files are processed
  committed;  the implicit COMMIT at the end of the whole thing then
 generates a WARNING: there is no transaction in progress message
 - if autocommit is OFF, statements in the remaining files generate
 ERROR:  current transaction is aborted, commands ignored until end of
 transaction block messages.
 
 This is the existing behaviour.
 
 So none of the above sounds like desired behavior to me...  is that just me?
 
 Single transaction needs some help, but that's not the fault of this
 patch.

I took a closer look at what was going on and what it would take to meet some 
of these expectations.  In main() the patch adds BEGIN and COMMIT statements 
outside the call to process_file() in src/bin/psql/command.c.  Here lies the 
previous logic for handling single transaction.  Since it remains, it appears 
that BEGIN can be issued twice before any statements are executed if the single 
transaction switch is used.  Plus there are other a couple of places that call 
this particular process_file() function, but I think those are straightforward 
cases to deal with.

Regards,
Mark
-- 
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] TCP keepalive support for libpq

2010-06-23 Thread Robert Haas
On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander mag...@hagander.net wrote:
 I looked around quickly earlier when we chatted about this, and I
 think I found an API call to change them for a socket as well - but a
 Windows specific one, not the ones you'd find on Unix...

Magnus - or anyone who knows Windows -

Now that I've committed this patch, any chance you want to add a few
lines of code to make this work on Windows also?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
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] Explicit psqlrc

2010-06-23 Thread Mark Wong
On Jun 23, 2010, at 5:36 PM, Mark Wong wrote:

 On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
 
 On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
 On Mon, Jun 21, 2010 at 7:51 PM, gabrielle gor...@gmail.com wrote:
 On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
 How does it play with ON_ERROR_STOP/ROLLBACK?
 
 With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
 stops processing the file that contains the error, and then continues
 to process any remaining files.
 
 That would be undesirable.
 
 I'm still investigating ON_ERROR_ROLLBACK.  I need to tinker with it
 some more before I say anything concrete.
 
 On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
 Also, how does it play with --single-transaction.
 That was buried in our original report :) BEGIN-COMMIT statements
 within the files cause warnings when the command is wrapped in a
 transaction with the -1 switch (as specified in the patch submission)
 
 To expand upon that a bit:  when psql encounters a file that contains
 a BEGIN statement, you get the expected WARNING: there is already a
 transaction in progress message.  The COMMIT at the end of that file
 (assuming the user doesn't forget it) generates a COMMIT.  Commands
 after that commit, or in any remaining files to be processed, are
 dealt with according to the user's autocommit settings:
 - if autocommit is ON, statements in the remaining files are processed
  committed;  the implicit COMMIT at the end of the whole thing then
 generates a WARNING: there is no transaction in progress message
 - if autocommit is OFF, statements in the remaining files generate
 ERROR:  current transaction is aborted, commands ignored until end of
 transaction block messages.
 
 This is the existing behaviour.
 
 So none of the above sounds like desired behavior to me...  is that just me?
 
 Single transaction needs some help, but that's not the fault of this
 patch.
 
 I took a closer look at what was going on and what it would take to meet some 
 of these expectations.  In main() the patch adds BEGIN and COMMIT statements 
 outside the call to process_file() in src/bin/psql/command.c.  Here lies the 
 previous logic for handling single transaction.  Since it remains, it appears 
 that BEGIN can be issued twice before any statements are executed if the 
 single transaction switch is used.  Plus there are other a couple of places 
 that call this particular process_file() function, but I think those are 
 straightforward cases to deal with.

Heh, not close enough.  I was wrong about that scenario.  I can see now that 
the single transaction flag is always set to false in process_file().  I think 
that turns the single transaction handling in process_file() into dead code 
with the patch like this.

Regards,
Mark


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers