Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg
On Fri, 20 Nov 2009, Magnus Hagander wrote: I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. Kris Jurka -- 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] Python 3.1 support
On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: Is there any precedent for the sort of behavior that you are implementing, that is, automatic sharing of variables between independent executions of the same source container? import foo # bar is a regular, def'd function. foo.bar() ... # even in another thread, doesn't matter.. foo.bar() In either call, foo.bar()'s globals() is the same dictionary object(the foo module's dictionary). A plpython3 function *is* a Python module. -- 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] Python 3.1 support
On fre, 2009-11-20 at 01:20 -0700, James Pye wrote: On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: Is there any precedent for the sort of behavior that you are implementing, that is, automatic sharing of variables between independent executions of the same source container? import foo # bar is a regular, def'd function. foo.bar() ... # even in another thread, doesn't matter.. foo.bar() In either call, foo.bar()'s globals() is the same dictionary object(the foo module's dictionary). That's not what I meant, because this is the same execution of the same source container, with threads explicitly started somewhere. You could do the same in a plpython function (in theory, at least). What I mean is more like, you execute the same source file twice in a row, and the global variables are saved for the second run. -- 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] enable-thread-safety defaults?
On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote: 2009/11/20 Peter Eisentraut pete...@gmx.net: On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote: Is there any actual reason why we are building without thread safety by default on most platforms? Consistent defaults on all platforms? So why do we have largefile enabled by default? And zlib? And readline? Let me be more verbose: I would assume that we want the configure defaults to be the same on all platforms. We fail by default, for example, if zlib and readline are not there, but you can turn them off explicitly. If we turn thread-safety on by default, we will/should fail if thread-safety is not supported, requiring the user to turn it off explicitly. If enough platforms don't support thread-safety, this could become annoying. I don't have a good overview over how many platforms would be affected, and I could in general support changing the default, but I'm just laying down one possible constraint. -- 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] Listen / Notify - what to do when the queue is full
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Note that we don't preserve notifications when the database restarts. But 2PC can cope with restarts. How would that fit together? The notifications are written to the state file at prepare. They can be recovered from there and written to the queue again at server start (see twophase_rmgr.c). Okay, but which of the backends would then leave its pointer at that place in the queue upon restart? This is also an issue for the non-restart case, what if you prepare the transaction in one backend and commit in the other? Joachim -- 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] Python 3.1 support
On Nov 20, 2009, at 1:26 AM, Peter Eisentraut wrote: because this is the same execution Hrm, not necessarily. foo could be imported by another, completely independent part of the program. foo is cached in sys.modules. bar() is executed and it's still the same globals(). shared. -- 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] Listen / Notify - what to do when the queue is full
Joachim Wieland wrote: On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Note that we don't preserve notifications when the database restarts. But 2PC can cope with restarts. How would that fit together? The notifications are written to the state file at prepare. They can be recovered from there and written to the queue again at server start (see twophase_rmgr.c). Okay, but which of the backends would then leave its pointer at that place in the queue upon restart? This is also an issue for the non-restart case, what if you prepare the transaction in one backend and commit in the other? The dummy procs that represent prepared transactions need to be treated as backends. Each prepared transaction needs a slot of its own in the backends array. -- 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] Python 3.1 support
Am 19.11.2009 18:01, schrieb James Pye: On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote: The other approach, which is what James Pye's new implementation proposes (as I understand it), is to convert PostgreSQL types into specially made Python objects, such as Postgres.types.record or Postgres.types.timestamp. Convert is not a good word choice. The Datum of the parameter is stored inside a new Python object(that only holds a Datum). So more like copied into Python memory, and associated with its respective type. Wrapped in a Python object? Yes wrapped is the term commonly used for that. And I must say I like it and I used plpy where I could. One cool thing about doing it this way, is that if you just pass parameters forward to a prepared statement, there's no type I/O overhead. Not a huge performance win for common cases, but if someone were passing larger arrays around, it could be quite beneficial. Exactly and you have all the meta information about the original postgres type. IIRC there were some thoughts of having something like that in a DBAPI interface as well (similar for example to cx_Oracle). Tino smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Listen / Notify - what to do when the queue is full
Joachim Wieland wrote: On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland j...@mcknight.de wrote: Given your example, what I am proposing now is to stop reading from the queue once we see a not-yet-committed notification but once the queue is full, read the uncommitted notifications, effectively copying them over into the backend's own memory... Once the transaction commits and sends a signal, we can process, send and discard the previously copied notifications. In the above example, at some point one, two or all three backends would see that the queue is full and everybody would read the uncommitted notifications of the other one, copy them into the own memory and space will be freed in the queue. Attached is the patch that implements the described modifications. That's still not enough if session 2 that issues the LISTEN wasn't previously subscribed to any channels. It will still miss the notification. -- 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] enable-thread-safety defaults?
Peter Eisentraut wrote: I don't have a good overview over how many platforms would be affected The anniversary of this thread is a few days early: http://archives.postgresql.org/message-id/492ea404.5080...@esilo.com -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.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] plperl and inline functions -- first draft
On Thu, Nov 19, 2009 at 05:04:22PM -0700, Joshua Tolley wrote:
The body of the function is ordinary Perl code. In fact, the PL/Perl
!glue code wraps it inside a Perl subroutine. Anonymous code blocks cannot
!return a value; PL/Perl functions created with CREATE FUNCTION must
always
!return a scalar value. You can return more complex structures (arrays,
!records, and sets) by returning a reference, as discussed below. Never
!return a list.
/para
The must always and Never return a list seem needlessly strong, not
very helpful, and slightly misleading. The key point is that the call is
made in a scalar context. The implications of that follow naturally.
I'd suggest:
...; PL/Perl functions created with CREATE FUNCTION are called in a
scalar context, so can't return a list. You can return more complex
structures (arrays, records, and sets) by returning a reference, as
discussed below.
That only mentions functions created with CREATE FUNCTION though.
Perhaps it needs to be generalized to cover DO as well.
+ Datum
+ plperl_inline_handler(PG_FUNCTION_ARGS)
+ {
+ desc.proname = Do Inline Block;
+ PG_TRY();
+ {
+
+ desc.reference = plperl_create_sub(DO Inline Block,
+
codeblock-source_text,
+
desc.lanpltrusted);
+
+ (void) plperl_call_perl_func(desc, fake_fcinfo);
+ }
+ PG_CATCH();
+ {
+ error_context_stack = pl_error_context.previous;
+ current_call_data = save_call_data;
+ restore_context(oldcontext);
+ PG_RE_THROW();
+ }
+ PG_END_TRY();
+
+ if (SPI_finish() != SPI_OK_FINISH)
+ elog(ERROR, SPI_finish() failed);
+
+ error_context_stack = pl_error_context.previous;
+ current_call_data = save_call_data;
+ restore_context(oldcontext);
+
+ PG_RETURN_VOID();
When does the reference held by desc.reference get freed?
At the moment it looks like this would leak memory for each DO.
+ static void
+ plperl_inline_callback(void *arg)
+ {
+ errcontext(PL/Perl anonymous code block);
+ }
I'd like to see more consistent terminlogy:
desc.proname = Do Inline Block;
plperl_create_sub(DO Inline Block,
errcontext(PL/Perl anonymous code block);
Tim.
--
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] enable-thread-safety defaults?
Peter Eisentraut wrote: Let me be more verbose: I would assume that we want the configure defaults to be the same on all platforms. We fail by default, for example, if zlib and readline are not there, but you can turn them off explicitly. If we turn thread-safety on by default, we will/should fail if thread-safety is not supported, requiring the user to turn it off explicitly. If enough platforms don't support thread-safety, this could become annoying. I don't have a good overview over how many platforms would be affected, and I could in general support changing the default, but I'm just laying down one possible constraint. Well, if we turn it on by default maybe the buildfarm will tell us who the major culprits are :-) 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] plperl and inline functions -- first draft
On Nov 20, 2009, at 2:04 AM, Joshua Tolley wrote: On Wed, Nov 18, 2009 at 12:38:00PM +0200, Alexey Klyukin wrote: Yes, current_call_data can't be allocate in the SPI memory context, since it's used to extract the result after SPI_finish is called, although it doesn't lead to problems here since no result is returned. Anyway, I'd move SPI_connect after the current_call_data initialization. I also noticed that no error context is set in the inline handler, not sure whether it really useful except for the sake of consistency, but in case it is - here is the patch: Makes sense on both counts. Thanks for the help. How does the attached look? These two problems seem to be fixed now, thank you. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc -- 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] plperl and inline functions -- first draft
On Nov 20, 2009, at 3:50 PM, Tim Bunce wrote: When does the reference held by desc.reference get freed? At the moment it looks like this would leak memory for each DO. Isn't it also the case with the existing plperl code ? I've noticed that free(prodesc) is called when it's no longer used (i.e. in plperl_compile_callback:1636), but refcount of desc-reference is never decremented. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc -- 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] Union test case broken in make check?
Tom Lane wrote: Kenneth Marshall k...@rice.edu writes: Without an order by, the order is not defined. Yeah, but with the same data and the same software it should generally give the same result; as evidenced by the fact that these same regression tests have worked for most people for years. There's something odd happening on Emmanuel's machine. Maybe he's changed the hashing algorithms or some planner cost parameters? I did not change anything to Postgres and I can reproduce the problem with a vanilla checkout of HEAD. However, I think I started to see the problem since my last VMWare and OS upgrade (unfortunately I did both simultaneously). For info, I am using VMWare Workstation v6.5.3 build-185404 on Vista 6.0.60002 SP2. The VM is an Ubuntu 9.04 (Jaunty) with a 2.6.28-16 SMP kernel on x86_64 (2 cores available for the VM, 4 cores total). gcc is 4.3.3 (Ubuntu 4.3.3-5ubuntu4). Let me know if you need additional info about my setup. Emmanuel -- Emmanuel Cecchet Aster Data Web: http://www.asterdata.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] Summary and Plan for Hot Standby
On Fri, Nov 20, 2009 at 7:31 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Simon Riggs wrote: On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote: I missed the original discussion of this problem, do you happen to remember the subject or url for the details? December 2008; hackers; you, me and Heikki. Yep: http://archives.postgresql.org/message-id/494b5ffe.4090...@enterprisedb.com And I can see I failed to understand the issue at the time. From the list it looks like the last word was Simon's: http://archives.postgresql.org/message-id/1229710177.4793.567.ca...@ebony.2ndquadrant From discussions in the bar it sounds like this was actually a false start however as the RecentGlobalXmin in the backend doing the split could be less aggressive than the RecentGlobalXmin used by some other backend to hit the hint bits leading to inconsistent results :( I'm leaning towards having the backend actually go fetch all the xmin/xmaxes of the pointers being pruned. It ought to be possible to skip that check in any database with no live snapshots so recovery performance would be unaffected on replicas not actively being used in hot mode. -- 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] Syntax for partitioning
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs si...@2ndquadrant.com wrote: On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote: On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner mar...@bluegap.ch wrote: Hi, Robert Haas wrote: Settling on a syntax, and an internal representation for that syntax, I've been under the impression that this was only about syntax. What are the internal additions? I haven't looked at it in detail, but it adds a new pg_partition table. Whether that table is suitably structured for use by the optimizer is not clear to me. If it does, then my review comments to Kedar still apply: * why do we want another catalog table? what's wrong with pg_inherits? It might need additional columns, and it certainly needs another index. That might work, I haven't looked at it enough to be sure one way or the other. * We need an internal data structure (discussed on this thread also). Leaving stuff in various catalog tables would not be the same thing at all. Ultimately I'm guessing that for query optimization we'll need to include the relevant info in the relcache. But I think that can wait until we're ready to actually make the optimizer changes - not much point in caching data that is never used. Right now I think it's enough to verify (which I haven't) that the schema of the catalog table is suitable for straightforward construction of the data that will eventually need to be cached. ...Robert -- 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] DEFAULT of domain ignored in plpgsql (8.4.1)
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote: Hi It seems that pl/pgsql ignores the DEFAULT value of domains for local variables. With the following definitions in place create domain myint as int default 0; create or replace function myint() returns myint as $body$ declare v_result myint; begin return v_result; end; $body$ language plpgsql immutable; issuing select myint(); returns NULL, not 0 on postgres 8.4.1 If the line v_result myint; is changes to v_result myint default 0; than 0 is returned as expected. I've tried to create a patch, but didn't see how I'd convert the result from get_typedefault() (A Node*, presumeably the parsetree corresponding to the default expression?) into a plan that I could store in a PLpgSQL_expr. I guess I'd need something like SPI_prepare_plan that takes a parse tree instead of a query string. Or am I on a completely wrong track there? While trying to cook up a patch I've also stumbled over what I perceive as a bug relating to DOMAINS and column DEFAULTs. I'll write that up in a second E-Mail to avoid confusion. I suggest adding this to the open CommitFest (2010-01) at https://commitfest.postgresql.org/action/commitfest_view/open ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Prettification versus dump safety
In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on pg_get_triggerdef(triggeroid, true) (ie, pretty mode) to dump triggers. This means that trigger WHEN conditions will be dumped without adequate parenthesization to ensure they are interpreted the same way when loaded into future PG versions. That's not acceptable. The easy ways out of this are (1) change pg_dump to not prettify trigger definitions at all, or (2) change pg_get_triggerdef from the submitted patch so that it doesn't reduce parenthesization even in pretty mode. Or somebody could bite the bullet and decouple formatting from parenthesization decisions in ruleutils.c. That's not going to be me, though. Comments, preferences? 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] plruby code and postgres ?
On Thu, Nov 19, 2009 at 05:15:05PM -0700, u235sentinel wrote: Does anyone have a link for pl/ruby? I found a link under the postgres documentation and found a web site from there talking about the code. However when I clicked on the link to download it I noticed ftp wouldn't respond on their site. Debian's got a copy of the original tarball or the most recently release version: http://packages.debian.org/source/lenny/postgresql-plruby And links there in. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 The Connexions Project http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- 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] Summary and Plan for Hot Standby
On Sun, 2009-11-15 at 17:17 -0500, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: So I'm in favor of committing part of the HS code even if there are known failure conditions, as long as those conditions are well-defined. If we're thinking of committing something that is known broken, I would want to have a clearly defined and trust-inspiring escape strategy. If it is broken, we shouldn't commit it at all. Commit it to some other git branch and call it, postgresql-alpha3-riggs-heikki if you must but keep it out of core. I agree with Heikki that it would be better not to commit as long as any clear showstoppers remain unresolved. Agreed. Joshua D. Drake regards, tom lane -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- 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] Summary and Plan for Hot Standby
On Fri, 2009-11-20 at 16:40 +0900, Josh Berkus wrote: Yes. I'm realizing that because of the highly techincal nature of the discussion and the language used few people other than you and Heikki are aware of the major issues which still need work. It would be helpful if someone could post a summary of outstanding issues which didn't require prior extensive experience with the HS code to understand; possibly you could then get people trying to tackle just those individual issues. Yes I believe it is time for that. Those of us neck deep in production loads would feel a lot better if we knew from a real world perspective what the issue is. Sincerely, Joshua D. Drake --Josh BErkus -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- 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] DEFAULT of domain ignored in plpgsql (8.4.1)
Robert Haas wrote: On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote: I've tried to create a patch, but didn't see how I'd convert the result from get_typedefault() (A Node*, presumeably the parsetree corresponding to the default expression?) into a plan that I could store in a PLpgSQL_expr. I guess I'd need something like SPI_prepare_plan that takes a parse tree instead of a query string. Or am I on a completely wrong track there? While trying to cook up a patch I've also stumbled over what I perceive as a bug relating to DOMAINS and column DEFAULTs. I'll write that up in a second E-Mail to avoid confusion. I suggest adding this to the open CommitFest (2010-01) at https://commitfest.postgresql.org/action/commitfest_view/open Hm, but I don't (yet) have a patch to add... best regards, Florian Pflug smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)
On Fri, Nov 20, 2009 at 12:51 PM, Florian G. Pflug f...@phlo.org wrote: Robert Haas wrote: On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote: I've tried to create a patch, but didn't see how I'd convert the result from get_typedefault() (A Node*, presumeably the parsetree corresponding to the default expression?) into a plan that I could store in a PLpgSQL_expr. I guess I'd need something like SPI_prepare_plan that takes a parse tree instead of a query string. Or am I on a completely wrong track there? While trying to cook up a patch I've also stumbled over what I perceive as a bug relating to DOMAINS and column DEFAULTs. I'll write that up in a second E-Mail to avoid confusion. I suggest adding this to the open CommitFest (2010-01) at https://commitfest.postgresql.org/action/commitfest_view/open Hm, but I don't (yet) have a patch to add... Woops, I saw an attachment and thought there was a patch, but it was just smime.p7s... sorry for the noise. ...Robert -- 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] Prettification versus dump safety
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 (1) change pg_dump to not prettify trigger definitions at all, or (2) change pg_get_triggerdef from the submitted patch so that it doesn't reduce parenthesization even in pretty mode. Or somebody could bite the bullet and decouple formatting from parenthesization decisions in ruleutils.c. That's not going to be me, though. Comments, preferences? Apply (2), and add the decoupling to the official todo list. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911201315 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksG3NEACgkQvJuQZxSWSsiIjgCg1u1oZqXGsM/ToBYH6OCBMcDt yXUAoK8xquH56UerP6AQl7bVxhMhPyyH =yuZ4 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Prettification versus dump safety
Tom Lane wrote: In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on pg_get_triggerdef(triggeroid, true) (ie, pretty mode) to dump triggers. This means that trigger WHEN conditions will be dumped without adequate parenthesization to ensure they are interpreted the same way when loaded into future PG versions. That's not acceptable. The easy ways out of this are (1) change pg_dump to not prettify trigger definitions at all, or (2) change pg_get_triggerdef from the submitted patch so that it doesn't reduce parenthesization even in pretty mode. The pretty option was explicitely never intended for pg_dump use. When pg_dump is used to create a future version proof dump, it shouldn't use the pretty option, when used to create some schema scripts for exernal editing it may be enabled. I propose to invent a cmd line option for that (maybe as prettified plain text output format). Regards, Andreas -- 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] Summary and Plan for Hot Standby
Greg Stark wrote: From discussions in the bar it sounds like this was actually a false start however as the RecentGlobalXmin in the backend doing the split could be less aggressive than the RecentGlobalXmin used by some other backend to hit the hint bits leading to inconsistent results :( Yeah, RecentGlobalXmin was wrong, it's not used at the moment. I'm leaning towards having the backend actually go fetch all the xmin/xmaxes of the pointers being pruned. It ought to be possible to skip that check in any database with no live snapshots so recovery performance would be unaffected on replicas not actively being used in hot mode. Hmm, I have always been thinking that it would be detrimental to performance to go fetch the xmin/xmaxes, but maybe it indeed wouldn't be so bad if you could optimize the common case where there's no snapshots in the standby. Also, if you have a very busy table where a lot of tuples are killed, many of the heap pages will probably be in cache. -- 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] [COMMITTERS] pgsql: /home/peter/commit-msg
Kris Jurka wrote: On Fri, 20 Nov 2009, Magnus Hagander wrote: I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. We figured it's easier to backtrack if there's no more commits on top of the modified one. Not sure how true it really was. -- 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] [COMMITTERS] pgsql: /home/peter/commit-msg
On Fri, Nov 20, 2009 at 2:44 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Kris Jurka wrote: On Fri, 20 Nov 2009, Magnus Hagander wrote: I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. We figured it's easier to backtrack if there's no more commits on top of the modified one. Not sure how true it really was. FWIW, I had good luck with git rebase origin/master. ...Robert -- 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] TRIGGER with WHEN clause
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes: [ TRIGGER WHEN patch ] Applied with assorted revisions. AFAICT the system column issue is only a problem for NEW references in BEFORE triggers --- those columns do read correctly in OLD, and all the time in AFTER triggers. I revised the parsing logic to enforce that. The patch also missed establishing dependencies for stuff referenced in the WHEN expression, and there were a few other minor problems. 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] Prettification versus dump safety
Andreas Pflug pgad...@pse-consulting.de writes: Tom Lane wrote: The easy ways out of this are (1) change pg_dump to not prettify trigger definitions at all, or (2) change pg_get_triggerdef from the submitted patch so that it doesn't reduce parenthesization even in pretty mode. The pretty option was explicitely never intended for pg_dump use. Yeah. I went with (1) because it's something we can undo in future on the pg_dump side. The alternative is to immortalize an arbitrary deviation of pg_get_triggerdef's pretty-fying behavior compared to every other ruleutils.c function. 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] Why do OLD and NEW have special internal names?
Jan Wieck janwi...@yahoo.com writes: On 11/20/2009 1:12 AM, Tom Lane wrote: Jan Wieck janwi...@yahoo.com writes: But this brings up another point about the recent discussion of what RENAME is good for. Removing RENAME may conflict with using OLD/NEW in UPDATE ... RETURNING. No? Um ... not sure why. Specific example please? Inside a trigger proc, NEW is supposed to mean the new row for the table that fired the trigger. However, inside an UPDATE RETURNING for example, there is another set of NEW and OLD. Uh, no there isn't ... and if there were I suppose it'd act much like a query-local alias. Let's call the trigger call's NEW NEW_a and the UPDATE RETURNING NEW NEW_b. How would the developer specify something like INSERT ... RETURNING (NEW_a.value - NEW_b.value)? They could use ALIAS to rename the trigger's NEW to something else. 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
[HACKERS] Re: [COMMITTERS] pgsql: Add a WHEN clause to CREATE TRIGGER, allowing a boolean
On Fri, Nov 20, 2009 at 3:38 PM, Tom Lane t...@postgresql.org wrote: Log Message: --- Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei. Random thought: would it be possible to use something like this to optimize foreign key constraints, by not firing them if none of the relevant columns have been updated? ...Robert -- 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] [COMMITTERS] pgsql: Add a WHEN clause to CREATE TRIGGER, allowing a boolean
Robert Haas robertmh...@gmail.com writes: Random thought: would it be possible to use something like this to optimize foreign key constraints, by not firing them if none of the relevant columns have been updated? There already is code in there to do that; see RI_FKey_keyequal_upd_fk and RI_FKey_keyequal_upd_pk. Earlier in the discussion of this patch I had suggested eliminating the special-case code for FKs in favor of using a WHEN clause, but that would probably not fly unless we can make the WHEN-based implementation just as fast as the bespoke code; which seems unlikely. 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
[HACKERS] Re: [COMMITTERS] pgsql: Add a WHEN clause to CREATE TRIGGER, allowing a boolean
On Fri, Nov 20, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Random thought: would it be possible to use something like this to optimize foreign key constraints, by not firing them if none of the relevant columns have been updated? There already is code in there to do that; see RI_FKey_keyequal_upd_fk and RI_FKey_keyequal_upd_pk. *scratches head* Hmm, I see EXPLAIN showing time calls logged against fk triggers even when I don't update any columns, unless the existing value is NULL. But maybe I'm doing something strange, or misinterpreting the output. Earlier in the discussion of this patch I had suggested eliminating the special-case code for FKs in favor of using a WHEN clause, but that would probably not fly unless we can make the WHEN-based implementation just as fast as the bespoke code; which seems unlikely. Yeah. ...Robert -- 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 option for COPY
Emmanuel Cecchet wrote: Hi Jan, Here is a new version of the patch with the following modifications: - used oid list from pg_list.h - properly handles triggers and generate an error if needed (updated doc as well) - added your test cases + extra bad trigger cases Hi, that got broken by the WHEN triggers patch (c6e0a36243a54eff79b47b3a0cb119fb67a55165), which changed the TriggerEnabled function signature, the code currently does not compile. I'll continue reading, in the meantime could you send a updated patch? Thanks, Jan -- 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 option for COPY
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: that got broken by the WHEN triggers patch (c6e0a36243a54eff79b47b3a0cb119fb67a55165), which changed the TriggerEnabled function signature, the code currently does not compile. [ squint... ] What is that patch doing touching the innards of trigger.c in the first place? I can't see any reason for trigger.c to be associated with partitioning. 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] DEFAULT of domain ignored in plpgsql (8.4.1)
Florian G. Pflug f...@phlo.org writes: It seems that pl/pgsql ignores the DEFAULT value of domains for local variables. The plpgsql documentation seems entirely clear on this: The DEFAULT clause, if given, specifies the initial value assigned to the variable when the block is entered. If the DEFAULT clause is not given then the variable is initialized to the SQL null 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] [INTERFACES] ecpg 8.3 - 8.4 migration
Bosco Rama postg...@boscorama.com writes: According to the PG docs 'server' is a *non-reserved* keyword. Does ecpg treat it as a reserved word? Upon poking around in the ecpg sources, I discover that it has its own list of unreserved keywords and pays no attention whatsoever to the core grammar's unreserved_keyword list. I can hardly find words to express my dissatisfaction with that. The unreserved_keyword list might not be the single most-likely-to-change production in the core grammar, but it's got to be right up there in the top two or three. This little shortcut means that all the work done last year to generate the ecpg grammar from core was practically useless --- we still have to worry about manually maintaining the ecpg grammar any time we change core. This has *got* to be fixed. The lack of obvious feedback about keywords not included in any keyword list means that manual maintenance is guaranteed to fail, as indeed it's already done, per this report. 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] DEFAULT of domain ignored in plpgsql (8.4.1)
Tom Lane wrote: Florian G. Pflug f...@phlo.org writes: It seems that pl/pgsql ignores the DEFAULT value of domains for local variables. The plpgsql documentation seems entirely clear on this: The DEFAULT clause, if given, specifies the initial value assigned to the variable when the block is entered. If the DEFAULT clause is not given then the variable is initialized to the SQL null value. Hm, must have missed that paragraph :-(. Sorry for that. Would a patch that changes that have any chance of being accepted? Or is the gain (not having to repeat the DEFAULT clause, and being able to maintain it at one place instead of many) considered too small compared to the risk of breaking existing code? best regards, Florian Pflug smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Partitioning option for COPY
Tom Lane wrote: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: that got broken by the WHEN triggers patch (c6e0a36243a54eff79b47b3a0cb119fb67a55165), which changed the TriggerEnabled function signature, the code currently does not compile. [ squint... ] What is that patch doing touching the innards of trigger.c in the first place? I can't see any reason for trigger.c to be associated with partitioning. The problem I had is that if I used the standard trigger mechanism for after row inserts on a child table where the trigger is called asynchronously, I had a relcache leak on the child table. I tried to ask for help on that earlier on but it got lost with other discussions on the patch. So I tried to call the after trigger synchronously on the child table and it worked. So the patch is just adding a synchronous call to after row insert triggers that is called when the tuple is moved to a child table (also allows to detect for triggers that are messing with the routing). I would be happy to follow any recommendation for a more elegant solution to the problem. Emmanuel -- Emmanuel Cecchet Aster Data Web: http://www.asterdata.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] DEFAULT of domain ignored in plpgsql (8.4.1)
Would a patch that changes that have any chance of being accepted? Or is the gain (not having to repeat the DEFAULT clause, and being able to maintain it at one place instead of many) considered too small compared to the risk of breaking existing code? I don't think there's a lot of risk of code breakage; few people use domains, fewer use them with defaults, and you might be the only one using them as variable types. And there are going to be more substantial backwards compat issues with the lexer changes anyway. As long as we remember to flag the compatibility issue in the release notes, I don't see it as a problem. However, there are some other issues to be resolved: (1) what should be the interaction of DEFAULT parameters and domains with defaults? (2) this change, while very useful, does change what had been a simple rule (All variables are NULL unless specifically set otherwise) into a conditional one (All variables are NULL unless set otherwise OR unless they are declared as domain types with defaults). Do people feel that the new behavior would be sufficiently intuitive to avoid user confusion? (3) Last I checked, there were still several places in which domains did not behave consistently in stored procedures. I think that Elein had some unfinished patches in this regard -- you'll want to search the archives and the TODO list. --Josh Berkus -- 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] [COMMITTERS] pgsql: /home/peter/commit-msg
2009/11/20 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: Kris Jurka wrote: On Fri, 20 Nov 2009, Magnus Hagander wrote: I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. We figured it's easier to backtrack if there's no more commits on top of the modified one. Not sure how true it really was. It made the work a bit easier, but it would've worked if it kept running as well. But we didn't know it at the time. Actually, it would've been more likely to cause conflicts for people I think, since we would still have had to revert everything back to the commit before the broken one anyway, and it would then affect more files for those who had pulled a broken version. -- 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] plperl and inline functions -- first draft
On Nov 20, 2009, at 10:50 PM, Tim Bunce wrote: I'd suggest: ...; PL/Perl functions created with CREATE FUNCTION are called in a scalar context, so can't return a list. You can return more complex structures (arrays, records, and sets) by returning a reference, as discussed below. That only mentions functions created with CREATE FUNCTION though. Perhaps it needs to be generalized to cover DO as well. FWIW, DO is run in a VOID context. Return values are ignored (or perhaps trigger an exception?). Best, David -- 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] enable-thread-safety defaults?
2009/11/20 Peter Eisentraut pete...@gmx.net: On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote: 2009/11/20 Peter Eisentraut pete...@gmx.net: On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote: Is there any actual reason why we are building without thread safety by default on most platforms? Consistent defaults on all platforms? So why do we have largefile enabled by default? And zlib? And readline? Let me be more verbose: I would assume that we want the configure defaults to be the same on all platforms. We fail by default, for example, if zlib and readline are not there, but you can turn them off explicitly. If we turn thread-safety on by default, we will/should fail if thread-safety is not supported, requiring the user to turn it off explicitly. Yes, of course. Silently turning it off would be a really really bad idea. If enough platforms don't support thread-safety, this could become annoying. Agreed. I don't have a good overview over how many platforms would be affected, and I could in general support changing the default, but I'm just laying down one possible constraint. Well, the buildfarm would tell us that, no? :) -- 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
