2014-06-17 8:46 GMT+02:00 xbzhang :
> one resource owner per tuples, when error happens, only release resource
> owner belong to error tuple.
> Why some memory structures should be in undefined state? Can you give
> some examples?
>
there can be raised any exception -- any non fatal exception. I
one resource owner per tuples, when error happens, only release resource owner
belong to error tuple.Why some memory structures should be in undefined state?
Can you give some examples?
From: Pavel StehuleDate: 2014-06-17 14:01To: xbzhangCC: Alvaro Herrera;
pgsql-hackersSubject: Re: Re:
2014-06-17 7:30 GMT+02:00 xbzhang :
> Use subtransaction , the tuples that had inserted into heap must be
> inserted again when some exception is raised,
> it is too expensive.
> My solution is :
> 1. delete the tuple that caused the error tuple;
> 2. release all the resources when inserting t
On 06/17/2014 04:19 AM, Jeff Janes wrote:
This commit, or a related one, changed the default (i.e. commented out)
nature of:
#define WAL_DEBUG
Oops. Fixed, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Use subtransaction , the tuples that had inserted into heap must be inserted
again when some exception is raised,it is too expensive.My solution is :1.
delete the tuple that caused the error tuple;2. release all the resources when
inserting the tuple;3. continue insert next tupleIs it feasi
Fujii-san,
I agree not to backpatch, but I noticed that the 9.3 document about
stats collector doesn't mention $PGDATA/pg_stat.
http://www.postgresql.org/docs/current/static/monitoring-stats.html
It just says:
> When the server shuts down, a permanent copy of the statistics data is stored
> in
At 2014-06-17 09:49:35 +0530, amit.kapil...@gmail.com wrote:
>
> By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
> something else, if earlier then I have removed it as per comment from
> Fujji-san.
Yes, what you've done in v3 of the patch is what I meant. I've marked
this as
On Mon, Jun 16, 2014 at 8:56 PM, Tom Lane wrote:
> Not having looked at the patch, but: I think the probability of
> useless-noise HINTs could be substantially reduced if the code prints a
> HINT only when there is a single available alternative that is clearly
> better than the others in Levensht
On Mon, Jun 16, 2014 at 8:38 PM, Ian Barwick wrote:
> I mean, does it come up with a suggestion in every case, even if there is
> no remotely similar column? E.g. would
>
> SELECT foo FROM some_table
>
> bring up column "bar" as a suggestion if "bar" is the only column in
> the table?
Yes, it w
On Mon, Jun 16, 2014 at 7:06 PM, Fujii Masao wrote:
> > Developer options are mainly for debugging information or might help in
one
> > of the situations, so I thought somebody might not want them to be part
of
> > server configuration once they are set. We already disallow parameters
like
> > co
Peter Geoghegan writes:
> On Mon, Jun 16, 2014 at 7:09 PM, Ian Barwick wrote:
>> Howver in this particular use case, as long as it doesn't produce false
>> positives (I haven't looked at the patch) I don't think it would cause
>> any problems (of the kind which would require actively excluding ce
On 14/06/17 11:57, Peter Geoghegan wrote:
> On Mon, Jun 16, 2014 at 7:09 PM, Ian Barwick wrote:
>> Howver in this particular use case, as long as it doesn't produce false
>> positives (I haven't looked at the patch) I don't think it would cause
>> any problems (of the kind which would require acti
On Mon, Jun 16, 2014 at 7:09 PM, Ian Barwick wrote:
> Howver in this particular use case, as long as it doesn't produce false
> positives (I haven't looked at the patch) I don't think it would cause
> any problems (of the kind which would require actively excluding certain
> languages/character se
At 2014-06-13 10:29:24 -0400, t...@sss.pgh.pa.us wrote:
>
> I wonder whether we should just get rid of log_disconnections as a
> separate variable, instead logging disconnections when log_connections
> is set.
I like that idea.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Sat, Jun 14, 2014 at 10:37:36AM -0400, Tom Lane wrote:
> After giving somebody advice, for the Nth time, to install a
> memory-consumption ulimit instead of leaving his database to the tender
> mercies of the Linux OOM killer, it occurred to me to wonder why we don't
> provide a built-in feature
On 14/06/17 9:53, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Jun 17, 2014 at 9:30 AM, Ian Barwick wrote:
>>> From what I've seen in the wild in Japan, Roman/ASCII characters are
>>> widely used for object/attribute names, as generally it's much less
>>> hassle than switching between inp
On 06/17/2014 02:02 AM, Shreesha wrote:
> But I believe, I am looking forward for the exact opposite of it. In
> other words, a possible work around for a root user to execute certain
> executable(s) as an unprivileged user.
>
So you want the su or sudo commands?
--
Craig Ringer
As discussed at the developer meeting at pgCon, I think that there is
a lot to be said for a tool that checks nbtree index invariants on
live systems.
Attached prototype patch adds contrib extension, btreecheck. This
extension provides SQL-callable functions for checking these
conditions on nbtree
On Friday, June 13, 2014, Heikki Linnakangas
wrote:
> As part of the WAL-format changing patch I've been working on, I changed
> the signature of the rm_desc function from:
>
> void (*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
> void (*rm_desc) (StringInfo buf, XLogRecord *record);
>
>
Michael Paquier writes:
> On Tue, Jun 17, 2014 at 9:30 AM, Ian Barwick wrote:
>> From what I've seen in the wild in Japan, Roman/ASCII characters are
>> widely used for object/attribute names, as generally it's much less
>> hassle than switching between input methods, dealing with different
>> en
On Tue, Jun 17, 2014 at 9:30 AM, Ian Barwick wrote:
> From what I've seen in the wild in Japan, Roman/ASCII characters are
> widely used for object/attribute names, as generally it's much less
> hassle than switching between input methods, dealing with different
> encodings etc. The only place whe
Gurjeet Singh writes:
> Please find attached the patch. It includes the doc changes as well.
What exactly is the point of the static state you added here? There
is no situation where that could possibly be useful, because this
code is executed at most once per process, and not at all in the
post
On 14/06/17 8:31, Peter Geoghegan wrote:
> On Mon, Jun 16, 2014 at 4:04 PM, Josh Berkus wrote:
>> Question: How should we handle the issues with East Asian languages
>> (i.e. Japanese, Chinese) and this Hint? Should we just avoid hinting
>> for a selected list of languages which don't work well w
On Sun, Jun 8, 2014 at 09:33:04AM +1200, Gavin Flower wrote:
> I know that I first look at the docs & seldom look at the Wiki - in
> fact it was only recently that I became aware of the Wiki, and it is
> still not the first thing I think of when I want to know something,
> and I often forget it ex
I like this feature but am wondering how to use it. If uses one value across
all backends, we may have to set it conservatively to avoid OOM killer. But
this does not promote resource sharing. If we set it per backend, what's the
suggested value? One may is recommending user sorts his queries to
Robert Haas writes:
> On further review, this is definitely the way to go: it's a
> straight-up win. The isnull array is never more than one element in
> length, so testing the single element is quite trivial. The
> attached, revised patch provides a modest but useful speedup for both
> hash an
On Mon, Jun 16, 2014 at 4:04 PM, Josh Berkus wrote:
> Question: How should we handle the issues with East Asian languages
> (i.e. Japanese, Chinese) and this Hint? Should we just avoid hinting
> for a selected list of languages which don't work well with levenshtein?
> If so, how do we get that
On 04/02/2014 01:16 PM, Andres Freund wrote:
> On 2014-04-02 21:08:47 +0100, Greg Stark wrote:
>> Normally I'm not for adding gucs that just gate new features. But I think a
>> simple guc to turn this on or off would be fine and alleviate any concerns.
>> I think users would appreciate it quite a l
On Wed, Jun 11, 2014 at 12:59 PM, Greg Stark wrote:
> I think this whole exercise has mostly just convinced me we should
> implement an HTTP interface and reimplement psql as a browser app.
I certainly hope not. I've seen lots of browser apps that were nice
enough to use for casual use by a cas
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESPACE
> > MOVE returned ALTER TABLE as a tag, I think it'd work well too; but not
> > ALTER TABLESPACE. Individually, since the implementation works by
> > calling
Robert Haas writes:
> On Sat, Jun 14, 2014 at 10:37 AM, Tom Lane wrote:
>> After giving somebody advice, for the Nth time, to install a
>> memory-consumption ulimit instead of leaving his database to the tender
>> mercies of the Linux OOM killer, it occurred to me to wonder why we don't
>> provid
On Mon, Jun 16, 2014 at 9:08 PM, Robert Haas wrote:
> What happens if the limit is exceeded? ERROR? FATAL? PANIC?
Well presumably it just makes malloc return NULL which causes an
ERROR. One advantage to setting it via a GUC is that it might be
possible to, for example, raise it automatically i
What's the status of this patch?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Kevin Grittner wrote:
> Attached is a WIP patch for implementing the capture of delta
> relations for a DML statement, in the form of two tuplestores --
> one for the old versions and one for the new versions. In the
> short term it is intended to make these relations available in
> trigger functi
On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas wrote:
> So, it seems like we need to do something about this one way or
> another. Who's working on that?
So I'm fine finishing what I started. I've just been a bit busy this past week.
My inclination is to try to push forward and commit this patch,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Fujii Masao writes:
> > That's harmful for audit purpose. I think that we should make
> > log_disconnections PGC_SUSET rather than PGC_BACKEND in order
> > to forbid non-superusers from changing its setting. Attached
> > patch does this.
I tend to agree wi
On Sat, Jun 14, 2014 at 10:37 AM, Tom Lane wrote:
> After giving somebody advice, for the Nth time, to install a
> memory-consumption ulimit instead of leaving his database to the tender
> mercies of the Linux OOM killer, it occurred to me to wonder why we don't
> provide a built-in feature for th
On Wed, Jun 11, 2014 at 10:16 PM, Tom Lane wrote:
> Noah Misch writes:
>> Based on the commit message and procedural history, I thought commit 6513633
>> was changing behavior solely for the combination of "\pset expanded" and
>> "\pset format wrapped". Peter's and my test cases show that it als
I wrote:
> Gurjeet Singh writes:
>> I tried to eliminate the 'pending' list, but I don't see a way around it.
>> We need temporary storage somewhere to store the branches encountered on
>> the right; in recursion case the call stack was serving that purpose.
> I still think we should fix this in
On Tue, Jun 3, 2014 at 4:38 PM, Robert Haas wrote:
> On Sun, Jun 1, 2014 at 3:26 AM, Amit Kapila wrote:
>> On Tue, May 6, 2014 at 12:04 AM, Robert Haas wrote:
>>> On Mon, May 5, 2014 at 2:13 PM, Andres Freund
>>> wrote:
>>> > On 2014-05-05 13:52:39 -0400, Robert Haas wrote:
>>> >> Today, I disc
On Fri, Jun 6, 2014 at 01:18:24PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > I think this is caused because the variable is not defined as SOCKET.
> > > > The attached patch fixes this. Th
* Ronan Dunklau (ronan.dunk...@dalibo.com) wrote:
> The problem with checking if the type is the same is deciding where to stop.
> For composite types, sure it should be easy. But what about built-in types ?
Haven't we already decided to trust these based on server version
information? Look at
Pavel Stehule wrote:
> 2014-06-16 11:46 GMT+02:00 xbzhang :
>
> >
> > I want to implement the skip errors for copy from,lik as :
> > create table A (c int primary key);
> > copy A from stdin;
> > 1
> > 1
> > 2
> > \.
> >
> > copy will failed:
> > ERROR: duplicate key violates primary key constrain
@Craig Ringer, I am afraid I didn't understand your solution.
The scenario I am having is a system which has only user as root. I have
all the permissions and privileges of the system as the user is root. But
pgsql doesn't allow initdb to be executed by root.
I think the solution you proposed gives
@Craig Ringer, I am afraid I didn't understand your solution.
The scenario I am having is a system which has only user as root. I have
all the permissions and privileges of the system as the user is root. But
pgsql doesn't allow initdb to be executed by root.
I think the solution you proposed gives
On Jun 15, 2014, at 1:58 PM, Josh Berkus wrote:
> In other words, what I'm saying is: I don't think there's an existing,
> poplular syntax we could reasonably use.
Okay, I’m good with that. Would be handy to document it in such a way as to
kind of put it forward as a standard. :-)
D
signatu
At 2014-05-30 16:04:33 +0700, the.ap...@gmail.com wrote:
>
> While developing some XML processing queries, i stumbled on an old bug
> mentioned in http://wiki.postgresql.org/wiki/Todo#XML: Fix Nested or
> repeated xpath() that apparently mess up namespaces.
Thanks for the patch, and welcome to Pos
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > Any dump not run by a superuser is already in doubt, imv. That
> > is a problem we already have which really needs to be addressed,
> > but I view that as an independent issue.
>
> I'm not seeing that. If the user can't dump
Hi.
Just a few minor comments about your patch:
At 2014-06-13 11:46:21 +0530, amit.kapil...@gmail.com wrote:
>
> + Notes
> +
> +
> +This command will not allow to set parameters that are disallowed or
> +excluded in postgresql.conf. It also disallows to set configuration
> +paramet
Stephen Frost wrote:
> Kevin Grittner (kgri...@ymail.com) wrote:
>> The proposed approach would leave the validity of any dump which
>> was not run as a superuser in doubt. The last thing we need, in
>> terms of improving security, is another thing you can't do
>> without connecting as a superus
(Cc: to pgsql-bugs dropped.)
At 2014-03-17 18:24:55 +1100, kommi.harib...@gmail.com wrote:
>
> *** a/doc/src/sgml/xfunc.sgml
> --- b/doc/src/sgml/xfunc.sgml
> ***
> *** 153,159 SELECT clean_emp();
> --- 153,186
> (\) (assuming escape string syntax) in the body of
>
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 13 June 2014 01:13, Stephen Frost wrote:
> > This approach was suggested by an existing user testing out this RLS
> > approach, to be fair, but it looks pretty sane to me as a way to address
> > some of these concerns. Certainly open to
On Mon, Jun 16, 2014 at 12:14 PM, Amit Kapila wrote:
> On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg wrote:
>>
>> Re: Amit Kapila 2014-06-13
>>
>> > Agreed, I had mentioned in Notes section of document. Apart from that
>> > I had disallowed parameters that are excluded from postgresql.conf by
(2014/06/14 2:46), Tom Lane wrote:
> Jason Petersen writes:
>> Even if there is no guarantee that `IterateForeignScan` is called exactly
>> once
>> before each `ExecForeignDelete` call (which would remove the ability to have
>> them cooperate using this single cursor), one could easily devise ot
On 2014-06-15 03:12:21 +0200, Andres Freund wrote:
> Hi,
>
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supported platforms would
> be helpful. I'v
> You introduced the state machine using the flag "flush_flg" into
> pg_receivexlog.
> That's complicated and would reduce the readability of the source code.
> I think that the logic should be simpler like walreceiver's one.
>
> Maybe I found one problematic path as follows:
>
> 1. WAL is writte
2014-06-16 11:46 GMT+02:00 xbzhang :
>
> I want to implement the skip errors for copy from,lik as :
> create table A (c int primary key);
> copy A from stdin;
> 1
> 1
> 2
> \.
>
> copy will failed:
> ERROR: duplicate key violates primary key constraint "CC_PKEY"
> CONTEXT: COPY CC, line 2: "1"
>
>
I want to?implement the skip errors for copy from,lik as :create table A (c int
primary key);copy A from stdin;112\.
copy will failed:ERROR: duplicate key violates primary key constraint "CC_PKEY"?
CONTEXT: COPY CC, line 2: "1"
I want skip the error, and continue to copy the reset of tuple
Re: Amit Kapila 2014-06-16
> Developer options are mainly for debugging information or might help in one
> of the situations, so I thought somebody might not want them to be part of
> server configuration once they are set. We already disallow parameters like
> config_file, transaction_isolation
Kaigai-san,
I've just applied v1 patch, and tried build and install, but I found two issues:
1) The contrib/ctidscan is not automatically built/installed because
it's not described in contrib/Makefile. Is this expected behavior?
2) I got an error message below when building document.
$ cd doc/s
On Sat, May 24, 2014 at 5:08 AM, Ronan Dunklau wrote:
> Hello,
>
> Since my last proposal didn't get any strong rebuttal, please find attached a
> more complete version of the IMPORT FOREIGN SCHEMA statement.
>
> I tried to follow the SQL-MED specification as closely as possible.
>
> This adds dis
61 matches
Mail list logo
