On Tue, Nov 19, 2013 at 5:13 AM, Heikki Linnakangas
wrote:
> Ok. Which use case are you targeting during this initial effort, batch
> updates or small OLTP transactions?
OLTP transactions are probably my primary concern. I just realized
that I wasn't actually very clear on that point in my most r
On Sun, Nov 24, 2013 at 4:36 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Fri, Nov 22, 2013 at 9:30 AM, Amit Kapila wrote:
>> Again looking at it, I think better fix would be to restore 'errno'
>> from 'edata->saved_errno' in errfinish() incase the control returns
>> back to caller (elevel <=
Sawada Masahiko writes:
> On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin wrote:
>>> I was using the lo contrib a few days ago and wasn't paying attention, and
>>> forgot the "for each row" in the create trigger command... PostgreSQL
>>> segfaulted, when the trigger tried to access the row's attribu
On Wed, 2013-09-25 at 12:31 +0300, Heikki Linnakangas wrote:
> On 19.09.2013 16:24, Andres Freund wrote:
> ...
> > There's probably more.
I think _bt_check_unique is also a problem.
> Hmm, some of those are trivial, but others, rewrite_heap_tuple() are
> currently only passed the HeapTuple, with
Rajeev rastogi writes:
> 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 the executable name, b
I have committed the PL/Tcl part.
I'll work on the PL/Perl part next.
I believe we're still waiting on something from you for PL/Python.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 18, 2013 at 1:54 AM, Sameer Thakur wrote:
> Please find v10 of patch attached. This patch addresses following
> review comments
I've cleaned this up - revision attached - and marked it "ready for committer".
I decided that queryid should be of type oid, not bigint. This is
arguably a
On Wed, 2013-11-20 at 22:41 +0900, Michael Paquier wrote:
> Here are a couple of comments about the patch:
> 1) I think that you should regenerate ./configure as well with this
> patch to include all the changes together (someone correct me if I am
> wrong here!)
Doesn't matter either way.
> 2) T
On 10/15/2013 07:50 AM, David Fetter wrote:
> On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote:
>> Folks,
>>
>> Please find attached a patch implementing and documenting, to some
>> extent, $subject. I did this in aid of being able to import SQL
>> standard catalogs and other entities
On Sat, Nov 23, 2013 at 4:21 PM, Jeremy Harris wrote:
> Its performance shines on partially- or reverse-sorted input.
Search the archives for the work I did on timsort support a while
back. A patch was posted, that had some impressive results provided
you just considered the number of comparisons
On 20/11/13 19:58, Robert Haas wrote:
Parallel sort, and then parallel other stuff. Eventually general
parallel query.
I have recently updated https://wiki.postgresql.org/wiki/Parallel_Sort
and you may find that interesting/helpful as a statement of intent.
I've been playing with an internal
Hi,
The attached pgbench testcase can reproduce two issues:
1) (takes a bit)
TRAP: FailedAssertion("!(((xid) >= ((TransactionId) 3)))", File:/pruneheap.c",
Line: 601)
That's because HeapTupleHeaderGetUpdateXid() ignores aborted updaters
and returns InvalidTransactionId in that case, but
HeapTupl
Amit Kapila writes:
> On Fri, Nov 22, 2013 at 9:30 AM, Amit Kapila wrote:
>> I could think of below possible ways to fix the problem:
>> a. in function pvsnprintf(), save the errno before setting it to 0 and
>> then before exiting function reset it back to saved errno. I think
>> this is sane bec
Hi,
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 of review?
Thanks for the confusi
On Mon, 2013-11-04 at 08:43 -0500, Stephen Frost wrote:
> I'll still go ahead and start looking through this, per our discussion.
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 Sun, Nov 24, 2013 at 6:37 AM, Kevin Grittner wrote:
> David Rowley wrote:
>
> > I've just had a look at both of these patches. All tests that
> > have been added seem to cover new areas that are not previously
> > tested, they also seem to cleanup properly after themselves, so I
> > think the
On Mon, 2013-05-13 at 15:22 -0700, Peter Geoghegan wrote:
> On Tue, May 7, 2013 at 7:01 PM, Tom Lane wrote:
> > It seems reasonable to me to reduce it to DEBUG1 level.
>
> Attached patch renders all "loaded library..." messages DEBUG1,
> regardless of whether local_preload_libraries or
> shared_p
Because of the recently discovered data-corruption-on-replication-slaves
bug, we're going to put out new minor releases for the back branches.
The plan is to wrap tarballs Monday Dec 2 for public announcement Thursday
Dec 5. We considered doing it this coming week instead, but that seems
impractic
On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 1:02 AM, Sawada Masahiko
> wrote:
> > I attached patch adds new wal_level 'all'.
> > If wal_level is set 'all', the server logs WAL not only when wal_level
> > is set 'hot_standby' ,but also when updating hint bit.
>
Boszormenyi Zoltan 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 be determined internally even if neither is
> asked exp
Am Samstag, 23. November 2013, 08:44:42 schrieb Kevin Grittner:
> 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:
>
> initdb Debug/data
> pg_ctl -D Debug/data -l Debug/da
Noah Misch writes:
> I'm unclear on the key ideas behind distinguishing em_is_child members from
> ordinary EC members. src/backend/optimizer/README says "These members are
> *not* full-fledged members of the EquivalenceClass and do not affect the
> class's overall properties at all." Is that an
On Tue, Nov 19, 2013 at 10:16 AM, J Smith wrote:
> Alright, we'll look into doing that heading into the weekend.
> Interestingly, we haven't experienced the issue since our main Java
> developer made some modifications to our backend system. I'm not
> entirely sure what the changes entail except t
David Rowley wrote:
> I've just had a look at both of these patches. All tests that
> have been added seem to cover new areas that are not previously
> tested, they also seem to cleanup properly after themselves, so I
> think these should be a worthwhile addition to the regression
> tests.
Thank
On Sat, Nov 23, 2013 at 12:11:56PM -0500, Tom Lane wrote:
> I also agree with *not* changing pg_dump, since it is not the charter
> of pg_dump to recreate a whole cluster, and the objection about possibly
> restoring into a database that was meant to be protected by this setting
> seems to have so
Kevin Grittner writes:
> Bruce Momjian wrote:
>> I am not a fan of backpatching any of this.
> Are you saying that you find current behavior acceptable in back
> branches?
I'm inclined to agree with Kevin that this behavior is wrong and
should be fixed (and back-patched), so far as pg_dumpall i
On Sat, Nov 23, 2013 at 08:44:42AM -0800, Kevin Grittner wrote:
> Here's my problem with that. Here's setup to create what I don't
> think is all that weird a setup:
...
> The following appears to produce a good backup, since there is no
> error:
...
> Now we attempt to restore what we though
Peter Eisentraut writes:
> On Fri, 2013-11-22 at 23:32 +, Greg Stark wrote:
>> Debian policy is to always use -fPIC
> My point is, they compile the *backend* as position-independent code.
> The backend is not a shared library. Maybe it is in Postgres-XC? But
> at least this makes their buil
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:
initdb Debug/data
pg_ctl -D Debug/data -l Debug/data/logfile -w start
createdb test
psql test /dev/null 2>&1
psql postgres -c "al
On Fri, Nov 22, 2013 at 04:38:53PM -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
> >> Oddly, it didn't complain about creating users within a read-only
> >> transaction. That seems like a potential bug.
> >
> > There's lots of things t
On Fri, Nov 22, 2013 at 04:25:57PM -0800, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
> >
> >> It does nothing about pg_upgrade, which is sort of a separate
> >> issue. My inclination is that connections to the new cluster
> >>
On Fri, 2013-11-22 at 23:32 +, Greg Stark wrote:
> According to the Debian build logs, postgres-xc compiles the
> entire
> backend with -fPIC. Not sure what sense that makes.
>
>
> Debian policy is to always use -fPIC
My point is, they compile the *backend* as positi
23.11.2013 14:12, Mario Weilguni kirjoitti:
Am 22.11.2013 16:15, schrieb Tom Lane:
[ memo to self: never, ever accept another contrib module whose name
isn't a plain SQL identifier ]
Well, in that case and since this is a rarely used extension (I guess
so), maybe it would be the best to simply
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).
diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.out
index
On 11/23/2013 01:12 PM, Mario Weilguni wrote:
> Am 22.11.2013 16:15, schrieb Tom Lane:
>> [ memo to self: never, ever accept another contrib module whose name
>> isn't a plain SQL identifier ]
>
> Well, in that case and since this is a rarely used extension (I guess
> so), maybe it would be the bes
Am 22.11.2013 16:15, schrieb Tom Lane:
[ memo to self: never, ever accept another contrib module whose name
isn't a plain SQL identifier ]
Well, in that case and since this is a rarely used extension (I guess
so), maybe it would be the best to simply rename that extension to
uuidossp (or what
On Wed, Oct 9, 2013 at 2:12 AM, Marc Cousin wrote:
> On Tuesday 08 October 2013 12:28:46 Robert Haas wrote:
>> On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin wrote:
>> > I was using the lo contrib a few days ago and wasn't paying attention, and
>> > forgot the "for each row" in the create trigger c
On Thu, Oct 24, 2013 at 9:59 PM, Haribabu kommi
wrote:
>
>
> Here I have added some more regression tests to improve the missing
> function coverage of
>
> schemacmds.c, user.c and tablespace.c.
>
>
>
> The added tests are mainly RENAME TO and OWNER TO support.
>
>
I've just had a look at both of
On 11/21/2013 10:39 PM, Peter Eisentraut wrote:
> On 11/21/13, 2:09 AM, Pavel Stehule wrote:
>> I wrote new styles for psql table borders.
>>
>> http://postgres.cz/wiki/Pretty_borders_in_psql
>>
>> This patch is simply and I am think so some styles can be interesting
>> for final presentation.
>>
20.11.2013 23:38, Robert Haas kirjoitti:
On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa wrote:
ISTM autoconf has been better with backwards compatibility lately. Maybe the
fatal error could be changed to a warning and/or the check for version ==
2.63 be replaced with a check for version >= 2
Have a look at
On Sat, Nov 23, 2013 at 3:48 PM, mohsen soodkhah mohammadi
wrote:
> in copy.c is one function that its name is CopyOneRowTO.
> in this function have one foreach loop. in this loop first if have this
> condition: !cstate->binary
> what means this condition and when true this conditi
41 matches
Mail list logo
