Re: [HACKERS] Re: new patch of MERGE (merge_204) a question about duplicated ctid

2010-12-29 Thread Robert Haas
On Wed, Dec 29, 2010 at 9:45 PM, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote: I have no idea why it worked in the past, but the patch was never designed to work for UPSERT.  This has been discussed in the past and some people thought that that's not a huge deal. I think it's expected to

[HACKERS] does anyone still care about synchronous replication?

2010-12-29 Thread Robert Haas
We haven't seen any updated patches in a long, long time... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Avoiding rewrite in ALTER TABLE ALTER TYPE

2010-12-29 Thread Noah Misch
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote: On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com wrote: Perhaps. ?A few kooky rows is indeed common, but we're talking about a specific breed of kookiness: 99.9% of the rows have identical bits after an ALTER TYPE

Re: [HACKERS] Avoiding rewrite in ALTER TABLE ALTER TYPE

2010-12-29 Thread Robert Haas
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com wrote: On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote: On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com wrote: Perhaps. ?A few kooky rows is indeed common, but we're talking about a specific breed of

[HACKERS] future-proofing relkind tests, take two

2010-12-29 Thread Robert Haas
Here's another attempt to reduce the number of places in the code that need to be updated when adding a new relkind. It adds a few macros -- RELKIND_HAS_STORAGE(), RELKIND_HAS_SYSTEM_ATTS(), and RELKIND_HAS_SYSTEM_GENERATED_ATTNAMES() and uses them in place of more ad-hoc tests for the same

Re: [HACKERS] Re: new patch of MERGE (merge_204) a question about duplicated ctid

2010-12-29 Thread Greg Smith
Marko Tiikkaja wrote: I have no idea why it worked in the past, but the patch was never designed to work for UPSERT. This has been discussed in the past and some people thought that that's not a huge deal. It takes an excessively large lock when doing UPSERT, which means its performance

Re: [HACKERS] pg_dump --split patch

2010-12-29 Thread Joel Jacobson
2010/12/29 Dimitri Fontaine dimi...@2ndquadrant.fr Please have a look at getddl: https://github.com/dimitri/getddl Nice! Looks like a nifty tool. When I tried it, ./getddl.py -f -F /crypt/funcs -d glue, I got the error No such file or directory: 'sql/schemas.sql'. While the task of

<    1   2