Hello
do you plan do some work on this job?
Regards
Pavel Stehule
2010/11/26 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of vie nov 26 07:37:42 -0300 2010:
>> Hello
>>
>> there is difficult working with exception still. Isn't time to move forward?
>>
>> http://archives.postgresql.o
Bruce Momjian writes:
> Tom Lane wrote:
>> PQping is supposed to be smarter about classifying errors
>> than this.
> I was not aware this was discussed last week because I am behind on
> email. I was fixing a report from a month ago. I did explain how I was
> doing the tests.
Um, you did respo
On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
>> On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
>>> So I've been working on improving locks for foreign key checks, as
>>> discussed in a thread started by Joel Jacobson a
Josh Berkus wrote:
> On 11/20/10 6:11 PM, Jeff Janes wrote:
>> True, but I think that changing these from their defaults is not
>> considered to be a dark art reserved for kernel hackers, i.e they are
>> something that sysadmins are expected to tweak to suite their work
>> load, just like the shmma
Excerpts from Fujii Masao's message of jue nov 25 10:47:12 -0300 2010:
> The attached patch s/CopyXLog/CopyBoth/g and adds the description
> about CopyBoth into the COPY section.
I gave this a look. It seems good, but I'm not sure about this bit:
+ case 'W': /* Start Copy Bo
Tom Lane wrote:
> I wrote:
> > The reason this is a problem is that somebody, in a fit of inappropriate
> > optimization, took out the code that allowed canAcceptConnections to
> > distinguish the "not consistent yet" state.
>
> Oh, no, that's not the case --- the PM_RECOVERY postmaster state does
Robert Haas writes:
> On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane wrote:
>> I think it's not only useless from a performance standpoint, but
>> probably actually dangerous, to not take AccessExclusiveLock on the
>> standby when it's taken on the master.
> As far as I can see, that's complete nonse
I wrote:
> Seems like a logic bug in inet_net_ntop_ipv6.
um ... no, it's connectFailureMessage's fault.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Fri, Nov 26, 2010 at 6:30 PM, Tom Lane wrote:
> Speaking of classifying errors, should we have a fourth result value to
> cover "obviously bogus parameters"?
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing lis
2010/11/25 KaiGai Kohei :
> (2010/10/16 4:49), Josh Kupershmidt wrote:
>> [Moving to -hackers]
>>
>> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote:
>>> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt
wrote:
> I n
On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
>> wrote:
>>> If you go down that path, you're going to spend a lot of time thinking
>>> through every single case that uses an AccessExclusiveLock, ensuring that
>>> the
Bruce Momjian writes:
> Is "::" correct?
I don't think so ... I get this, even sillier, response:
$ psql -h ::1 -p 5433 regression
psql: could not connect to server: Connection refused
Is the server running on host "::1" (::) and accepting
TCP/IP connections on port 5433?
Seems
Robert Haas writes:
> On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
> wrote:
>> If you go down that path, you're going to spend a lot of time thinking
>> through every single case that uses an AccessExclusiveLock, ensuring that
>> the standby has enough information, and tinkering with the r
I wrote:
> The reason this is a problem is that somebody, in a fit of inappropriate
> optimization, took out the code that allowed canAcceptConnections to
> distinguish the "not consistent yet" state.
Oh, no, that's not the case --- the PM_RECOVERY postmaster state does
still distinguish not-ready
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > > > On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
> > > > > OK, I updated the code to always use cur_addr in the code --- let me
> > > > > know if t
On Thu, Nov 25, 2010 at 5:00 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Please do. Tab completion support should really be included in the
>> patch - adding it as a separate patch is better than not having it, of
>> course.
>
> Please find attached version 9 of the patch, which include
On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
wrote:
>>> As a concrete example, VACUUM acquires an AccessExclusiveLock when it
>>> wants
>>> to truncate the relation. A sequential scan running against the table in
>>> the
>>> standby will get upset, if the startup process replays a truncatio
On Wed, Nov 24, 2010 at 11:01:28PM -0500, Josh Kupershmidt wrote:
> On Tue, Nov 23, 2010 at 10:21 PM, David Fetter wrote:
> > Please find attached a patch changing both this and "updateable" to
> > "updatable," also per the very handy git grep I just learned about :)
>
> I looked a little more at
2010/11/26 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of vie nov 26 07:37:42 -0300 2010:
>> Hello
>>
>> there is difficult working with exception still. Isn't time to move forward?
>>
>> http://archives.postgresql.org/pgsql-general/2010-11/msg01129.php
>>
>> I am thinking, so we can l
Excerpts from Pavel Stehule's message of vie nov 26 07:37:42 -0300 2010:
> Hello
>
> there is difficult working with exception still. Isn't time to move forward?
>
> http://archives.postgresql.org/pgsql-general/2010-11/msg01129.php
>
> I am thinking, so we can little bit enhance a GET DIAGNOSTIC
Bruce Momjian writes:
> Fujii Masao wrote:
>> This patch breaks the behavior that "pg_ctl -w start" waits until the standby
>> has been ready to accept read-only queries. IOW, pg_ctl without this patch
>> continues to check the connection even if the connection is rejected because
>> the database
Bruce Momjian writes:
> Fujii Masao wrote:
>> I agree to treat the receipt of password request from the server as success
>> of the server starting. But I don't think that we should treat other
>> rejection
>> cases that way and change the existing behavior.
> OK, that is easy to fix.
It's wron
Hey hackers,
I am sorry, but is it possible to implement BTW ability to
check exactly status of authentication from libpq ? As for now,
the only way to check failed authentication is parsing the error
message, that is sadly.
2010/11/26 Bruce Momjian
> Fujii Masao wrote:
> > On Fri, Nov 26, 2010
2010/11/26 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/26 Itagaki Takahiro :
>>> Why did you change doctree and ctxt to global variables?
>>> I'm not sure why /* xmlFreeDoc(doctree); */ is commented out
>>> at the end of pgxml_xpath(), but is it enough to enable the code?
>
>> I am thinking, so
Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
> On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
> > So I've been working on improving locks for foreign key checks, as
> > discussed in a thread started by Joel Jacobson a while ago. I've posted
> > about this:
> > http://
Alvaro Herrera writes:
> This looks great. As this fixes a problem that was reported to us two
> days ago, I'm interested in backpatching it. Are you going to do it?
Yeah, I'm on it. It's a bit tedious because the back branches are
different ...
regards, tom lane
--
Peter Eisentraut wrote:
> On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
> > > > OK, I updated the code to always use cur_addr in the code --- let me
> > > > know if that doesn't fix it.
> > >
> > >
Excerpts from Tom Lane's message of vie nov 26 16:14:08 -0300 2010:
> Those static variables are really ugly, and what's more this patch only
> stops some of the leakage. Per experimentation, the result object from
> pgxml_xpath has to be freed too, once it's been safely converted to
> whatever t
On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
> > > OK, I updated the code to always use cur_addr in the code --- let me
> > > know if that doesn't fix it.
> >
> > Now it's even more wrong:
> >
> > psq
Fujii Masao wrote:
> On Fri, Nov 26, 2010 at 3:11 AM, Bruce Momjian wrote:
> > I have applied this patch, with modified wording of the "cannot connect"
> > case:
> >
> > ? ? ? ?$ pg_ctl -w -l /dev/null start
> > ? ? ? ?waiting for server to start done
> > ? ? ? ?server started
> > ? ? ? ?warni
Pavel Stehule writes:
> 2010/11/26 Itagaki Takahiro :
>> Why did you change doctree and ctxt to global variables?
>> I'm not sure why /* xmlFreeDoc(doctree); */ is commented out
>> at the end of pgxml_xpath(), but is it enough to enable the code?
> I am thinking, so you must not to call xmlFreeDo
On 26.11.2010 20:17, Robert Haas wrote:
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
wrote:
If you have operation A in the master that currently acquires an
AccessExclusiveLock on a table, do you think it's safe for another
transaction to peek at the table at the same time?
Beep, tim
Dmitriy Igrishin writes:
> Without some "restoreddl" which able to "compile" the set of
> database objects from many files this tool (getddl) does nothing
> because another developer can change the database directly
Indeed, getddl does not try to solve that issue. It's more a VCS and
editor frien
Peter Eisentraut wrote:
> On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
> > OK, I updated the code to always use cur_addr in the code --- let me
> > know if that doesn't fix it.
>
> Now it's even more wrong:
>
> psql: could not connect to server: Connection refused
> Is the serv
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
wrote:
Incidentally, I haven't been able to wrap my head around why we need
to propagate AccessExclusiveLocks to the standby in the first place.
Can someone explain?
>>>
>>> To make the standby stop applying WAL when a local trans
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
> OK, I updated the code to always use cur_addr in the code --- let me
> know if that doesn't fix it.
Now it's even more wrong:
psql: could not connect to server: Connection refused
Is the server running on host "localhost" (???) and
On Fri, Nov 26, 2010 at 11:16 AM, Tom Lane wrote:
> Shigeru HANADA writes:
>> I'll revise the patch along the discussion. Before starting code work,
>> please let me summarize the discussion.
>
>> * Generally, we should keep FDWs away from PostgreSQL internals,
>> such as TupleTableSlot.
>
>> *
Hey Dimitri, hackers,
Okay, there is a some getddl utility. But as for me, it does not
simplify the development. It is "file-based pgAdmin" with the
exception that I can use, e.g. Emacs for editing rather than
build-in editor of pgAdmin. But I can use Emacs from psql(1)...
Without some "restoredd
Jeff Janes wrote:
For the individual file sync times emitted under debug1, it would be
very handy if the file being synced was identified, for example
"relation base/16384/16523".
I was in the middle of looking into adding that already, so consider
that part of the target for the next update I
Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of vie nov 26 11:06:24 -0300 2010:
>
> > Thanks for working on this. However, the example I posted at the
> > beginning of this thread now does this:
> >
> > $ ./psql -p 5 -h localhost
> > psql: could not connect to server: Con
Peter Eisentraut wrote:
> On l?r, 2010-11-20 at 18:07 -0500, Bruce Momjian wrote:
> > The output is as expected:
> >
> > $ psql -h localhost test
> > psql: could not connect to server: Connection refused
> > Is the server running on host "localhost" (127.0.0.1) and
> > accepti
Shigeru HANADA writes:
> I'll revise the patch along the discussion. Before starting code work,
> please let me summarize the discussion.
> * Generally, we should keep FDWs away from PostgreSQL internals,
> such as TupleTableSlot.
> * FDW should have planner hook which allows FDW to create FDW-
I thought I could improve the way libpq/Makefile pulls in C files, but
it turns out MSVC scrapes the OBJS lines from that file, so I had to
revert most of my cleanup, attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It
On Fri, 2010-11-26 at 17:53 +0200, Heikki Linnakangas wrote:
> Hmm,
> looking at the code, we also allow RowShareLock and RowExclusiveLock
> in
> the standby. You can't actually insert/update/delete tuples or set
> xmax
> as SELECT FOR SHARE does on standby, though, so why do we allow that?
It
On 26.11.2010 17:28, Robert Haas wrote:
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund wrote:
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
Simon Riggs writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
On Fri, 2010-11-26 at 11:19 +0900, Fujii Masao wrote:
> On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs wrote:
> > As to solutions, it cannot be acceptable to ignore some locks just
> > because an xid has not been assigned.
>
> Even if GetRunningTransactionLocks ignores such a lock, it's eventually
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund wrote:
> On Friday 26 November 2010 13:32:18 Robert Haas wrote:
>> On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
>> > Simon Riggs writes:
>> >> That would mean running GetCurrentTransactionId() inside LockAcquire()
>> >>
>> >> if (lockmode >= Acc
Excerpts from Peter Eisentraut's message of vie nov 26 11:06:24 -0300 2010:
> Thanks for working on this. However, the example I posted at the
> beginning of this thread now does this:
>
> $ ./psql -p 5 -h localhost
> psql: could not connect to server: Connection refused
> Is the ser
On lör, 2010-11-20 at 18:07 -0500, Bruce Momjian wrote:
> The output is as expected:
>
> $ psql -h localhost test
> psql: could not connect to server: Connection refused
> Is the server running on host "localhost" (127.0.0.1) and
> accepting
> TCP/IP connec
On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
> So I've been working on improving locks for foreign key checks, as
> discussed in a thread started by Joel Jacobson a while ago. I've posted
> about this:
> http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks/
>
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
> On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> That would mean running GetCurrentTransactionId() inside LockAcquire()
> >>
> >> if (lockmode >= AccessExclusiveLock &&
> >> locktag->locktag_type == LOCKTAG
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
> Simon Riggs writes:
>> That would mean running GetCurrentTransactionId() inside LockAcquire()
>
>> if (lockmode >= AccessExclusiveLock &&
>> locktag->locktag_type == LOCKTAG_RELATION &&
>> !RecoveryInProgress())
>> (void) GetCurrent
On Thu, Nov 25, 2010 at 9:54 PM, KaiGai Kohei wrote:
> I'll revise my patch. How about _PG_fini()?
In modules like auto_explain and pg_stat_statements, we have some
token code in there to handle unload, but I don't believe there's any
way to invoke it, nor would it work if there were multiple use
Joshua Tolley writes:
>> > * I'd like to see the docs slightly expanded, specifically to describe
>> > parameter replacement. I wondered for a while if I needed to set of
>> > parameters in any specific way, before reading the code and realizing
>> > they
>> > can be whatever I want.
>>
>>
2010/11/26 Itagaki Takahiro :
> On Fri, Nov 26, 2010 at 17:59, Pavel Stehule wrote:
>> our customer showed a very significant memory leak in xml2.
>> It never release a memory allocated for context and doctree.
>
> Why did you change doctree and ctxt to global variables?
> I'm not sure why /* xmlF
Hello
there is difficult working with exception still. Isn't time to move forward?
http://archives.postgresql.org/pgsql-general/2010-11/msg01129.php
I am thinking, so we can little bit enhance a GET DIAGNOSTICS statement
condition item names are defined in SQL 92 - mainly: TABLE_NAME,
COLUM_NAM
On Fri, Nov 26, 2010 at 17:59, Pavel Stehule wrote:
> our customer showed a very significant memory leak in xml2.
> It never release a memory allocated for context and doctree.
Why did you change doctree and ctxt to global variables?
I'm not sure why /* xmlFreeDoc(doctree); */ is commented out
at
This what I done is
1. Send bind
2. Put on stack the requested format types
3. On bind complete get requestedFormats from stack.
4. When execute is complete (or portal suspend) then, use requestedFormats
to change the field formats received from describe or previously cached.
I assume server can'
Hello
our customer showed a very significant memory leak in xml2.
try to
select xpath_number('' || generate_series || '','/data')
from generate_series(1,50);
attention! take all memory very fast
It never release a memory allocated for context and doctree.
Regards
Pavel Stehule
*** ./xpat
59 matches
Mail list logo
