From: Amit Khandekar [mailto:amit.khande...@enterprisedb.com]
> On 1 November 2013 16:32, Etsuro Fujita wrote:
>> From: Fujii Masao [mailto:masao.fu...@gmail.com]
>>> I'm not sure if it's good idea to show the number of the fetches because it
>>> seems difficult to tune work_mem from that number.
* Tom Lane wrote:
I looked at this patch a bit. I agree that we need to fix
pgwin32_CommandLine to double-quote the executable name, but it needs a
great deal more work than that :-(. Whoever wrote this code was
One additional issue is that the path to the service executable should
use back
On 24.11.2013 19:23, Simon Riggs wrote:
On 18 November 2013 07:06, Heikki Linnakangas wrote:
On 18.11.2013 13:48, Simon Riggs wrote:
On 18 November 2013 07:50, Heikki Linnakangas
wrote:
It doesn't go far enough, it's still too *low*-level. The sequence AM
implementation shouldn't need to h
Merlin Moncure writes:
> By 'insignificant' you mean 'necessary to do any non-trivial real
> work'. Personally, I'd prefer it if FDW was extended to allow
> arbitrary parameterized queries like every other database connectivity
> API ever made ever. But in lieu of that, I'll take as much push d
Pavel Stehule writes:
> there is other issue - simply parser will be really user unfriendly, and
> user friendly parser will not by simply :(
If simple things are hard to implement, get yourself better tools.
Each time we get on the topic of improving scripting abilities for our
interactive tool
On 25 November 2013, Amit Khandekar
mailto:amit.khande...@enterprisedb.com>> wrote:
>>>Ok. we will then first fix the \COPY TO issue where it does not revert back
>>>the overriden psql output file handle. Once this is solved, fix for both
>>>COPY FROM and COPY TO, like how it is done in the patc
On 25 November 2013 04:01, Heikki Linnakangas wrote:
> The proposed changes to alloc() would still suffer from all the problems
> that I complained about. Adding a new API alongside doesn't help with that.
You made two proposals. I suggested implementing both.
What would you have me do?
--
S
Hi,
On 2013-11-24 16:56:26 -0500, J Smith wrote:
> coredumper worked like a charm. Useful tool, that is... although as a
> bit of advice, I'd try not to run it on Postgres if your various
> memory settings are tweaked towards production use -- the core dump
> that was captured on my server weighed
On Sun, Nov 24, 2013 at 6:02 AM, Jeff Davis wrote:
> On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote:
> My take is that configuration options should be used to serve different
> use cases. One thing I like about postgres is that it doesn't have
> options for the sake of options.
>
> The trade
On Sat, Nov 23, 2013 at 08:44:42AM -0800, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I am not a fan of backpatching any of this.
>
> Here's my problem with that. Here's setup to create what I don't
> think is all that weird a setup:
>
> The cluster is created in the state that was dump
On 24 November 2013, Tom Lane Wrote:
> > One suggestion:
> > Instead of using sizeof(cmdLine),
> > a. Can't we use strlen (hence small 'for' loop).
> > b. Or use memmove to move one byte.
>
> I looked at this patch a bit. I agree that we need to fix
> pgwin32_CommandLine to double-quote
On Mon, Nov 25, 2013 at 3:33 AM, Dimitri Fontaine
wrote:
> Pavel Stehule writes:
>> there is other issue - simply parser will be really user unfriendly, and
>> user friendly parser will not by simply :(
>
> If simple things are hard to implement, get yourself better tools.
>
> Each time we get on
On 11/25/2013 09:00 AM, Merlin Moncure wrote:
On Mon, Nov 25, 2013 at 3:33 AM, Dimitri Fontaine
wrote:
Pavel Stehule writes:
there is other issue - simply parser will be really user unfriendly, and
user friendly parser will not by simply :(
If simple things are hard to implement, get yourse
Andrew Dunstan writes:
> Even if it is it's totally off topic. Please don't hijack email threads.
Well, when I read that parsing a user setup is too complex, for me that
calls for a solution that offers more power to the user without us
having to write specialized code each time.
I'm sorry, but
On 11/25/2013 09:33 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Even if it is it's totally off topic. Please don't hijack email threads.
Well, when I read that parsing a user setup is too complex, for me that
calls for a solution that offers more power to the user without us
having to
Andrew Dunstan writes:
>> I'm sorry, but I don't understand how off-topic or hijack applies here.
And I just realize there's another way to read what Pavel said, which is
that *user scripts* parsing the output of psql might become harder to
write as soon as they don't control the default border s
On 10/3/13, 7:58 AM, Magnus Hagander wrote:
>> Did we get around to doing this?
> Nope.
>
> Given my schedule between now and the release wrap, I won't have a
> chance to do it if I want any reasonable ability to roll it back if it
> fails. But if you want to ahead and get it done, go ahead :)
Ne
On Mon, Nov 25, 2013 at 4:27 PM, Peter Eisentraut wrote:
> On 10/3/13, 7:58 AM, Magnus Hagander wrote:
> >> Did we get around to doing this?
> > Nope.
> >
> > Given my schedule between now and the release wrap, I won't have a
> > chance to do it if I want any reasonable ability to roll it back if
Magnus Hagander writes:
> This will somehow show up in the snapshot builds, correct? So we (you? :P)
> can verify after the next snapshots that it's correct?
I thought the devel docs at
http://www.postgresql.org/docs/devel/static/
were built on that machine?
regards, tom
Andres Freund wrote:
Hi,
> The attached pgbench testcase can reproduce two issues:
Thanks.
> 2) we frequently error out in heap_lock_updated_tuple_rec() with
> ERROR: unable to fetch updated version of tuple
>
> That's because when we're following a ctid chain, it's perfectly
> possible for t
On Mon, Nov 25, 2013 at 4:40 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > This will somehow show up in the snapshot builds, correct? So we (you?
> :P)
> > can verify after the next snapshots that it's correct?
>
> I thought the devel docs at
> http://www.postgresql.org/docs/devel/static/
>
On Mon, Nov 25, 2013 at 4:04 AM, Jeff Davis wrote:
> session_preload_libraries is not in the sample config file. Is that just
> an oversight?
I think so.
Regards,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
> > 2) we frequently error out in heap_lock_updated_tuple_rec() with
> > ERROR: unable to fetch updated version of tuple
> >
> > That's because when we're following a ctid chain, it's perfectly
> > possible for the updated version of a tuple to
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> As the path didn't make it already, yes it needs another (final) round
> of review. The main difficulty in reviewing is understanding the design
> and the relation in between our current model of extensions and what
> this patch offers.
On Mon, Nov 25, 2013 at 6:47 AM, Andres Freund wrote:
> Hi,
>
> On 2013-11-24 16:56:26 -0500, J Smith wrote:
>
>> Nov 23 14:38:32 dev postgres[23810]: [4-1] user=dev,db=dev ERROR: could not
>> access status of transaction 13514992
>> Nov 23 14:38:32 dev postgres[23810]: [4-2] user=dev,db=dev DET
Andres Freund wrote:
> On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
> > There is no way to close the window, but there is no need; if the
> > updater aborted, we don't need to mark the page prunable in the first
> > place. So we can just check the return value of
> > HeapTupleHeaderGetUpda
J Smith escribió:
> We did have some long-running transactions, yes. We refactored a bit
> and removed them and the problem ceased on our end. We ended up
> reverting our changes for the sake of running this experiment over the
> weekend and the errors returned. We've since restored our fix and
>
On 2013-11-25 13:45:53 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
>
> > > There is no way to close the window, but there is no need; if the
> > > updater aborted, we don't need to mark the page prunable in the first
> > > place. So
On Mon, Nov 25, 2013 at 11:46 AM, Alvaro Herrera
wrote:
> J Smith escribió:
>
>> We did have some long-running transactions, yes. We refactored a bit
>> and removed them and the problem ceased on our end. We ended up
>> reverting our changes for the sake of running this experiment over the
>> week
Andrew Tipton wrote:
> Simon Riggs wrote:
>> So we'd need to get access to the changed rows, rather than
>> re-executing a huge SQL command that re-checks every row of the
>> table. That last point will make it unusable for sensible
>> amounts of data.
>
> That sounds very similar to handling in
On Mon, Nov 25, 2013 at 11:04:23AM -0800, Kevin Grittner wrote:
> Andrew Tipton wrote:
> > Simon Riggs wrote:
> >> So we'd need to get access to the changed rows, rather than
> >> re-executing a huge SQL command that re-checks every row of the
> >> table. That last point will make it unusable fo
David Fetter wrote:
> On Mon, Nov 25, 2013 at 11:04:23AM -0800, Kevin Grittner wrote:
>> As soon as we are out of this CF, I am planning to write code to
>> capture deltas and fire functions to process them "eagerly"
>> (within the creating transaction). There has been suggestions
>> that the ch
Andres Freund escribió:
> Ok, this is helpful. Do you rather longrunning transactions? The
> transaction that does foreign key checks has an xid of 10260613, while
> the row that's getting checked has 13514992.
Thanks for the analysis.
> #4 0x00635dc7 in XactLockTableWait (xid=13514992)
Claudio,
Unfortunately, this UPDATE...FROM approach does not detect ambiguities,
unless we go for tricks.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5780215.html
Sent from the PostgreSQL - hackers mai
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we would have one less
rule to memorize. Th
On 2013-11-25 17:10:39 -0300, Alvaro Herrera wrote:
> > I am not sure whether that's the origin of the problem but at the very
> > least it seems to me that heap_lock_updated_tuple_rec() is missing
> > several important pieces:
> > a) do the priorXmax==xmin dance to check we're still following the
On 11/25/2013 03:42 PM, AK wrote:
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we wou
Andres Freund escribió:
> On 2013-11-25 17:10:39 -0300, Alvaro Herrera wrote:
> > Let me point out that this is exactly the same code that would be
> > affected by my proposed fix for #8434, which would have this check the
> > updateXid in all cases, not only in KEYS_UPDATED as currently.
>
> Hm.
Hi,
When looking at table 8-1 at
http://www.postgresql.org/docs/9.3/static/datatype.html i noticed that
all types except for json was in alphabetical order. I have attached a
patch which fixes this.
By the way should character and character varying be swapped in that
table too?
--
Andreas
AK wrote
> Kevin,
>
> I do see your logic now, but this thing is a common mistake - it means
> that this seems counter-intuitive to some people. What would happen if we
> applied Occam's razor and just removed this rule?
>
> All existing code would continue to work as is, and we would have one le
On 2013-11-25 18:06:30 -0300, Alvaro Herrera wrote:
> > I mean that in the !KEYS_UPDATED case we don't need to abort if we're
> > only acquiring a key share...
>
> Hm, I think that's correct -- we don't need to abort. But we still need
> to wait until the updater completes. So this proposed patc
AK wrote:
> I do see your logic now, but this thing is a common mistake - it
> means that this seems counter-intuitive to some people. What
> would happen if we applied Occam's razor and just removed this
> rule?
>
> All existing code would continue to work as is, and we would have
> one less rul
(sorry for possible duplicates, used wrong account on first try)
On 07.10.2013 17:00, Pavel Stehule wrote:
Hello
I fixed patch - there was a missing cast to domain when it was used (and
all regress tests are ok now).
This doesn't work correctly for varlen datatypes. I modified your
quicksort
Hi!
On Wed, Sep 25, 2013 at 3:14 PM, Stas Kelvich wrote:
> I've fixed split algorithm that was implemented in cube extension. I've
> changed it according to the original Guttman paper (old version was more
> simple algorithm) and also ported Alexander Korotkov's algorithm from box
> datatype inde
Heikki Linnakangas writes:
> In general, I'm not convinced this patch is worth the trouble. The
> speedup isn't all that great; manipulating large arrays in PL/pgSQL is
> still so slow that if you care about performance you'll want to rewrite
> your function in some other language or use tempor
On 26/11/13 09:42, AK wrote:
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we would hav
Alvaro Herrera wrote:
> Andres Freund wrote:
>> That's because HeapTupleHeaderGetUpdateXid() ignores aborted
>> updaters and returns InvalidTransactionId in that case, but
>> HeapTupleSatisfiesVacuum() returns
>> HEAPTUPLE_DELETE_IN_PROGRESS...
> I checked for other cases where the update Xid is
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> Bruce Momjian wrote:
>>
>>> I am not a fan of backpatching any of this.
>>
>> Here's my problem with that. Here's setup to create what I
>> don't think is all that weird a setup:
>>
>> The cluster is created in the state that was dumped, default
>>
On 24.11.2013 18:44, Marko Kreen wrote:
On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
2013/11/22 Marko Kreen
One more thing - please update Python 3 regtests too.
The attached patch (version 3) includes the expected results for Python 3
(file plpython_types_3.out).
Thank
On Fri, 2013-11-22 at 09:54 -0300, Alvaro Herrera wrote:
> Amit Kapila escribió:
> > On Fri, Nov 22, 2013 at 1:33 AM, Alvaro Herrera
> > wrote:
>
> > > \ib homer ~/photos/homer.jpg
> > > insert into people (name, photo) values ('Homer', :homer);
> >
> > Isn't something similar already supported
On Mon, Nov 25, 2013 at 3:07 PM, Andreas Karlsson wrote:
> Hi,
>
> When looking at table 8-1 at
> http://www.postgresql.org/docs/9.3/static/datatype.html i noticed that all
> types except for json was in alphabetical order. I have attached a patch
> which fixes this.
>
> By the way should characte
Mark Kirkwood-2 wrote
> Postgres supports many procedural languages (e.g plperl, plpython) and all
> these have different
> grammar rules from SQL - and from each other. We can't (and shouldn't)
> try altering them to be similar to SQL - it would defeat the purpose of
> providing a procedural en
On 11/25/2013 06:13 PM, David Johnston wrote:
A side observation: why does "DECLARE" not require a block-end keyword but
instead "BEGIN" acts as effectively both start and end? BEGIN, IF, FOR,
etc... all come in pairs but DECLARE does not.
A complete block is:
[ DECLARE declaration
Andrew Dunstan wrote
> On 11/25/2013 06:13 PM, David Johnston wrote:
>>
>> A side observation: why does "DECLARE" not require a block-end keyword
>> but
>> instead "BEGIN" acts as effectively both start and end? BEGIN, IF, FOR,
>> etc... all come in pairs but DECLARE does not.
>>
>>
> A complete b
On 24.11.2013 00:19, Dimitri Fontaine wrote:
Jeff Davis writes:
In the CF app, this is marked "Ready for Committer". That's a bit vague
here, considering Dimitri, you, Peter, and Alvaro are all committers.
Who is this patch waiting on? Is the discussion concluding, or does it
need another round
On 26/11/13 12:13, David Johnston wrote:
Mark Kirkwood-2 wrote
Postgres supports many procedural languages (e.g plperl, plpython) and all
So in the case of plpgsql - it needs to follow the Ada grammar,
otherwise it would be useless.
I do not follow the "useless" conclusion - what, present day
On 11/25/2013 11:52 PM, Merlin Moncure wrote:
On Mon, Nov 25, 2013 at 3:07 PM, Andreas Karlsson wrote:
Hi,
When looking at table 8-1 at
http://www.postgresql.org/docs/9.3/static/datatype.html i noticed that all
types except for json was in alphabetical order. I have attached a patch
which fixe
On Sat, Nov 23, 2013 at 11:52 PM, Peter Geoghegan wrote:
> I have some concerns about what you've done that may limit my
> immediate ability to judge performance, and the relative merits of
> both approaches generally. Now, I know you just wanted to sketch
> something out, and that's fine, but I'm
On Mon, Nov 25, 2013 at 02:24:25PM -0800, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > Kevin Grittner wrote:
> >> Bruce Momjian wrote:
> >>
> >>> I am not a fan of backpatching any of this.
> >>
> >> Here's my problem with that. Here's setup to create what I
> >> don't think is all that weir
On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> > Good points. I have modified the attached patch to do as you suggested.
>
> Also, I have read through the thread and summarized the positions of the
> posters:
>
>
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 24.11.2013 00:19, Dimitri Fontaine wrote:
> >This patch has received extensive review in July and I think it now
> >properly implements the design proposed by Tom and Heikki in 9.3/CF4.
>
> Ok, since my name has been mentioned, I'll bite..
On Sun, Nov 24, 2013 at 9:06 AM, Simon Riggs wrote:
> VACUUM uses 6 bytes per dead tuple. And autovacuum regularly removes
> dead tuples, limiting their numbers.
>
> In what circumstances will the memory usage from multiple concurrent
> VACUUMs become a problem? In those circumstances, reducing
>
On Mon, Jul 22, 2013 at 2:31 PM, Greg Smith wrote:
> On the Mac, the only case that seems to have a slowdown now is "hundred tiny
> fields, half nulled". It would be nice to understand just what is going on
> with that one. I got some ugly results in "two short fields, no change"
> too, along wi
On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
>> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
>> > Good points. I have modified the attached patch to do as you suggested.
>>
>> Also, I have read through the
On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
> On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> > On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> >> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> >> > Good points. I have modified the attac
Kyotaro HORIGUCHI wrote:
> the attched pathkey_and_uniqueindx_v4_20131122.patch is changed as
> follows.
The patch is compiled successfully and passes all regression tests. Also,
the patch works well for the tests shown in an earlier email from
Horiguchi-san. But in this version I found an incor
2013/11/25 Heikki Linnakangas
[...]
> This does change the behavior of any existing functions that return a
> domain over array. For example:
>
> postgres=# create domain intarr as integer[];
> CREATE DOMAIN
> postgres=# create function intarr_test() returns intarr as $$
> return '{1,2}'
> $$ lan
Thank you.
I'll soon come up with regress for the patch 3, 4.
=
> > See commit dd4134ea, which added that text. IIRC, the key point is that
> > among "real" EC members, there will never be duplicates: a Var "x.y"
> > for instance cannot appear in two different ECs, because we'd have merged
>
On Mon, Nov 25, 2013 at 9:17 AM, Rajeev rastogi
wrote:
> On Sat, Nov 9, 2013, Amit Kapila wrote
>
Further Review of this patch:
a. there are lot of trailing whitespaces in patch.
b. why to display 'First log segment after reset' in 'Currrent
pg_control values' section as now the same information
Hello,
> I'll soon come up with regress for the patch 3, 4.
New version patches added with regression tests are attached.
I'll show you pulling-up-in-expand_inherited_rtentry version
later.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/optimizer/plan/
On Tue, 2013-11-26 at 01:37 +0200, Heikki Linnakangas wrote:
> Back in December, when I agreed that "upload zip file via libpq" might
> be useful, Tom suggested that we call control+sql file a "template", and
> the installed entity an "extension".
Simply uploading "safe" extension files (i.e. no
On 25 November 2013 13:37, Etsuro Fujita wrote:
>
> Reconsidering that, I wish to know your opinion. The patch shows the
> number of exact/lossy pages that has been fetched in a bitmap heap scan.
> But the number varies with the fraction of tuples to be retrieved like the
> following.
>
> postgr
72 matches
Mail list logo
