2014-04-24 15:19 keltezéssel, Boszormenyi Zoltan írta:
2014-04-24 14:50 keltezéssel, Michael Meskes írta:
Thanks an awful lot Antonin.
Committer availability might well be the issue, but missing review
probably too.
Yes, you're right. If my taks is mostly one last glance and a commit I
2014-04-24 14:50 keltezéssel, Michael Meskes írta:
Thanks an awful lot Antonin.
Committer availability might well be the issue, but missing review
probably too.
Yes, you're right. If my taks is mostly one last glance and a commit I will
make time for that.
Whether this review is enough to
respectively ...
Consider it just a tentative proposal, I can easily be wrong :-)
I will read your comments again with fresh eyes.
That's it for my review.
Thank you very much.
// Tony
On 04/16/2014 10:54 AM, Boszormenyi Zoltan wrote:
2014-01-18 18:08 keltezéssel, Boszormenyi Zoltan
2014-04-16 10:54 keltezéssel, Boszormenyi Zoltan írta:
2014-01-18 18:08 keltezéssel, Boszormenyi Zoltan írta:
Hi,
Alvaro Herrera wrote:
Boszormenyi Zoltan escribió:
Rebased patches after the regression test and other details were fixed
in the infrastructure part.
This thread started
2014-03-24 07:22 keltezéssel, Ashutosh Bapat írta:
Hi,
I tried using integer array within a structure array in ECPG code. But it resulted in
some garbage values being printed from the table. Here are the details,
The ECPG program is attached (array_test.pgc). It tries to read the contents of
2014-01-16 22:13 keltezéssel, Alvaro Herrera írta:
Alvaro Herrera escribió:
Boszormenyi Zoltan escribió:
All patches are attached again for completeness.
Thanks. I pushed a commit comprising patches 09 through 14.
Now also pushed 15 to 17.
Thanks very much.
--
Sent via pgsql-hackers
2014-01-16 23:42 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
Rebased patches after the regression test and other details were fixed
in the infrastructure part.
This thread started in 2010, and various pieces have been applied
already and some others have changed in nature
2013-12-24 13:55 kelteze'ssel, MauMau i'rta:
Hello,
I encountered a bug of ECPG with PG 9.2.4, which probably exists in all
releases. The
attached patch is for 9.4. Could you review and backport this to at least 9.2
and later?
[Problem]
The attached ECPG app
The app wasn't attached,
2013-12-21 14:56 keltezéssel, Peter Eisentraut írta:
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th.
Done.
Best regards,
Zoltán Böszörményi
--
--
Zoltán
Hi,
2013-12-05 15:36 keltezéssel, Antonin Houska írta:
On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thanks. New version attached.
I have reviewed and tested it and marked it as ready for committer.
Best regards,
Zoltán Böszörményi
how this is usually enforced. I'm
mentioning it for the sake of completeness.
The soversion has changed because of the changes in already
existing exported functions.
// Antonin Houska (Tony)
On 11/28/2013 03:21 PM, Boszormenyi Zoltan wrote:
2013-11-20 14:53 keltezéssel, Boszormenyi Zoltan
Hi,
I am reviewing your patch.
2013-10-10 15:32 keltezéssel, Antonin Houska írta:
On 10/09/2013 08:56 PM, Robert Haas wrote:
There seem to be several review comments made since you posted this
version. I'll mark this Waiting on Author in the CommitFest
application, since it seems that the
2013-11-28 00:17 keltezéssel, Tom Lane írta:
Peter Eisentraut pete...@gmx.net writes:
On 11/27/13, 3:47 PM, Tom Lane wrote:
Given these considerations, I think it'd be better to allow explicit
application control over whether read-ahead happens for a particular
query. And I have no problem
2013-11-28 09:55 keltezéssel, Michael Meskes írta:
On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote:
Well, technically, unspecified means NO SCROLL according to the SQL
standard. A lot of applications in ECPG are ported from other systems,
That means by automatically adding
2013-11-29 04:56 keltezéssel, Peter Eisentraut írta:
On Wed, 2013-11-27 at 18:17 -0500, Tom Lane wrote:
Hm. So you're suggesting that ECPG fix this problem by inserting an
explicit NO SCROLL clause into translated DECLARE CURSOR commands, if
there's not a SCROLL clause?
I wouldn't go that far
2013-11-23 22:01 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Attached is the patch that modified the command tag returned by
the DECLARE CURSOR command. It returns DECLARE SCROLL CURSOR
or DECLARE NO SCROLL CURSOR depending on the cursor's
scrollable flag that can
2013-11-27 19:16 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-11-23 22:01 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Attached is the patch that modified the command tag returned by
the DECLARE CURSOR command. It returns DECLARE
2013-11-27 20:49 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
If you consider all these:
- certain combinations of query and DECLARE stmt flags fail;
- adding NO SCROLL is breaking backward compatibility;
- the readahead code has to really know whether the cursor
2013-11-21 11:52 keltezéssel, David Rowley írta:
I'm not quite sure why nobody else seems to be complaining, but the changes to type.h in
this commit seems to have broken things little.
In the visual studios build I'm getting:
src\interfaces\ecpg\preproc\preproc.y(84): error C2065:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need to
clone it fresh. https://github.com/zboszor/ecpg
2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need
2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need
2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need
2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need
2013-10-11 00:16 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch. I was shocked by it initially, but on
further reading, I observed
2013-10-21 17:11 keltezéssel, Robert Haas írta:
On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-21 09:15:36 -0400, Peter Eisentraut wrote:
On 10/21/13 1:31 AM, Andres Freund wrote:
The point of the CF is exactly that all
patches get at least one good
2013-10-21 18:25 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
I even provided a repo @github where it was broken up into pieces that can be
sanely reviewed.
You also gave the first person looking at the patch a hard time about
asking
2013-10-21 19:10 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
I hoped that reviewing 4 patches in this CF (UNNEST, Extension templates,
DISCARD SEQUENCES, and extended RETURNING syntax) gets my huge patch reviewed.
I'm still on the hook for parts of this one (and also
Hi,
2013-10-19 17:20 keltezéssel, David Fetter írta:
Thanks very much to Mike Blackwell and Craig Kerstiens for their
persistence through what most people would consider a tedious and
thankless task. Thanks also to the patch submitters, reviewers and
other participants.
That the formal
2013-10-11 00:16 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch.
You *know* that the patch is available in pieces at
https
Hi,
I have experimented with cursors a little and found that the part about FOR SHARE/FOR
UPDATE in
http://www.postgresql.org/docs/9.2/interactive/sql-declare.html
i.e. the sensitive cursor is not what actually happens. BTW, 9.3 has the same contents
for the same page.
If the cursor's
2013-09-18 14:27 keltezéssel, Andres Freund írta:
On 2013-09-18 14:23:19 +0200, Boszormenyi Zoltan wrote:
Hi,
I have experimented with cursors a little and found that the part about FOR
SHARE/FOR UPDATE in
http://www.postgresql.org/docs/9.2/interactive/sql-declare.html
i.e. the sensitive
2013-09-13 21:03 keltezéssel, Andrew Gierth írta:
Latest version of patch, incorporating regression tests and docs, and
fixing the operator issue previously raised.
It looks good. I think it's ready for a committer.
Best regards,
Zoltán Böszörményi
--
--
Hi,
2013-08-17 13:02 keltezéssel, Boszormenyi Zoltan írta:
[snip, discussion of WHERE CURRENT OF in the ECPG client lib]
I had a second thought about it and the client side caching and
parser behind the application's back seems to be an overkill.
Instead, I propose a different solution, which
2013-08-27 01:24 keltezéssel, Andrew Gierth írta:
Latest version of patch. This should be it as far as code goes; there
may be some more regression test work, and a doc patch will be
forthcoming.
This version supports, in addition to the previous stuff:
[snip]
In my limited testing, it works
2013-08-27 18:09 keltezéssel, Dimitri Fontaine írta:
Hi,
Boszormenyi Zoltan z...@cybertec.at writes:
Here's a review for this patch.
Thanks for that review Zoltan!
You're welcome.
I would like to see the control parameters documented in allcaps
in CREATE EXTENSION TEMPLATE. Then ALTER
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:2001:26: warning: ‘before_index’ may be used uninitialized in this function
[-Wmaybe-uninitialized
2013-08-21 19:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:2001:26: warning: ‘before_index’ may be used
2013-08-21 20:00 keltezéssel, Boszormenyi Zoltan írta:
2013-08-21 19:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs
Hi,
2013-08-21 20:52 keltezéssel, Karol Trzcionka írta:
W dniu 21.08.2013 19:17, Boszormenyi Zoltan pisze:
With this fixed, a more complete review:
Thanks.
There is a new regression test (returning_before_after.sql) covering
this feature. However, I think it should be added to the group
2013-08-20 08:13 keltezéssel, Pavel Stehule írta:
2013/8/20 David Fetter da...@fetter.org mailto:da...@fetter.org
On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote:
Hello
Harder maybe but it may still be cleaner in the long run.
Overall, it's my
2013-08-20 08:37 keltezéssel, Heikki Linnakangas írta:
On 19.08.2013 21:15, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Based on a quick look it seems like you're throttling on the receiving
side. Is that a good idea? Especially over longer latency links, TCP
Hi,
2013-08-04 15:20 keltezéssel, Dimitri Fontaine írta:
Thom Brown t...@linux.com writes:
Could you please resubmit this without using SnapshotNow as it's no longer
supported?
Sure, sorry that I missed that, please find v12 attached.
Here's a review for this patch.
* Is the patch in a
2013-08-20 14:35 keltezéssel, David E. Wheeler írta:
On Aug 20, 2013, at 2:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select * from x;
end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
david$#
Hi,
2013-08-19 21:52 keltezéssel, Boszormenyi Zoltan írta:
2013-08-19 21:21 keltezéssel, Karol Trzcionka írta:
W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze:
* Does it apply cleanly to the current git master?
No. There's a reject in src/backend/optimizer/plan/initsplan.c
Thank you
2013-08-20 17:30 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in
Hi,
2013-08-13 15:54 keltezéssel, Andrew Gierth írta:
Summary:
This patch implements a method for expanding multiple SRFs in parallel
that does not have the surprising LCM behaviour of SRFs-in-select-list.
(Functions returning fewer rows are padded with nulls instead.)
It then uses this
2013-07-31 22:50 keltezéssel, Antonin Houska írta:
On 07/31/2013 07:13 AM, Gibheer wrote:
Hi,
That is a really nice feature.
I don't pretend it's my idea, I just coded it. My boss proposed the feature as
such :-)
I took a first look at your patch and some empty lines you added (e.g. line 60
Hi,
mini-review follows.
2013-07-22 21:52 keltezéssel, Karol Trzcionka írta:
I've noticed problem with UPDATE ... FROM statement. Fix in new version.
Regards,
Karol
* Does it apply cleanly to the current git master?
No. There's a reject in src/backend/optimizer/plan/initsplan.c
* Does it
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Hi,
On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
Hello,
the purpose of this patch is to limit impact of pg_backup on running server.
Feedback is appreciated.
Based on a quick look it seems like you're throttling on the receiving
side.
2013-08-19 20:03 keltezéssel, Josh Berkus írta:
On 08/19/2013 09:23 AM, Boszormenyi Zoltan wrote:
Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having
WITH ORDINALITY and this feature, I would vote for removing
SRF-in-targetlist and call the release PostgreSQL 10.0.
That's
Hi,
2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta:
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com mailto:fabriziome...@gmail.com
2013-08-19 21:02 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta:
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
2013-08-19 21:11 keltezéssel, Andres Freund írta:
On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Hi,
On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
Hello,
the purpose of this patch is to limit impact of pg_backup on running
2013-08-19 21:21 keltezéssel, Karol Trzcionka írta:
W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze:
* Does it apply cleanly to the current git master?
No. There's a reject in src/backend/optimizer/plan/initsplan.c
Thank you, merged in attached version.
* Does it include reasonable tests
2013-08-19 22:04 keltezéssel, Andrew Gierth írta:
Boszormenyi Zoltan wrote:
This parser hackery is of course somewhat ugly. But given the objective
of implementing the spec's unnest syntax, it seems to be the least ugly
of the possible approaches. (The hard part of doing it any other way
would
2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta:
Hi,
I am restarting this old thread... :-)
2012-04-24 10:17 keltezéssel, Michael Meskes írta:
OK, I will implement #2. Another question popped up: what to do
with FETCH ALL? The current readahead window size or temporarily
bumping
2013-08-05 16:01 keltezéssel, Stephen Frost írta:
* Greg Stark (st...@mit.edu) wrote:
On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not even clear we do want this in /etc since none of our GUC
options are repeatable things like Apache virtual servers. It actually
2013-08-06 19:41 keltezéssel, Bruce Momjian írta:
On Tue, Aug 6, 2013 at 06:34:35PM +0200, Boszormenyi Zoltan wrote:
2013-08-05 16:01 keltezéssel, Stephen Frost írta:
* Greg Stark (st...@mit.edu) wrote:
On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not even
2013-06-27 17:03 keltezéssel, Fujii Masao írta:
On Thu, Jun 27, 2013 at 2:22 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Hi,
I just realized that in the original incarnation of lock_timeout,
I used ERRCODE_LOCK_NOT_AVAILABLE (to be consistent with NOWAIT)
but the patch that was accepted
Hi,
I just realized that in the original incarnation of lock_timeout,
I used ERRCODE_LOCK_NOT_AVAILABLE (to be consistent with NOWAIT)
but the patch that was accepted into 9.3 contained ERRCODE_QUERY_CANCELED
which is the same as for statement_timeout.
Which would be more correct?
Thanks in
Hi,
review below.
2013-06-13 14:35 keltezéssel, Amit Kapila írta:
On Friday, June 07, 2013 9:45 AM Amit Kapila wrote:
On Thursday, June 06, 2013 10:22 PM Robert Haas wrote:
On Wed, Jun 5, 2013 at 7:24 AM, Amit Kapila amit.kap...@huawei.com
wrote:
On Monday, May 27, 2013 4:17 PM Amit Kapila
2013-06-14 05:12 keltezéssel, Amit Kapila írta:
On Friday, June 14, 2013 3:17 AM Josh Berkus wrote:
On 06/13/2013 05:35 AM, Amit Kapila wrote:
On Friday, June 07, 2013 9:45 AM Amit Kapila wrote:
On Thursday, June 06, 2013 10:22 PM Robert Haas wrote:
On Wed, Jun 5, 2013 at 7:24 AM, Amit
2013-06-18 14:11 keltezéssel, Amit Kapila írta:
On Tuesday, June 18, 2013 3:26 PM Boszormenyi Zoltan wrote:
Hi,
review below.
Thanks for the review.
There are 2 options to proceed for this patch for 9.4
1. Upload the SET PERSISTENT syntax patch for coming CF by fixing
existing
review
2013-05-17 16:05 keltezéssel, Heikki Linnakangas írta:
On 18.02.2013 16:35, Boszormenyi Zoltan wrote:
2013-01-29 11:15 keltezéssel, Magnus Hagander írta:
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu haribabu.ko...@huawei.com
wrote:
On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
On Wed
2013-05-15 20:05 keltezéssel, Andrew Dunstan írta:
On 05/15/2013 02:00 PM, Josh Berkus wrote:
Obviously we need a meta-manager who makes sure we have managers, and is
able to notice that a manager is MIA and needs replaced (or at least
backed-up).
And then a meta-meta-manager to make sure
2013-04-21 15:10 keltezéssel, Bruce Momjian írta:
On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:
2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those dates
2013-03-29 02:46 keltezéssel, Tom Lane írta:
Since there has been some, um, grumbling about the quality of the
release notes of late, I've prepared draft notes for next week's
releases, covering commits through today. These are now committed
into the master branch for review, and should show up
2013-04-21 08:28 keltezéssel, Boszormenyi Zoltan írta:
2013-03-29 02:46 keltezéssel, Tom Lane írta:
Since there has been some, um, grumbling about the quality of the
release notes of late, I've prepared draft notes for next week's
releases, covering commits through today. These are now
2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those dates might change,
but that is the current plan. I have completed a draft 9.3 release
notes, which you can view here:
2013-04-10 18:46 keltezéssel, Fujii Masao írta:
On Wed, Apr 10, 2013 at 11:16 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-04-10 10:10:31 -0400, Tom Lane wrote:
Amit Kapila amit.kap...@huawei.com writes:
On Wednesday, April 10, 2013 3:42 PM Samrat Revagade wrote:
Sorry, this is
2013-04-03 20:58 keltezéssel, Gavin Flower írta:
On 04/04/13 05:36, David E. Wheeler wrote:
On Apr 3, 2013, at 9:30 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Fortran ... Basic ... actually I'd have thought that zero was a
minority position. Fashions change I guess.
I say we turn the default
2013-03-18 06:47 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true
2013-03-17 04:48 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
[ 2-lock_timeout-v37.patch ]
Applied after a fair amount of additional hacking.
Thank you, thank you, thank you! :-)
I was disappointed to find that the patch introduced a new race
condition
2013-03-17 16:07 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 04:48 keltezéssel, Tom Lane írta:
[ worries about stray SIGALRM events ]
Your reasoning seems to be correct. However, if we take it to the
extreme, enable_timeout_at/enable_timeout_after
2013-03-17 17:05 keltezéssel, Greg Smith írta:
On 3/14/13 4:48 PM, Boszormenyi Zoltan wrote:
The attached patch makes
SET PERSISTENT transactional and uses one setting per file.
It uses the currently existing parsing and validating code
and because of this, the patch is half the size of v12
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
sigalrm_allowed
2013-03-18 06:22 keltezéssel, Boszormenyi Zoltan írta:
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Boszormenyi Zoltanz...@cybertec.at writes:
[ 2-lock_timeout-v33.patch ]
I looked at this patch a bit. I don't understand why you've chosen to
alter the API of the enable_timeout variants to have a bool result that
says I didn't bother to process
2013-03-16 17:42 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Also, I'm not really enamored of the choice to use List* infrastructure
for enable_timeouts().
Changed. However, the first member of the structure is
TimeoutId
2013-03-15 00:48 keltezéssel, Boszormenyi Zoltan írta:
2013-03-13 21:28 keltezéssel, Boszormenyi Zoltan írta:
2013-03-13 13:45 keltezéssel, Andres Freund írta:
On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM
2013-03-13 21:28 keltezéssel, Boszormenyi Zoltan írta:
2013-03-13 13:45 keltezéssel, Andres Freund írta:
On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having just some set and not others would be
inconsistent.
Yeah, that's a killer. The reload would need to be
2013-03-13 09:09 keltezéssel, Boszormenyi Zoltan írta:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having just some set and not others would be
inconsistent
2013-03-13 13:45 keltezéssel, Andres Freund írta:
On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having
2013-03-06 19:53 keltezéssel, Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the
2013-03-04 08:02 keltezéssel, Simon Riggs írta:
On 4 March 2013 06:39, Boszormenyi Zoltan z...@cybertec.at wrote:
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
src/backend/rewrite/rewriteDefine.c.orig| 945
2013-03-04 08:10 keltezéssel, Devrim Gündüz írta:
Hi,
Kevin already removed it with a followup commit:
http://git.postgresql.org/pg/commitdiff/d63977eea3ab18fdec05e370b633d10b9fd20179
404 - Unknown commit object
Regards, Devrim
Boszormenyi Zoltan z...@cybertec.at wrote:
Hi
2013-03-04 13:01 keltezéssel, Magnus Hagander írta:
The repository is currently broken. There's a thread on www about it, and also see the
email to hackers a few hours ago telling committers to stop pushing until it's fixed.
Thanks for the info, I didn't know about it. I am not
subscribed
Hi,
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
src/backend/rewrite/rewriteDefine.c.orig| 945 +...
...
create mode 100644 src/backend/rewrite/rewriteDefine.c.orig
Committers should be more careful if they want to do
2013-02-27 20:38 keltezéssel, Boszormenyi Zoltan írta:
2013-02-27 20:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying
2013-02-27 04:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
attached is v30, I hope with everything fixed.
Making progress, certainly.
Given the hack to the API of enable_timeout_after() and the need for
timeout_reset_base_time(), I'm just going
2013-02-27 19:07 keltezéssel, Tom Lane írta:
Stephen Frost sfr...@snowman.net writes:
Tom, can you comment on your thoughts around this notion of an aggregate
time constraint for waiting on locks? As mentioned upthread, I like the
idea of having an upper-limit on waiting for relation-level
2013-02-27 20:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying that we shouldn't have
that capability, just
2013-02-24 16:14 keltezéssel, Boszormenyi Zoltan írta:
2013-02-24 15:03 keltezéssel, Stephen Frost írta:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format
2013-02-25 15:25 keltezéssel, Tom Lane írta:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
I think we should
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
Zoltán,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
First off, it's not in context diff format, which is the PG standard for
patch submission.
Since moving to GIT, this expectation
Stephen,
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
Zoltán,
* Zoltán Böszörményi (z...@cybertec.at) wrote:
The patch now passed make check in both cases.
Is v29 the latest version of this patch..?
attached is v30, I hope with everything fixed.
- List based
2013-02-24 15:03 keltezéssel, Stephen Frost írta:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format (and uncompressed unless it's too large) for easier reading.
That avoids
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
Zoltán,
* Zoltán Böszörményi (z...@cybertec.at) wrote:
The patch now passed make check in both cases.
Is v29 the latest version of this patch..?
Yes, is was until you came up with your review... ;-)
Looking through the patch, I've noticed
1 - 100 of 480 matches
Mail list logo
