Peter Eisentraut writes:
> Start here:
> http://developer.postgresql.org/pgdocs/postgres/plhandler.html
> I notice that this has not been updated for the new inline handlers, but
> that shouldn't stop you.
Actually, that chapter is so old it didn't get updated for language
validators either :-(.
On Wed, Oct 7, 2009 at 10:41 PM, Jeff Janes wrote:
>> I don't really see what's wrong with using Perl modules that are
>> likely to be installed most places and easy to obtain where not, if it
>> makes writing a test framework much easier. But I also think that we
>> should not get bogged down on
2009/10/8 Tom Lane :
> Pavel Stehule writes:
>> [ latest named-args patch ]
>
> Committed with a fair amount of corner-case cleanup and refactoring.
>
> regards, tom lane
>
Thank you
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Heikki Linnakangas wrote:
> I've made public the version I'm working on. That's the version I'm
> ultimately going to commit. It would be a lot more helpful if you
> provided these patches over that version. Otherwise I have to refactor
> them over that codebase, possibly introducing new bugs.
Act
Simon Riggs wrote:
> On Tue, 2009-09-22 at 12:53 +0300, Heikki Linnakangas wrote:
>> It looks like the standby tries to remove XID 4323 from the
>> known-assigned hash table, but it's not there because it was removed
>> and set in pg_subtrans by an XLOG_XACT_ASSIGNMENT record earlier. I
>> guess we
Andrew Chernow wrote:
u235sentinel wrote:
So I compiled postgres with Solaris 10 and have problems running it.
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
Maybe l
Andrew Chernow writes:
> u235sentinel wrote:
>> So I compiled postgres with Solaris 10 and have problems running it.
>>
>> # ./pg_ctl
>> ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
>> /usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
>> 0xfd7fff1cf210 does not fit
On Wed, Oct 7, 2009 at 5:33 PM, David E. Wheeler wrote:
> On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
>
>> I'd much rather live without Test::More and use DBD::Pg, then have
>> Test::More but need to open pipes to psql to talk to the database,
>> rather than using DBI to do it. But I guess we w
On Wed, Oct 7, 2009 at 6:01 PM, Robert Haas wrote:
> On Wed, Oct 7, 2009 at 8:33 PM, David E. Wheeler wrote:
>>> Do we need to restrict ourselves to core? Developers already need
>>> flex and bison, which aren't needed when installing from the tarball.
>>> Couldn't we also have "make dev-check"
Pavel Stehule writes:
> [ latest named-args patch ]
Committed with a fair amount of corner-case cleanup and refactoring.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Fri, Sep 25, 2009 at 10:01 AM, Emmanuel Cecchet wrote:
> Robert,
>
> Here is the new version of the patch that applies to CVS HEAD as of this
> morning.
>
> Emmanuel
I took a look at this patch tonight and, having now read through some
of it, I have some more detailed comments.
It seems quite
u235sentinel wrote:
So I compiled postgres with Solaris 10 and have problems running it.
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
Maybe libpq.so wasn't built wi
David E. Wheeler wrote:
On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
I'd much rather live without Test::More and use DBD::Pg, then have
Test::More but need to open pipes to psql to talk to the database,
rather than using DBI to do it. But I guess we would need to worry
about whether we can
So I compiled postgres with Solaris 10 and have problems running it.
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
# ldd pg_ctl
libpq.so.5 =>/usr/local/postgr
On Wed, Oct 7, 2009 at 7:52 PM, Greg Smith wrote:
> On Wed, 7 Oct 2009, Robert Haas wrote:
>
>> On Wed, Oct 7, 2009 at 3:17 AM, Greg Smith wrote:
>>
>>> I doubt taskmaster Robert is going to let this one linger around with
>>> scope creep for too long before being pushed out to the next CommitFes
On Wed, Oct 7, 2009 at 8:33 PM, David E. Wheeler wrote:
>> Do we need to restrict ourselves to core? Developers already need
>> flex and bison, which aren't needed when installing from the tarball.
>> Couldn't we also have "make dev-check" that has higher requirements
>> than "make check" does, b
Greg Smith wrote:
On Wed, 7 Oct 2009, Michael Renner wrote:
I haven't thought about result aggregation & rendering/UI part of the
whole thing so far, so if anyone has some ideas in that direction
they'd be very much appreciated when the time has come.
What I did in pgbench-tools (now availab
On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
I'd much rather live without Test::More and use DBD::Pg, then have
Test::More but need to open pipes to psql to talk to the database,
rather than using DBI to do it. But I guess we would need to worry
about whether we can make DBD::Pg work with the
On Wed, 7 Oct 2009, Michael Renner wrote:
I haven't thought about result aggregation & rendering/UI part of the whole
thing so far, so if anyone has some ideas in that direction they'd be very
much appreciated when the time has come.
What I did in pgbench-tools (now available at http://git.po
On Wed, Oct 7, 2009 at 10:38 AM, David Fetter wrote:
> On Wed, Oct 07, 2009 at 10:28:08AM -0700, David Wheeler wrote:
>> On Oct 7, 2009, at 9:53 AM, David Fetter wrote:
>>
>>> At the moment, we have no way to test this, although with certain
>>> Perl modules, it would be pretty trivial.
>>
>> No n
Kiswono Prayogo escribió:
> i guess v8 still the best javascript interpreter
> http://waynepan.com/2008/09/02/v8-tracemonkey-squirrelfish-ie8-benchmarks/
> nitro from apple safari would be the second best..
> http://www.computerworld.com/s/article/9128638/Safari_4_rivals_Google_Chrome_in_JavaScrip
On Wed, Oct 07, 2009 at 08:06:50PM -0400, Greg Smith wrote:
> On Wed, 7 Oct 2009, Alvaro Herrera wrote:
>
>> I don't find this a compelling argument against concurrent psql.
>> Sure there are things you can't do with it, but it doesn't mean
>> it's not useful. Are we going to need further tools to
On Thu, 2009-10-08 at 07:06 +0700, Kiswono Prayogo wrote:
> > Said slides are available here:
> > http://www.pgcon.org/2009/schedule/events/159.en.html
> >
> > I hope they can be useful.
> >
> > --
> > Joshua Tolley / eggyknap
>
> ok i will read it, thanks ^^
And video:
http://www.vimeo.com/3728
On Wed, 7 Oct 2009, Alvaro Herrera wrote:
I don't find this a compelling argument against concurrent psql. Sure
there are things you can't do with it, but it doesn't mean it's not
useful. Are we going to need further tools to find "the good concurrent
bugs"? No doubt.
Don't get me wrong, I
> Said slides are available here:
> http://www.pgcon.org/2009/schedule/events/159.en.html
>
> I hope they can be useful.
>
> --
> Joshua Tolley / eggyknap
ok i will read it, thanks ^^
On Wed, Oct 7, 2009 at 11:18 PM, David E. Wheeler wrote:
> On Oct 7, 2009, at 7:55 AM, Andrew Dunstan wrote:
>
>
On Wed, 7 Oct 2009, Robert Haas wrote:
On Wed, Oct 7, 2009 at 3:17 AM, Greg Smith wrote:
I doubt taskmaster Robert is going to let this one linger around with
scope creep for too long before being pushed out to the next
CommitFest.
I'm can't decide whether to feel good or bad about that ap
On Wed, 7 Oct 2009, Emmanuel Cecchet wrote:
I think there is a misunderstanding about what the current patch is
about...the patch does NOT include logging errors into a file (a feature
we can add later on (next commit fest?))
I understand that (as one of the few people who has read the patch
Jeff Davis writes:
>> We could possibly have VARIADIC throw an error if the
>> named argument that matches to the variadic parameter isn't the last
>> one, but I'm not sure that that's important rather than just pedantry.
> I would prefer such a restriction if it's reasonable to do.
[ pokes arou
On Wed, Oct 7, 2009 at 5:45 PM, Tom Lane wrote:
> I think what he was considering was the question of insisting that
> the VARIADIC keyword be attached to the named argument that actually
> matches the VARIADIC parameter. I think we could do it, but it might
> be a bit of a wart. I notice that r
On Wed, 2009-10-07 at 18:17 -0400, Tom Lane wrote:
> No, that's not what I'm driving at. The small change that I've got in
> mind would require you to say VARIADIC, but it would allow the function
> to match both the above call and
> foo(a AS x, c AS z, VARIADIC b AS y)
> when really z is the
2009/10/7 Jeff Davis :
> On Wed, 2009-10-07 at 23:32 +0200, Pavel Stehule wrote:
>> It's same as my origin ideas, much better formulated. It is ok for me.
>
> You indicated that there may be some implementation difficulty if the
> VARIADIC keyword is required for calling using named notation:
>
> h
2009/10/8 Tom Lane :
> Jeff Davis writes:
>> On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
>>> I think what he was considering was the question of insisting that
>>> the VARIADIC keyword be attached to the named argument that actually
>>> matches the VARIADIC parameter.
>
>> It seems strange
Alvaro Herrera wrote:
> Log Message:
> ---
> psql has gained a \drds command to display the settings.
And, of course, I only noticed after the commit that it's not listed in
\?.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consul
Jeff Davis writes:
> On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
>> I think what he was considering was the question of insisting that
>> the VARIADIC keyword be attached to the named argument that actually
>> matches the VARIADIC parameter.
> It seems strange to me if we have a situation
On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
> I think what he was considering was the question of insisting that
> the VARIADIC keyword be attached to the named argument that actually
> matches the VARIADIC parameter. I think we could do it, but it might
> be a bit of a wart. I notice that
2009/10/7 Peter Eisentraut :
> On Sun, 2009-10-04 at 22:07 -0400, Tom Lane wrote:
>> In short: while I haven't looked at the patch, I think Peter may be
>> steering you in the wrong direction.
>>
>> In cases where you do have related functions, I suggest having
>> SQL-callable V1 functions that abs
On Wed, 2009-10-07 at 23:32 +0200, Pavel Stehule wrote:
> It's same as my origin ideas, much better formulated. It is ok for me.
You indicated that there may be some implementation difficulty if the
VARIADIC keyword is required for calling using named notation:
http://archives.postgresql.org/pgsq
Jeff Davis writes:
> If we allow calling a variadic function using named notation, the
> VARIADIC keyword is not strictly necessary, but I think we should
> require it. It seems strange without it.
Yeah. My first thought was to just remove the check in
FuncnameGetCandidates, which would have the
On Wed, 2009-10-07 at 16:58 -0400, Tom Lane wrote:
> * completely ignores variadic functions when trying to match
> a call having any named arguments
>
> * does not throw an error for use of the VARIADIC keyword
> in a call together with named arguments
>
> Neither of
2009/10/7 Tom Lane :
> Pavel Stehule writes:
>>> Sorry, I'm having trouble understanding what you're driving at here.
>>> I think we should just not allow named notation to be combined with
>>> VARIADIC, at least for a first version of this feature, either when
>>> defining a function or when call
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
wrote:
Right. This is exactly what I'm trying to do, except I think we could
easily optimize this case and store only the first processed row inside
the CTE.
why? we don't should be thinking in optimizations in this phase
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
wrote:
> Jaime Casanova wrote:
>>
>> On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
>> wrote:
>>>
>>> 1) WITH t AS
>>> (UPDATE foo SET bar = bar+1 RETURNING *)
>>> SELECT * FROM t LIMIT 1;
>>>
>>> What's problematic here is that only
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
wrote:
1) WITH t AS
(UPDATE foo SET bar = bar+1 RETURNING *)
SELECT * FROM t LIMIT 1;
What's problematic here is that only 1 row is read from the CTE, meaning
also that only one row is updated which, at lea
On Tuesday 06 October 2009 11:35:03 Roger Leigh wrote:
> On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> > On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > > Roger Leigh writes:
> > > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > > >> Elsewhere
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
wrote:
>
> 1) WITH t AS
> (UPDATE foo SET bar = bar+1 RETURNING *)
> SELECT * FROM t LIMIT 1;
>
> What's problematic here is that only 1 row is read from the CTE, meaning
> also that only one row is updated which, at least how I see
I've made progress in implementing writeable CTEs (repo at
git://git.postgresql.org/git/writeable_cte.git , branch actually_write)
and I've hit a few corner-cases which have lead me to think that we
should be handling DML inside CTEs a bit differently. Before I go on
implementing this, I'd like t
Pavel Stehule writes:
>> Sorry, I'm having trouble understanding what you're driving at here.
>> I think we should just not allow named notation to be combined with
>> VARIADIC, at least for a first version of this feature, either when
>> defining a function or when calling one. Â We can consider
David Fetter wrote:
Folks,
As we move forward, we run into increasingly complex situations under
the general rubric of concurrency.
What test frameworks are already out there that we can use in our
regression test suite? If there aren't any, how might we build one?
Not entirely on-topic, but
Greg Smith wrote:
> On Wed, 7 Oct 2009, Alvaro Herrera wrote:
>
> >Yeah, the API they implemented wasn't ideal, so there was some
> >discussion that ended up with a specification everyone was happy with,
> >but then nobody got around to implementing it.
>
> I needed something like this and didn't
On Wed, 7 Oct 2009, Alvaro Herrera wrote:
Yeah, the API they implemented wasn't ideal, so there was some
discussion that ended up with a specification everyone was happy with,
but then nobody got around to implementing it.
I needed something like this and didn't implement those suggestions
be
On Oct 7, 2009, at 10:38 AM, David Fetter wrote:
When did Test::More become core? I believe we support back to Perl
5.6 :/
Module::CoreList says 5.006002, though I would have sworn it was added
much earlier than that. You could always use Test.pm, I suppose, which
has been in core since 5
On Wed, Oct 07, 2009 at 10:28:08AM -0700, David Wheeler wrote:
> On Oct 7, 2009, at 9:53 AM, David Fetter wrote:
>
>> At the moment, we have no way to test this, although with certain
>> Perl modules, it would be pretty trivial.
>
> No non-core modules necessary. Just use Test::More and file handle
On Oct 7, 2009, at 9:53 AM, David Fetter wrote:
At the moment, we have no way to test this, although with certain Perl
modules, it would be pretty trivial.
No non-core modules necessary. Just use Test::More and file handles
opened via pipes to two or more psql sessions.
Best,
David
--
Se
I've started looking at the following TODO item:
"Improve deferrable unique constraints for cases with many conflicts"
and Tom's suggestion that the rows to be checked can be stored in a
bitmap, which would become lossy when the number of rows becomes large
enough. There is also another TODO it
David Fetter wrote:
> I seem to recall that there were some patches to get psql to help with
> such things, but they didn't go in. Time to revive them?
Yeah, the API they implemented wasn't ideal, so there was some
discussion that ended up with a specification everyone was happy with,
but then n
On Wed, Oct 07, 2009 at 11:29:15AM -0400, Alvaro Herrera wrote:
> Joshua Tolley escribió:
> > On Wed, Oct 07, 2009 at 10:22:02AM -0400, Alvaro Herrera wrote:
> > > Kiswono Prayogo escribió:
> > > > by using latest v8 engine from google, is it possible to build PL/Js
> > > > just like other PL in Po
On Wed, Oct 07, 2009 at 09:17:52AM -0700, David Fetter wrote:
> Folks,
>
> As we move forward, we run into increasingly complex situations under
> the general rubric of concurrency.
>
> What test frameworks are already out there that we can use in our
> regression test suite? If there aren't any
On Wed, Oct 7, 2009 at 5:00 AM, Kiswono Prayogo wrote:
> by using latest v8 engine from google, is it possible to build PL/Js
> just like other PL in Postgre? such as PL/PHP
> what should i learn if i want to build PL/Js?
> thanks in advance.
>
> regards,
> Kis
> GB
>
>
You also can see this link
On Wed, Oct 7, 2009 at 11:45 AM, Emmanuel Cecchet wrote:
> You are suggesting then that it is the COPY command that aborts the
> transaction. That would only happen if you had set a limit on the number of
> errors that you want to accept in a COPY command (in which case you know
> that there is so
On Oct 7, 2009, at 7:55 AM, Andrew Dunstan wrote:
BTW I've seen requests for PL/Js so I'm sure it'll be welcome. What
license is v8 under?
It's a BSD license, but it's a C++ API. While it looks cool, I think
SpiderMonkey is possibly a better bet.
SquirrelFish? http://webkit.org/blog/189/a
Folks,
As we move forward, we run into increasingly complex situations under
the general rubric of concurrency.
What test frameworks are already out there that we can use in our
regression test suite? If there aren't any, how might we build one?
Cheers,
David.
--
David Fetter http://fetter.or
Greg Smith wrote:
Absolutely, that's the whole point of logging to a file in the first
place. What needs to happen here is that when one is aborted, you
need to make sure that fact is logged, and with enough information
(the pid?) to tie it to the COPY that failed. Then someone can crawl
the
Robert Haas wrote:
On Wed, Oct 7, 2009 at 11:39 AM, Emmanuel Cecchet wrote:
Robert Haas wrote:
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet
wrote:
Hi all,
I think there is a misunderstanding about what the current patch is
about.
The patch includes 2 things:
- error logg
The roadmap I would propose for the current list of enhancements to COPY
is as follows:
1. new syntax for COPY options (already committed)
2. error logging in a table
3. auto-partitioning (just relies on basic error logging, so can be
scheduled anytime after 2)
4. error logging in a file
manu
On Wed, Oct 7, 2009 at 11:39 AM, Emmanuel Cecchet wrote:
> Robert Haas wrote:
>>
>> On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet
>> wrote:
>>
>>>
>>> Hi all,
>>>
>>> I think there is a misunderstanding about what the current patch is
>>> about.
>>> The patch includes 2 things:
>>> - error log
Robert Haas wrote:
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet wrote:
Hi all,
I think there is a misunderstanding about what the current patch is about.
The patch includes 2 things:
- error logging in a table for bad tuples in a COPY operation (see
http://wiki.postgresql.org/wiki/Error
>
> I think Josh Tolley has some slides on how we built PL/LOLCODE that
> could prove useful.
>
> BTW I've seen requests for PL/Js so I'm sure it'll be welcome. What
> license is v8 under?
>
>
the new BSD License
http://code.google.com/p/v8/
--
GHUM Harald Massa
persuadere et programmare
Haral
Joshua Tolley escribió:
> On Wed, Oct 07, 2009 at 10:22:02AM -0400, Alvaro Herrera wrote:
> > Kiswono Prayogo escribió:
> > > by using latest v8 engine from google, is it possible to build PL/Js
> > > just like other PL in Postgre? such as PL/PHP
> > > what should i learn if i want to build PL/Js?
On Wed, Oct 07, 2009 at 10:22:02AM -0400, Alvaro Herrera wrote:
> Kiswono Prayogo escribió:
> > by using latest v8 engine from google, is it possible to build PL/Js
> > just like other PL in Postgre? such as PL/PHP
> > what should i learn if i want to build PL/Js?
>
> I think Josh Tolley has some
On Wed, 2009-10-07 at 16:34 +0200, Gnanam wrote:
> NOTE: I've seen "deadlock" errors in UPDATE statement but why it is throwing
> in INSERT statements.
It is because of the foreign key. Inserting a child row will lock the
corresponding parent row, and if you insert multiple rows with different
par
On Wed, Oct 7, 2009 at 10:34 AM, Gnanam wrote:
>
> Hi,
>
> We've a web-based application.
> We are trying to do concurrency testing, Three person doing same operation
> on different data.
>
> I'm facing the following deadlock error thrown by PostgreSQL:
>
> org.postgresql.util.PSQLException: ERROR
Alvaro Herrera wrote:
Kiswono Prayogo escribió:
by using latest v8 engine from google, is it possible to build PL/Js
just like other PL in Postgre? such as PL/PHP
what should i learn if i want to build PL/Js?
I think Josh Tolley has some slides on how we built PL/LOLCODE that
could p
Tom Lane wrote:
Andrew Dunstan writes:
Emmanuel Cecchet wrote:
If you prefer to postpone the auto-partitioning to the next commit
fest, I can strip it from the current patch and re-submit it for the
next fest (but it's just 2 isolated methods really easy to review).
I ce
Hi,
We've a web-based application.
We are trying to do concurrency testing, Three person doing same operation
on different data.
I'm facing the following deadlock error thrown by PostgreSQL:
org.postgresql.util.PSQLException: ERROR: deadlock detected
Detail: Process 13560 waits for ShareLock
Andrew Dunstan writes:
> Emmanuel Cecchet wrote:
>> If you prefer to postpone the auto-partitioning to the next commit
>> fest, I can strip it from the current patch and re-submit it for the
>> next fest (but it's just 2 isolated methods really easy to review).
> I certainly think this should b
On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote:
> we need be careful to avoid putting any extra work into the normal
> recovery path. Otherwise bugs in hot standby related code can cause
> crash recovery to fail.
Re-checked code and found a couple of additional places that needed
tes
Kiswono Prayogo escribió:
> by using latest v8 engine from google, is it possible to build PL/Js
> just like other PL in Postgre? such as PL/PHP
> what should i learn if i want to build PL/Js?
I think Josh Tolley has some slides on how we built PL/LOLCODE that
could prove useful.
BTW I've seen re
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet wrote:
> Hi all,
>
> I think there is a misunderstanding about what the current patch is about.
> The patch includes 2 things:
> - error logging in a table for bad tuples in a COPY operation (see
> http://wiki.postgresql.org/wiki/Error_logging_in_CO
On Wed, 2009-10-07 at 15:33 +0200, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > It will be best to have the ability to have a specific rejection reason
> > for each row rejected. That way we will be able to tell the difference
> > between uniqueness violation errors, invalid date format on c
On Tue, 2009-09-22 at 12:53 +0300, Heikki Linnakangas wrote:
> It looks like the standby tries to remove XID 4323 from the
> known-assigned hash table, but it's not there because it was removed
> and set in pg_subtrans by an XLOG_XACT_ASSIGNMENT record earlier. I
> guess we should just not throw a
Simon Riggs writes:
> It will be best to have the ability to have a specific rejection reason
> for each row rejected. That way we will be able to tell the difference
> between uniqueness violation errors, invalid date format on col7, value
> fails check constraint on col22 etc..
In case that he
Emmanuel Cecchet wrote:
If you prefer to postpone the auto-partitioning to the next commit
fest, I can strip it from the current patch and re-submit it for the
next fest (but it's just 2 isolated methods really easy to review).
I certainly think this should be separated out. In general it
Hi all,
I think there is a misunderstanding about what the current patch is about.
The patch includes 2 things:
- error logging in a table for bad tuples in a COPY operation (see
http://wiki.postgresql.org/wiki/Error_logging_in_COPY for an example;
the error message, command and so on are autom
On Fri, 2009-10-02 at 10:32 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I will docuemnt the recommendation to set max_standby_delay = 0 if
> > performing an archive recovery (and explain why).
>
> Hmm, not sure if that's such a good piece of advice either. It will mean
> waiting for
On Wed, Oct 7, 2009 at 3:17 AM, Greg Smith wrote:
> I know this patch is attracting more reviewers lately, is anyone tracking
> the general architecture of the code yet? Emmanuel's work is tough to
> review just because there's so many things mixed together, and there's other
> inputs I think sho
On Wed, 2009-10-07 at 03:17 -0400, Greg Smith wrote:
> On Mon, 5 Oct 2009, Josh Berkus wrote:
>
> Also, presumbly, if you abort a COPY because of errors, you
> > probably want to keep the errors around for later analysis. No?
>
> Absolutely, that's the whole point of logging to a file in the f
On Mon, Oct 05, 2009 at 02:23:57PM +0200, Boszormenyi Zoltan wrote:
> Noah Misch ?rta:
> I will post a new patch for SQLDA and for all others that need
> updating.
Thanks; that one does apply cleanly.
> > The main test suite acquired no regressions, but I get failures in two
> > tests of
> > th
On Wed, 2009-10-07 at 15:00 +0700, Kiswono Prayogo wrote:
> by using latest v8 engine from google, is it possible to build PL/Js
> just like other PL in Postgre? such as PL/PHP
> what should i learn if i want to build PL/Js?
Start here:
http://developer.postgresql.org/pgdocs/postgres/plhandler.ht
by using latest v8 engine from google, is it possible to build PL/Js
just like other PL in Postgre? such as PL/PHP
what should i learn if i want to build PL/Js?
thanks in advance.
regards,
Kis
GB
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Mon, 5 Oct 2009, Josh Berkus wrote:
I think that this was the original idea but we should probably rollback
the error logging if the command has been rolled back. It might be more
consistent to use the same hi_options as the copy command. Any idea what
would be best?
Well, if we're logging
90 matches
Mail list logo
