While regular ANALYZE seems to be pretty good ... is it insane to
suggest determining the min/max bounds of problem columns by looking at
a btree index on the column in ANALYZE, instead of relying on random
data sampling? An ANALYZE that didn't even have to scan the indexes but
just look at the
On 31/12/2009 12:33 AM, Kevin Grittner wrote:
Tom Lane wrote:
Well, the problem Josh has got is exactly that a constant high
bound doesn't work.
I thought the problem was that the high bound in the statistics fell
too far below the actual high end in the data. This tends (in my
experience)
"David E. Wheeler" writes:
> On Dec 30, 2009, at 4:17 PM, Robert Haas wrote:
>> That doesn't seem like enough to guarantee that you've got the right
>> function.
> As Tim said elsewhere:
>> I don't see either of those as significant issues: "If you need more
>> control for a particular SP then do
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves relfilenodes for TOAST files because
this is required for prop
Kevin Grittner wrote:
> Once I sort out the subject issue, I'm about ready to try to start
> generating a very rough prototype of predicate locking. I don't want
> to start a discussion of those details on this thread, because it
> seems to me that a decision on the subject issue affects significa
Bruce Momjian wrote:
> I must be missing something but I thought the only problem with our
> existing snapshot system was that you could see a row updated after
> your snapshot was created, and that the solution to that was to
> abort the transaction that would see the new row. Can you tell me
On Thursday 31 December 2009 01:09:57 Robert Haas wrote:
> On Wed, Dec 30, 2009 at 6:43 PM, Andres Freund wrote:
> >> On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund
wrote:
> >> > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
> >> > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
> This is just a kluge, and a rather bad one I think. The real problem
> here is that AtAbort_Portals destroys the portal contents and doesn't
> do anything to record the fact. It should probably be putting the
> portal into PORTAL_FAILED state, and what exec_execute_message ought
> to be doing i
Joshua D. Drake wrote:
postgres=# analyze verbose test_ten_million;
INFO: analyzing "public.test_ten_million"
INFO: "test_ten_million": scanned 3000 of 44248 pages, containing 678000
live rows and 0 dead rows; 3000 rows in sample, 1048 estimated total
rows
ANALYZE
Time: 20145.148 ms
At
On Dec 30, 2009, at 4:17 PM, Robert Haas wrote:
>> That much works currently. Behind the scenes, when a stored procedure is
>> loaded into plperl the code ref for the perl sub is stored in a cache.
>> Effectively just
>>$cache{$name}[$nargs] = $coderef;
>
> That doesn't seem like enough to gu
On Wed, Dec 30, 2009 at 5:54 PM, Tim Bunce wrote:
> That much works currently. Behind the scenes, when a stored procedure is
> loaded into plperl the code ref for the perl sub is stored in a cache.
> Effectively just
> $cache{$name}[$nargs] = $coderef;
That doesn't seem like enough to guarante
On Wed, Dec 30, 2009 at 6:43 PM, Andres Freund wrote:
>
> - Ursprüngliche Mitteilung -
>> On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote:
>> > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
>> > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
>> > > > Andres Freund
2009/12/31 Hiroshi Inoue :
> Magnus Hagander wrote:
>>
>> 2009/12/30 Hiroshi Inoue :
>>>
>>> Hi,
>>>
>>> As far as I tested, the krb_server_keyfile setting
>>> in postgres.conf doesn't work on Windows.
>>>
>>> Because gssapi32.dll(krb5_32.dll) seems to call
>>> getenv("KRB5_KTNAME") in msvcr71, pos
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue :
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because gssapi32.dll(krb5_32.dll) seems to call
getenv("KRB5_KTNAME") in msvcr71, postgres.exe
should call putenv("KRB5_KTNAME=...") in msvcr71.
Th
- Ursprüngliche Mitteilung -
> On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote:
> > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
> > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
> > > > Andres Freund writes:
> > > > > On Tuesday 29 December 2009 16:22:54 Tom Lan
2009/12/4 Tsutomu Yamada :
> Thanks to suggestion.
> I send pathces again by another mailer for the archive.
>
> Sorry to waste resources, below is same content that I send before.
I have a couple of comments about the first patch (I'll get to the
others later):
config.win32.h has:
+ #ifdef _MSC_
Tom Lane wrote:
> Back when we put in the ability to use "x IS NULL" as a btree search
> condition, we intentionally left out "x IS NOT NULL", on the grounds
> that it is comparable to "x <> something" which is not btree-searchable
> either. However, it occurs to me that we missed a bet here. The
Kevin Grittner wrote:
> I've been reviewing code to get a better handle on the scope of
> changes to support serializable transactions, in preparation for
> next month's meetings with our CIO. My posts should start getting
> progressively less hand-wavy. :-)
>
> I've come to a few conclusions:
Back when we put in the ability to use "x IS NULL" as a btree search
condition, we intentionally left out "x IS NOT NULL", on the grounds
that it is comparable to "x <> something" which is not btree-searchable
either. However, it occurs to me that we missed a bet here. The NOT
NULL condition coul
Hi,
PostgreSQL RPM Building Project released RPM sets for 3rd Alpha of the
upcoming 8.5 release.
Please note that these packages are **not** production ready. They are
for Fedora 7,8,9,11,12 and RHEL/CentOS 4,5.
These packages *do* require a dump/reload, even from the second alpha
packages, beca
I've been reviewing code to get a better handle on the scope of
changes to support serializable transactions, in preparation for
next month's meetings with our CIO. My posts should start getting
progressively less hand-wavy. :-)
I've come to a few conclusions:
(1) The notions of having multi
While waiting for feedback on my earlier plperl refactor and feature
patches I'm working on a further patch that adds, among other things,
fast inter-plperl-sp calling.
I want to outline what I've got and get some feedback on open issues.
To make a call to a stored procedure from plperl you just
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Because gssapi32.dll(krb5_32.dll) seems to call
>> getenv("KRB5_KTNAME") in msvcr71, postgres.exe
>> should call putenv("KRB5_KTNAME=...") in msvcr71.
>> The attached patch fixes the problem in my test
>> case.
>
> Don't we already have something like th
Chris Browne writes:
> I find it curious that ANALYZE *would* take a long time to run.
> After all, its sampling strategy means that, barring having SET
> STATISTICS to some ghastly high number, it shouldn't need to do
> materially more work to analyze a 1TB table than is required to analyze
> a
well that's interesting because they claim to be doing exactly the same amount
of I/O in terms of pages.
In the first case it's reading 3/4 of the table so it's effectively doing a
sequential scan. In the second case it's only scanning 7.5% so you would expect
it to be slower but not that much
j...@commandprompt.com ("Joshua D. Drake") writes:
> On the other hand ANALYZE also:
>
> 1. Uses lots of memory
> 2. Lots of processor
> 3. Can take a long time
>
> We normally don't notice because most sets won't incur a penalty. We got a
> customer who
> has a single table that is over 1TB in siz
On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule wrote:
> here is patch
The error handling in quote_literal() doesn't look right to me. The
documentation for PQescapeStringConn says that it stores an error
message in the conn object, but your code ignores that and prints out
a generic message inst
On Mon, Nov 30, 2009 at 4:36 AM, Itagaki Takahiro
wrote:
> If we want to keep backward compatibility, the issue can be fixed
> by adding pg_verifymbstr() to the function. We can also have the
> binary version in another name, like pg_read_binary_file().
I don't feel good about changing the return
Peter Eisentraut writes:
> On tis, 2009-12-29 at 22:08 -0500, Tom Lane wrote:
>> This seems like a fundamentally broken approach, first because "time
>> between analyzes" is not even approximately a constant, and second
>> because it assumes that we have a distance metric for all datatypes.
> May
On Wed, Dec 30, 2009 at 12:16 PM, Robert Haas wrote:
> 2009/12/30 Teodor Sigaev :
>>> changes should be made. It does also need to be updated to CVS HEAD,
>>> as it no longer applies cleanly.
>>
>> The reason was a point_ops patch, some OIDs become duplicated. Both attached
>> patches are synced
* Rod Taylor (rod.tay...@gmail.com) wrote:
> I (stupidly?) installed PostgreSQL into a hostile environment which
> didn't like this and decided to kill the processes as a result.
> Unfortunately, I cannot change the environment.
That's not hostile, that's broken.
Stephen
signature.asc
D
On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>> On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan
>> wrote:
>>> I think we are getting the cart way before the horse. I'd like to see at
>>> least the outline of an API before we go any further. JSON is, shall we
>>> say
Robert Haas wrote:
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan wrote:
I think we are getting the cart way before the horse. I'd like to see at
least the outline of an API before we go any further. JSON is, shall we say,
lightly specified, and doesn't appear to have any equivalent to XP
On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote:
> On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
>> On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
>> > Andres Freund writes:
>> > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
>> > >> This seems like a fairly bad idea.
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan wrote:
> I think we are getting the cart way before the horse. I'd like to see at
> least the outline of an API before we go any further. JSON is, shall we say,
> lightly specified, and doesn't appear to have any equivalent to XPath and
> friends, fo
On tis, 2009-12-29 at 22:08 -0500, Tom Lane wrote:
> This seems like a fundamentally broken approach, first because "time
> between analyzes" is not even approximately a constant, and second
> because it assumes that we have a distance metric for all datatypes.
Maybe you could compute a correlatio
On Wed, 30 Dec 2009 18:42:38 +, Greg Stark wrote:
> I'm a bit puzzled by people's repeated suggestion here that large
> tables take a long time to analyze. The sample analyze takes to
> generate statistics is not heavily influenced by the size of the
> table. Your 1TB table should take basica
On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
> On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
> > >> This seems like a fairly bad idea. One of the intended use-cases is
> > >> to be able to manua
On Wed, 2009-12-30 at 14:15 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> > AFAIK, NOTICE was suggested because it can be sent at any time, whereas
> > ERRORs are only associated with statements.
> >
> > http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASY
On Wed, Dec 30, 2009 at 4:31 PM, Joshua D. Drake wrote:
> On the other hand ANALYZE also:
>
> 1. Uses lots of memory
> 2. Lots of processor
> 3. Can take a long time
>
> We normally don't notice because most sets won't incur a penalty. We got a
> customer who
> has a single table that is over 1TB
Alvaro Herrera writes:
> Tom Lane escribió:
>> Normally, yeah. I think Josh's problem is that he's got
>> performance-critical queries that are touching the "moving edge" of the
>> data set, and so the part of the stats that are relevant to them is
>> changing fast, even though in an overall sens
David E. Wheeler wrote:
I guess the question is whether we would slurp one of these into our
code base, or whether we would add an analog of --with-libxml and
provide only a stub implementation when the library is not present.
Any opinions? Does anyone know whether any of these implementations
On Dec 30, 2009, at 9:53 AM, Robert Haas wrote:
> It looks like they are all very permissive, though I wonder what the
> legal effect of a license clause that the software be used for Good
> and not Evil might be.
Yeah, that might be too restrictive, given that PostgreSQL is used by
government a
We got an interesting report on the testers list today:
http://archives.postgresql.org/pgsql-testers/2009-12/msg0.php
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.html
Di
On Wed, Dec 30, 2009 at 12:38 PM, David E. Wheeler wrote:
> On Dec 29, 2009, at 6:14 PM, Robert Haas wrote:
>
>> I've been mulling this over and I think this is a pretty good idea.
>> If we could get it done in time for 8.5, we could actually change the
>> output type of EXPLAIN (FORMAT JSON) to t
On Dec 29, 2009, at 6:14 PM, Robert Haas wrote:
> I've been mulling this over and I think this is a pretty good idea.
> If we could get it done in time for 8.5, we could actually change the
> output type of EXPLAIN (FORMAT JSON) to the new type. If not, I'm
> inclined to say that we should postpo
On Wed, 2009-12-30 at 15:31 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The code has always been capable of starting without this, which was
> > considered a feature to be able start from a hot copy.
>
> Why is that desirable? The system is in an inconsistent state. To force
> it, yo
2009/12/30 Teodor Sigaev :
>> changes should be made. It does also need to be updated to CVS HEAD,
>> as it no longer applies cleanly.
>
> The reason was a point_ops patch, some OIDs become duplicated. Both attached
> patches are synced with current CVS.
Thanks! I will take a look.
>> I tend to
Tom Lane escribió:
> Greg Smith writes:
> > Right, and the only thing that makes this case less painful is that you
> > don't really need the stats to be updated quite as often in situations
> > with that much data. If, say, your stats say there's 2B rows in the
> > table but there's actually
Teodor Sigaev escribió:
> Actually, it's easy to split patch to several ones:
> - contrib/pg_trgm
> - contrib/btree_gist
> - knngist itself
> - planner changes
+1 on the split patches. I wonder about the opr_sanity test change ...
why is it necessary?
--
Alvaro Herrera
Greg Smith wrote:
> If, say, your stats say there's 2B rows in the table but there's
> actually 2.5B, that's a big error, but unlikely to change the
> types of plans you get. Once there's millions of distinct values
> it's takes a big change for plans to shift, etc.
Well, the exception to tha
Greg Smith writes:
> Right, and the only thing that makes this case less painful is that you
> don't really need the stats to be updated quite as often in situations
> with that much data. If, say, your stats say there's 2B rows in the
> table but there's actually 2.5B, that's a big error, but
On Wed, Dec 30, 2009 at 9:20 AM, Oleg Bartunov wrote:
> From metodological point of view I don't quite understand how to measure
> the value of development, I mean what'is a "big patch", "invasive patch".
I want to speak specifically to this question because I think it's a
good one. Of course, I
Tatsuo Ishii writes:
> parse causes transaction to abort, which causes call to
> AbortCurrentTransaction->AbortTransaction->AtAbort_portals->ReleaseCachedPlan.
> It
> calls ReleaseCachePlan(portal->cplan). ReleaseCachePlan calls
> MemoryContextDelete(plan->context) which destroys both portal->cpl
Joshua D. Drake wrote:
We normally don't notice because most sets won't incur a penalty. We got a
customer who
has a single table that is over 1TB in size... We notice. Granted that is the
extreme
but it would only take a quarter of that size (which is common) to start seeing
issues.
Righ
Hi Tom-san.
Ahh.. It was correction of the test of often...
again, the pursued relation was seen, I think that it is good now.
Thanks!!
Regards,
Hiroshi Saito
- Original Message -
From: "Tom Lane"
"Hiroshi Saito" writes:
[ examples_win32_patch2 ]
Is the addition of -DFRONTEND
"Hiroshi Saito" writes:
> [ examples_win32_patch2 ]
Is the addition of -DFRONTEND actually needed, and if so why?
We shouldn't be depending on that in any user-exposed code, I would
think. Otherwise I don't have any objection to this version.
regards, tom lane
--
Sent
Tom Lane wrote:
> Well, the problem Josh has got is exactly that a constant high
> bound doesn't work.
I thought the problem was that the high bound in the statistics fell
too far below the actual high end in the data. This tends (in my
experience) to be much more painful than an artificially
On Wed, 30 Dec 2009 11:16:45 -0500, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> I don't have a better idea at the moment :-(
>
>> It's been a while since I've been bitten by this issue -- the last
>> time was under Sybase. The Sybase suggestion was to either add
>> "dumm
2009/12/30 Hiroshi Saito :
> Hi Andrew-san.
>
> This saves a windows users.
> I appreciate your suggestion.
> Thanks!
This one looks much better. +1 for this version :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing li
Hi Andrew-san.
This saves a windows users.
I appreciate your suggestion.
Thanks!
P.S)
I often use by the test by nmake at the time of independent creation of libpq.
Regards,
Hiroshi Saito
- Original Message -
From: "Andrew Dunstan"
Hiroshi Saito wrote:
Hi Andrew-san.
Althou
On Wed, Dec 30, 2009 at 10:24 AM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>> Robert Haas writes:
>> > If you'd be willing to look over the latest version of my
>> > per-tablespace random_page_cost/seq_page_cost patch, which I posted to
>> > -hackers some time in the last few days, I can get th
2009/12/30 Hiroshi Inoue :
> Hi,
>
> As far as I tested, the krb_server_keyfile setting
> in postgres.conf doesn't work on Windows.
>
> Because gssapi32.dll(krb5_32.dll) seems to call
> getenv("KRB5_KTNAME") in msvcr71, postgres.exe
> should call putenv("KRB5_KTNAME=...") in msvcr71.
> The attached
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I don't have a better idea at the moment :-(
> It's been a while since I've been bitten by this issue -- the last
> time was under Sybase. The Sybase suggestion was to either add
> "dummy rows" [YUCK!] to set the extreme bounds or to "lie to the
>
Hiroshi Inoue writes:
> Because gssapi32.dll(krb5_32.dll) seems to call
> getenv("KRB5_KTNAME") in msvcr71, postgres.exe
> should call putenv("KRB5_KTNAME=...") in msvcr71.
> The attached patch fixes the problem in my test
> case.
Don't we already have something like that in our src/port putenv
s
Andrew Dunstan writes:
> Tom Lane wrote:
>> On reflection I think it's just wrong to expect that the examples will
>> compile out-of-the-box on every platform.
> That would be all good and well if we didn't already rely on the
> configure setup. But we do - the Makefile includes src/Makefile.glo
Hiroshi Saito wrote:
Hi Andrew-san.
Although this is a standard in windows.
*** testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- testlibpq2.cThu Dec 31 00:52:52 2009
***
*** 24,34
--- 24,39
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #ifdef WIN32
+ #includ
Tom Lane wrote:
> Josh Berkus writes:
>> My thoughts on dealing with this intelligently without a major
>> change to statstics gathering went along these lines:
>
>> 1. add columns to pg_statistic to hold estimates of upper and
>> lower bounds growth between analyzes.
>
> This seems like a fund
Hi Andrew-san.
Although this is a standard in windows.
*** testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- testlibpq2.cThu Dec 31 00:52:52 2009
***
*** 24,34
--- 24,39
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #ifdef WIN32
+ #include
+ #endif
#include
Tom Lane wrote:
"Hiroshi Saito" writes:
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains
Thanks!
It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is th
Bruce Momjian writes:
> Well, those example programs are pretty clean libpq apps so I don't see
> why they should using platform-specific stuff.
Example #2 depends on select(), which depends on fd_set, so you're
already into territory where there are issues.
regards, tom
Tom Lane wrote:
> "Hiroshi Saito" writes:
> > Yes, I thinks that it is an exact idea. However, this example was not
> > helped.
> > fd_set complains
> > Thanks!
>
> > It seems that pg_bench takes the thing same again into consideration.
> > Anyway, If it is called example of end-user cod
"Hiroshi Saito" writes:
> Yes, I thinks that it is an exact idea. However, this example was not helped.
> fd_set complains
> Thanks!
> It seems that pg_bench takes the thing same again into consideration.
> Anyway, If it is called example of end-user code, what is the evasion method
> of
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because gssapi32.dll(krb5_32.dll) seems to call
getenv("KRB5_KTNAME") in msvcr71, postgres.exe
should call putenv("KRB5_KTNAME=...") in msvcr71.
The attached patch fixes the problem in my test
case.
Tom Lane escribió:
> Robert Haas writes:
> > If you'd be willing to look over the latest version of my
> > per-tablespace random_page_cost/seq_page_cost patch, which I posted to
> > -hackers some time in the last few days, I can get that committed and
> > then start working on this, if you'd like.
Hi Alvaro-san.
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains
Thanks!
It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is the evasion method
of fd_set?
Regards,
Mark Cave-Ayland writes:
> Alvaro Herrera wrote:
>> As a proof of its usefulness, you could remove DATA_TSEARCH and replace
>> it with usage of MODULEDIR, right?
> Not in its current form because PGXS always places files underneath a
> contrib/ subdirectory within datadir. However, if people are
Alvaro Herrera wrote:
The attached patch is a prototype which allows the user to specify a
new MODULEDIR variable in a module makefile which, if specified,
will install DATA and DOCS items in contrib/$(MODULEDIR) rather than
just contrib. If MODULEDIR is left unspecified, the files will
simply b
Robert Haas writes:
> If you'd be willing to look over the latest version of my
> per-tablespace random_page_cost/seq_page_cost patch, which I posted to
> -hackers some time in the last few days, I can get that committed and
> then start working on this, if you'd like.
I think Alvaro would actual
Sync with current CVS
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
point_ops-0.5.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Tarun Sharma wrote:
> hi,
>
> i assigned super user privelledge to a user by specifing entries in
> pg_hba.conf file as
>
> hostallnewuser127.1.1.1 md5
>
> and the default postgres user is made access to only the default postgres
> databse and is no more the super user.
>
> the p
Hiroshi Saito wrote:
> Hi Tom-san.
>
> Um, How do you consider sample which cannot build?
I think testlibpq2.c is missing a couple of system includes, sys/types.h
and unistd.h (or alternatively select.h); and testlibpq3.c is missing
stdint.h. Or so say my (POSIX) manpages anyway.
--
Alvaro Her
Craig Ringer wrote:
> It might be kind of handy if I could getWarnings() on the
> connection object without blocking so I could call it before I
> executed a statement on the connection ... but that'd always
> introduce a race between transaction cancellation/timeout and
> statement execution, s
Robert,
On Wed, 30 Dec 2009, Robert Haas wrote:
Based on the feedback provided on this patch so far, it looks like
some changes are probably needed, but it's not entirely clear whether
the feedback provided is sufficient to provide guidance on what
changes should be made. It does also need to
> Tatsuo Ishii wrote:
> > ! if (!PortalIsValid(portal) || (PortalIsValid(portal) && portal->cleanup
> > == NULL))
> >
> >
>
>
> Surely the second call to PortalIsValid() is redundant.
>
> if (( !PortalIsValid(portal)) || portal->cleanup == NULL)
>
> should do it, no?
Oops. Yo
Simon Riggs wrote:
> On Wed, 2009-12-23 at 12:50 +0200, Heikki Linnakangas wrote:
>
>> I just realized that the current history file fails to recognize this
>> scenario:
>>
>> 1. pg_start_backup()
>> 2. cp -a $PGDATA data-backup
>> 3. create data-backup/recovery.conf
>> 4. postmaster -D data-backu
Fujii Masao wrote:
> On Thu, Dec 24, 2009 at 1:39 PM, Fujii Masao wrote:
>> On Wed, Dec 23, 2009 at 7:50 PM, Heikki Linnakangas
>> wrote:
>>> Ok. How about writing the history file in pg_stop_backup() for
>>> informational purposes only. Ie. never read it, but rely on the WAL
>>> records instead.
Tatsuo Ishii wrote:
! if (!PortalIsValid(portal) || (PortalIsValid(portal) && portal->cleanup
== NULL))
Surely the second call to PortalIsValid() is redundant.
if (( !PortalIsValid(portal)) || portal->cleanup == NULL)
should do it, no?
cheers
andrew
--
Sent via pgsq
> While inspecting a complain from a pgpool user, I found that
> PostgreSQL crushes with following statck trace:
>
> #0 0x0826436a in list_length (l=0xaabe4e28)
> at ../../../src/include/nodes/pg_list.h:94
> #1 0x08262168 in IsTransactionStmtList (parseTrees=0xaabe4e28)
> at postgres.c:2
On 30/12/2009 7:37 PM, Simon Riggs wrote:
Can JDBC accept a NOTICE, yet throw an error? NOTICEs have a SQLState
field just like ERRORs do, so you should be able to special case that.
The JDBC driver would have to throw when the app code next interacted
with the connection object anyway. It ca
On Wed, 30 Dec 2009, Heikki Linnakangas wrote:
Could we send an asynchronous notification immediately when the
transaction is cancelled, but also change the error message you get in
the subsequent commands. Clients that ignore the async notification
would still see a proper error message at th
2009/12/30 Hiroshi Inoue :
> Hi,
>
> I try to build msvc version of postgres using the current cvs and
> get the following error.
>
> Unable to determine vcbuild version from first line of output! at
> src/tools/msvc/Solution.pm line 70.
>
> The error comes from the following output of vcbuild /
On Wed, 30 Dec 2009, Simon Riggs wrote:
http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC
"It is possible for NoticeResponse messages to be generated due to
outside activity; for example, if the database administrator commands a
"fast" database shutdown, the bac
2009/12/30 Tarun Sharma :
> hi,
>
> i assigned super user privelledge to a user by specifing entries in
> pg_hba.conf file as
>
> host all newuser 127.1.1.1 md5
>
> and the default postgres user is made access to only the default postgres
> databse and is no more the super user.
>
> the
Simon Riggs wrote:
> On Wed, 2009-12-30 at 05:02 -0500, Kris Jurka wrote:
>> On Tue, 29 Dec 2009, Simon Riggs wrote:
>>
The proposal is to send an additional NOTICE to the client and abort
all open transactions and subtransactions (this is what I got from the
previous discussion).
>>
On Wed, 2009-12-30 at 11:43 +0100, Joachim Wieland wrote:
> On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs wrote:
> >> I had to write an additional function AbortAnyTransaction() which
> >> aborts all transactions and subtransactions and leaves the transaction
> >> in the aborted state, is there an
On Wed, 2009-12-30 at 12:05 +0100, Joachim Wieland wrote:
> On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane wrote:
> > This seems like a fairly bad idea. One of the intended use-cases is to
> > be able to manually "kill -INT" a misbehaving backend. Assuming that
> > there will be valid info about the
On Wed, 2009-12-30 at 05:02 -0500, Kris Jurka wrote:
>
> On Tue, 29 Dec 2009, Simon Riggs wrote:
>
> >> The proposal is to send an additional NOTICE to the client and abort
> >> all open transactions and subtransactions (this is what I got from the
> >> previous discussion).
> >
> > Would this wo
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane wrote:
> This seems like a fairly bad idea. One of the intended use-cases is to
> be able to manually "kill -INT" a misbehaving backend. Assuming that
> there will be valid info about the signal in shared memory will break
> that.
I never intended to ch
hi,
i assigned super user privelledge to a user by specifing entries in pg_hba.conf
file as
hostallnewuser127.1.1.1 md5
and the default postgres user is made access to only the default postgres
databse and is no more the super user.
the problem is that this conf file is available
1 - 100 of 104 matches
Mail list logo
