On 17.02.2011 14:30, Gurjeet Singh wrote:
On Wed, Feb 16, 2011 at 6:37 PM, Tom Lane wrote:
Gurjeet Singh writes:
On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane wrote:
The only reason you'd need that code is if you were trying to construct
a fake Relation structure, which seems unnecessary and
=?iso-8859-1?Q?R=E9mi_Zara?= writes:
> Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit :
>> It's only failing on this one machine, but there isn't anything
>> platform-specific in this code, so I'd look for memory management faults
>> on the code or a compiler problem. Try with lower optimizat
Hi,
Thanks for your reply.
Of course, we will think about whether 4 relations dropping is
reasonable. In fact, this happens in a very special scenario .
But when we analyzed this issue, we found the PG code can be rewritten to
achieve better performance. Or we can say the arithmetic of
Hi,
Thanks for your reply.
Of course, we will think about whether 4 relations dropping is
reasonable. In fact, this happens in a very special scenario .
But when we analyzed this issue, we found the PG code can be rewritten to
achieve better performance. Or we can say the arithmetic of
Teodor Sigaev writes:
>> I've applied all of this, and written documentation for all of it,
> Thank you a lot
>> except for the contrib/btree_gist additions which still need to be
>> redone for the revised API (and then documented!). My patience ran out
> Done, btree_gist is reworked for a new A
On Fri, Feb 18, 2011 at 13:15, Shigeru HANADA wrote:
> When I've used COPY TO for testing file_fdw, I got wrong result.
> It would be because DR_copy's processed is not initialized in
> CreateCopyDestReceiver(). Please see attached patch.
Oops, thanks, applied.
--
Itagaki Takahiro
--
Sent vi
On Thu, Feb 17, 2011 at 17:05, Itagaki Takahiro
wrote:
> I did a few cosmetic fixes, mainly lmgr/README and make a subroutine
> ReleaseLockForOwner() for LockReleaseSession and LockReleaseCurrentOwner.
Committed with a few typo fixes. Thanks, Marko!
--
Itagaki Takahiro
--
Sent via pgsql-hacke
On Wed, 16 Feb 2011 11:22:04 +0900
Itagaki Takahiro wrote:
> Thanks comments. I've applied the COPY API patch.
When I've used COPY TO for testing file_fdw, I got wrong result.
# Actually csv_branches has only 10 rows.
postgres=# copy (select * from csv_branches) to
'/home/hanada/DB/BINARY/branc
Bruce Momjian writes:
> Tom Lane wrote:
>> I think we have a few TODO items here:
>>
>> * Invent ... and document ... an API that permits safe assembly of a
>> parameter list from non-constant (and perhaps untrustworthy) values.
>>
>> * Fix xslt_process' failure to report (some?) errors detected
On Fri, Feb 18, 2011 at 04:04, Hitoshi Harada wrote:
> FWIW, I finally found the good example to cache miscellaneous data in
> file local, namely regexp.c. It allocates compiled regular expressions
> up to 32 by using malloc().
I'm not exactly sure the cache usage in mbutils.c because it doesn't
Tom Lane wrote:
> Mike Fowler writes:
> > On 06/08/10 17:50, Pavel Stehule wrote:
> >> attached updated patch with regression test
>
> > Bravely ignoring the quotation/varidic/
> > conversations, I've taken a look at the patch as is. Thanks to Tom's
> > input I can now correctly drive the funct
Robert Haas writes:
> On Thu, Feb 17, 2011 at 4:53 PM, Tom Lane wrote:
>> In short, add a bit of overhead at SetUserId time in order to make this
>> cheap (and accurate) in elog.c.
> As Stephen says, I think this is utterly impractical; those routines
> can't ever throw any kind of error.
Why w
Gan Jiadong writes:
> we have PG 8.3.13 in our system. When running performance cases, we find the
> startup recovery cost about 3 minutes. It is too long in our system.
Maybe you should rethink the assumption that dropping 4 tables is a
cheap operation. Why do you have that many in the fir
Recently two systems here have suffered severely with excessive
temporary file creation during query execution. In one case it could
have been avoided by more stringent qa before application code release,
whereas the other is an ad-hoc system, and err...yes.
In both cases it would have been gr
On Thu, Feb 17, 2011 at 9:10 PM, Fujii Masao wrote:
> On Fri, Feb 18, 2011 at 7:55 AM, Josh Berkus wrote:
>>> So, in summary, the position is that we have a timeout, but that timeout
>>> doesn't work in all cases. But it does work in some, so that seems
>>> enough for me to say "let's commit". No
On Thu, Feb 17, 2011 at 4:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> It seems there's at least one more thing to worry about here, which is
>> the overhead of this computation when CSV logging is in use. If no
>> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
>> will ca
Hello guys,
we have PG 8.3.13 in our system. When running performance cases, we find the
startup recovery cost about 3 minutes. It is too long in our system.
We diagnose the problem by adding timestamp. Finally, we find almost all 3
minutes were used by the relation dropping and buffer in
On Thu, Feb 17, 2011 at 4:29 PM, Simon Riggs wrote:
>> Something like the following description should be in the doc.
>>
>> hot_standby_feedback has no effect if either hot_standby is off or
>> wal_receiver_status_interval is zero.
>
> The docs are going to need some work after 3-4 relat
I wrote:
> Robert Haas writes:
>> I think we should try to make the state match as closely as possible,
>> no matter how you got there. Otherwise, I think we're storing up a
>> host of future pain for ourselves.
> Well, if you're willing to hold your nose for the "UPDATE pg_proc" hack,
> we can
Excerpts from Alvaro Herrera's message of mié feb 16 19:54:07 -0300 2011:
>
> I cleaned up the patch a bit -- result is v11, attached. I'll give it
> another look tomorrow and hopefully commit it.
Applied. Thanks.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Rep
On Fri, Feb 18, 2011 at 7:55 AM, Josh Berkus wrote:
>> So, in summary, the position is that we have a timeout, but that timeout
>> doesn't work in all cases. But it does work in some, so that seems
>> enough for me to say "let's commit". Not committing gives us nothing at
>> all, which is as much
> On 02/17/2011 12:34 PM, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 02/17/2011 12:13 PM, Bruce Momjian wrote:
> FWIW, the only interactively usable version of psql for windows I know
> of is the one that runs under Cygwin. It can be build with readline and
> works a
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> * The UI differs from what was agreed on here:
> http://archives.postgresql.org/message-id/4d1dcf5a.7070...@enterprisedb.com.
Patch to add server_name parameter, plus mechanism to send info from
standby to master. While doing that, r
On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera
wrote:
> Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011:
>
>> - make plperl.o depend on plperl_helpers.h (should have been done in
>> the utf8 patch)
>
> Incidentally, I think this bit was lost, no?
It was, yes.
--
Sent via
Jesper Krogh writes:
> Attached patch tries to align the behaviour
Applied with a bit of editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Jesper Krogh writes:
> On 2011-02-17 23:20, Tom Lane wrote:
>> The proposed patch seems wrong to me: if we're estimating on the basis
>> of most-common-value fractions, the null_frac is already accounted for,
>> because it's not part of the MCV selectivity fractions. IOW, aren't you
>> double-cou
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > It seems there's at least one more thing to worry about here, which is
> > the overhead of this computation when CSV logging is in use. If no
> > SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> > will call show
Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011:
> - make plperl.o depend on plperl_helpers.h (should have been done in
> the utf8 patch)
Incidentally, I think this bit was lost, no?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication,
On Feb 17, 2011, at 2:50 PM, Tom Lane wrote:
> I observe the following discrepancy between the 9.0 and 9.1 citext
> install scripts:
>
> ***
> *** 52,58
> STORAGE= extended,
> -- make it a non-preferred member of string type category
> CATEGORY = 'S',
On Thu, 2011-02-17 at 16:42 -0500, Robert Haas wrote:
> >
> > So, in summary, the position is that we have a timeout, but that timeout
> > doesn't work in all cases. But it does work in some, so that seems
> > enough for me to say "let's commit". Not committing gives us nothing at
> > all, which is
> So, in summary, the position is that we have a timeout, but that timeout
> doesn't work in all cases. But it does work in some, so that seems
> enough for me to say "let's commit". Not committing gives us nothing at
> all, which is as much use as a chocolate teapot.
Can someone summarize the ca
I observe the following discrepancy between the 9.0 and 9.1 citext
install scripts:
***
*** 52,58
STORAGE= extended,
-- make it a non-preferred member of string type category
CATEGORY = 'S',
! PREFERRED = false
);
--
--- 49,56
On 2011-02-17 23:20, Tom Lane wrote:
Jesper Krogh writes:
When something evaluates to "null" isn't included in the result,
shouldn't the query-planner
then take the null_frac into account when computing the estimate?
The proposed patch seems wrong to me: if we're estimating on the basis
of mos
Jesper Krogh writes:
> When something evaluates to "null" isn't included in the result,
> shouldn't the query-planner
> then take the null_frac into account when computing the estimate?
The proposed patch seems wrong to me: if we're estimating on the basis
of most-common-value fractions, the nul
Dan Ports wrote:
> Oops. Those are both definitely bugs (and my fault). Your patch
> looks correct. Thanks for catching that!
Could a committer please apply the slightly modified version here?:
http://archives.postgresql.org/message-id/4d5c46bb02250003a...@gw.wicourts.gov
It is a prett
Robert Haas writes:
> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use. If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none". We'll then st
I wrote:
> In any case, I was pointing to that as a reason that btree_gist wasn't
> ready to be in core. It has nothing to do with KNN-ifying the module.
> I would like to see that happen before 9.1, else KNN will go out with
> not very many actual use-cases supported.
However, a larger reason fo
On Thu, Feb 17, 2011 at 4:21 PM, Simon Riggs wrote:
> On Wed, 2011-02-16 at 11:34 +0900, Fujii Masao wrote:
>> On Tue, Feb 15, 2011 at 7:13 AM, Daniel Farina wrote:
>> > On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao
>> > wrote:
>> >> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
>> >>>
Hi All.
The NULL element always suprises me in unpleasant ways.. my brain simply
cant really understand the logic, so please let me know if this is
one of the cases where I just should spend way more efforts into fixing
that instead.
I have a table with a "null_frac" of 0.5 and i have tested
On Wed, 2011-02-16 at 11:34 +0900, Fujii Masao wrote:
> On Tue, Feb 15, 2011 at 7:13 AM, Daniel Farina wrote:
> > On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao wrote:
> >> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
> >>> Context diff equivalent attached.
> >>
> >> Thanks for the patch
On Wed, Feb 16, 2011 at 04:33:19PM -0800, Joshua D. Drake wrote:
> Maybe we really should consider moving to NSS insread?
>
> http://www.mozilla.org/projects/security/pki/nss/
>
> If it solves the license problem, it is well supported etc..
For the record, which library you choose only matters f
On Thu, Feb 17, 2011 at 3:47 PM, Simon Riggs wrote:
> The only difference in messages I got was
>
> dbsize.c: In function ‘pg_relation_filepath’:
> dbsize.c:570: warning: ‘rnode.dbNode’ may be used uninitialized in this
> function
> dbsize.c:570: warning: ‘rnode.spcNode’ may be used uninitialized
On Thu, Feb 17, 2011 at 3:55 PM, Bruce Momjian wrote:
> Daniel Loureiro wrote:
>> Is there any official style guide of PostgreSQL code ? Like the
>> "google-styleguide"
>> (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) ?
>
> There is the developers FAQ.
There's also http://www.p
Hi Oliver
There are two problems.
>
> The first problem is a plpgsql problem in that particular function. It's
> broken regardless of how you call it. Here's how to fix it [...]
>
Thanks for insisting! I missed that fact. In the end, it looked like the
same error, but you're right about the plpgs
Daniel Loureiro wrote:
> Is there any official style guide of PostgreSQL code ? Like the
> "google-styleguide"
> (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) ?
There is the developers FAQ.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Thu, 2011-02-17 at 10:09 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote:
> >> Doesn't anybody around here pay attention to compiler warnings?
>
> > If you see one, then I accept one was there. I didn't see one, and a
> > full make distclean a
On Feb 17, 2011, at 11:28 AM, Tom Lane wrote:
>> The status of that patch is that Tom promised to look at it two months
>> ago and hasn't. It would be nice if someone else could pick it up.
>
> I'm pedaling as fast as I can, honestly
Tom leaves everything on the road.
http://en.wiktionary.or
Excerpts from Florian Pflug's message of jue feb 17 16:55:55 -0300 2011:
> You can, however, do ALTER USER SET default_tablespace=,
> which will
> cause default_tablespace to be set automatically upon login for that user.
>
> I don't know of the top of my head how we store that in the system ca
Robert,
> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use. If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none". We'll then strcmp()
> tha
On Thu, Feb 17, 2011 at 08:55:55PM +0100, Florian Pflug wrote:
- On Feb17, 2011, at 18:32 , David Kerr wrote:
- > On Wed, Feb 16, 2011 at 03:59:13PM -0800, carl clemens wrote:
- > - After reviewing docs and searching web
- > - cannot find out how to determine the default tablespace
- > - of a user?
David,
as a cool perl guy you can easily take OpenFTS (openfts.sourceforge.net),
which provides perl interface to tsearch datatypes, and develop a
plperl version. That would be interesting for many people, who like flexibility
of perl. We personally use openfts in our web projects,i.e., we use ts
On Feb17, 2011, at 18:32 , David Kerr wrote:
> On Wed, Feb 16, 2011 at 03:59:13PM -0800, carl clemens wrote:
> - After reviewing docs and searching web
> - cannot find out how to determine the default tablespace
> - of a user?
>
> It doesn't appear to me that default tablespaces are assigned to a
Is there any official style guide of PostgreSQL code ? Like the
"google-styleguide"
(http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) ?
Regards,
--
Daniel Loureiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Thu, Feb 17, 2011 at 11:45 AM, Stephen Frost wrote:
> Robert, if you say this has to be punted to 9.2 again, I'm giving up. ;)
Frankly, this patch has already consumed more than its fair share of
my attention. Having said that, I've just spent some more time on it.
I tightened up both the co
On Wed, Feb 16, 2011 at 10:13:35PM +, YAMAMOTO Takashi wrote:
> i got the following SEGV when runnning vacuum on a table.
> (the line numbers in predicate.c is different as i have local modifications.)
> oldlocktag.myTarget was NULL.
> it seems that TransferPredicateLocksToNewTarget sometimes u
Robert Haas writes:
> The status of that patch is that Tom promised to look at it two months
> ago and hasn't. It would be nice if someone else could pick it up.
I'm pedaling as fast as I can, honestly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-ha
Marko Tiikkaja wrote:
> On 2011-02-17 8:37 PM +0200, Bruce Momjian wrote:
> > Marko Tiikkaja wrote:
> >> The problem with the "safe" way is that it's not safe if called in a
> >> transaction with isolation level set to SERIALIZABLE.
> >
> > Good analysis. Documentation patch attached and applied.
On 02/17/2011 12:54 PM, Kevin Grittner wrote:
Andrew Dunstan wrote:
Ugh. Isn't there some sort of pragma or similar we can use to shut
it up?
If that fails, maybe use some function like the below? That would
also have the advantage of not relying on assumptions beyond the
documented API,
2011/2/17 Itagaki Takahiro :
> Base on the latest patch,
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php
> I added pg_any_to_server() and pg_server_to_any() functions instead of
> exposing FmgrInfo in pg_wchar.h. They are same as pg_client_to_server()
> and pg_server_to_client
On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane wrote:
>>> It's worth noting that both versions still leave the pg_trgm opclasses a
>>> bit different from a fresh install, because the added operators are
>>> "loose" in the opfa
On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro
wrote:
> COPY ENCODING patch was returned with feedback,
> https://commitfest.postgresql.org/action/patch_view?id=501
> but we still need it for file_fdw. Using client_encoding at runtime
> is reasonable for one-time COPY command, but logically
Robert Haas writes:
> On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane wrote:
>> It's worth noting that both versions still leave the pg_trgm opclasses a
>> bit different from a fresh install, because the added operators are
>> "loose" in the opfamily rather than being bound into the opclass. This
>>
On 2011-02-17 8:37 PM +0200, Bruce Momjian wrote:
Marko Tiikkaja wrote:
The problem with the "safe" way is that it's not safe if called in a
transaction with isolation level set to SERIALIZABLE.
Good analysis. Documentation patch attached and applied.
The "safe way" I was referring to above
On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane wrote:
> So, after some testing, attached are two different fixed-up versions of
> pg_tgrm's update-from-unpackaged script. The first one leaves the
> parameter lists of some GIN support functions different from what they
> would be if you installed pg_t
Marko Tiikkaja wrote:
> On 8/5/2010 9:44 PM, Merlin Moncure wrote:
> > On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane wrote:
> >> I was not persuaded that there's a real bug in practice. IMO, his
> >> problem was a broken trigger not broken upsert logic. Even if we
> >> conclude this is unsafe, simply
Robert Haas wrote:
> On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Robert Haas writes:
> >> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
> >> >> I seriously doubt that there are many applications out there that are
> >> >> actually depending on this aspect o
On 02/17/2011 12:34 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 02/17/2011 12:13 PM, Bruce Momjian wrote:
FWIW, the only interactively usable version of psql for windows I know
of is the one that runs under Cygwin. It can be build with readline and
works as expected.
Uh, don't we have
On Thu, 2011-02-17 at 10:49 +, Dave Page wrote:
> On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander wrote:
> >> Probably readline but does it matter? We distribute the source to the
> >> click installers.
> >
> > Actually, we don't. We used to, but we don't at this point.
>
> Depends on your
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
>> >> I seriously doubt that there are many applications out there that are
>> >> actually depending on this aspect of rule execution; if anything,
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
> >> I seriously doubt that there are many applications out there that are
> >> actually depending on this aspect of rule execution; if anything, there
> >> are probably more that will see it as a bug.
>
>
Andrew Dunstan wrote:
> Ugh. Isn't there some sort of pragma or similar we can use to shut
> it up?
If that fails, maybe use some function like the below? That would
also have the advantage of not relying on assumptions beyond the
documented API, which I tend to feel good about no matter how
Boszormenyi Zoltan wrote:
> Kevin Grittner ?rta:
> > Michael Meskes wrote:
> >
> >> All prior ECPG versions were fine because dynamic cursor names
> >> were only added in 9.0. Apparently only this one place was
> >> missed. So this is a bug in the new feature, however not such a
> >> major one
Erik Rijkers wrote:
> On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
> > Hi Pavel,
> >
> > In xfunc.sgml, I came across a function example (for use of VARIADIC in
> > polymorphic functions),
> > where the function name is concat(): (in the manual: 35.4.10. Polymorphic
> > SQL Functions).
> > A
On Thu, Feb 17, 2011 at 09:38:51AM +0100, Benjamin S. wrote:
> ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus
> does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c
> uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap
> file.
>
> I don't understand w
Andrew Dunstan wrote:
>
>
> On 02/17/2011 12:13 PM, Bruce Momjian wrote:
> >
> >> FWIW, the only interactively usable version of psql for windows I know
> >> of is the one that runs under Cygwin. It can be build with readline and
> >> works as expected.
> > Uh, don't we have a psql built via MSVC
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (br...@momjian.us) wrote:
> > I just posted on this. The risk is to people using the packages --- the
> > packages themselves include the source as an option, so they are fine,
> > but everyone using those packages would also b
On Wed, Feb 16, 2011 at 03:59:13PM -0800, carl clemens wrote:
- Hi Hackers,
-
- After reviewing docs and searching web
- cannot find out how to determine the default tablespace
- of a user?
-
- Like:
-
- select spcname from blab where roloid = ;
-
- Is this possible?
-
- Thank you for your
On 02/17/2011 12:19 PM, Tom Lane wrote:
"Kevin Grittner" writes:
Tom Lane wrote:
Would you check whether just casting the function result to (void)
shuts it up?
Casting the result to (void) didn't change the warning. It shut up
when I declared a local variable and assigned the value to
On 02/17/2011 12:13 PM, Bruce Momjian wrote:
FWIW, the only interactively usable version of psql for windows I know
of is the one that runs under Cygwin. It can be build with readline and
works as expected.
Uh, don't we have a psql built via MSVC? Doesn't it work interactively?
Not if yo
* Bruce Momjian (br...@momjian.us) wrote:
> OK, I was only responding to Stephen Frost who said psql did not behave
> like other Windows apps.
I don't actually run psql or PG on Windows at all, I just presumed it
did since you were bringing up concerns about it in the Windows
installers. Ah well,
"Kevin Grittner" writes:
> I know that in Java you can get a positive number less than the full
> size as an indication that part of the block was written, and you
> must loop to write until you get all of it written (or get an error
> return). At this page, it appears that the same is true of th
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Would you check whether just casting the function result to (void)
>> shuts it up?
> Casting the result to (void) didn't change the warning. It shut up
> when I declared a local variable and assigned the value to it (which
> was then never used).
So, after some testing, attached are two different fixed-up versions of
pg_tgrm's update-from-unpackaged script. The first one leaves the
parameter lists of some GIN support functions different from what they
would be if you installed pg_trgrm fresh in 9.1. The second one fixes
the parameter list
Andrew Dunstan wrote:
>
>
> On 02/17/2011 11:58 AM, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 02/17/2011 11:44 AM, Bruce Momjian wrote:
> >>> Andrew Dunstan wrote:
> On 02/17/2011 11:22 AM, Bruce Momjian wrote:
> > psql used to use the native Windows line editing abilit
Tom Lane wrote:
> In at least some of these cases, I think ignoring the write()
> result is intentional, because there's really nothing useful we
> can do about it if it fails (oh, you wish we'd log a failure to
> write to the log?).
I know that in Java you can get a positive number less than
On 02/17/2011 11:58 AM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 02/17/2011 11:44 AM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 02/17/2011 11:22 AM, Bruce Momjian wrote:
psql used to use the native Windows line editing ability --- has that
changed?
When did it? Ad what "native" w
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit :
>
> Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit :
>
>>
>> It's only failing on this one machine, but there isn't anything
>> platform-specific in this code, so I'd look for memory management faults
>> on the code or a compiler problem. Try
Hi Hackers,
After reviewing docs and searching web
cannot find out how to determine the default tablespace
of a user?
Like:
select spcname from blab where roloid = ;
Is this possible?
Thank you for your time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
hi,
might be unrelated to the loop problem, but...
i got the following SEGV when runnning vacuum on a table.
(the line numbers in predicate.c is different as i have local modifications.)
oldlocktag.myTarget was NULL.
it seems that TransferPredicateLocksToNewTarget sometimes use stack garbage
for
hi,
> YAMAMOTO Takashi wrote:
>
>> might be unrelated to the loop problem, but...
>
> Aha! I think it *is* related. There were several places where data
> was uninitialized here; mostly because Dan was working on this piece
> while I was working on separate issues which added the new fields
hi,
> YAMAMOTO Takashi wrote:
>
>> with your previous patch or not?
>
> With, thanks.
i tried. unfortunately i can still reproduce the original loop problem.
WARNING: [0] target 0xbb51ef18 tag 4000:4017:7e3:78:0 prior 0xbb51f148 next 0xb
b51edb0
WARNING: [1] target 0xbb51f148 tag 4000:40
Hello list,
ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus
does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c
uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap
file.
I don't understand why it is not needed in the first case. In the
second case I
2011/2/17 Florian Pflug
> On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
> > Any suggestions about how the JDBC driver can express the query to get
> > the behavior that it wants? Specifically, the driver wants to call a
> > particular function with N OUT or INOUT parameters (and maybe some othe
The attached patch removes rules to build a policy package for regression
test and modifies documentation part to introduce steps to run the test.
Thanks,
--
NEC Europe Ltd, Global Competence Center
KaiGai Kohei
> -Original Message-
> From: Kohei Kaigai
> Sent: 15 February 2011 18:27
>
Andrew Dunstan wrote:
>
>
> On 02/17/2011 11:44 AM, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 02/17/2011 11:22 AM, Bruce Momjian wrote:
> >>> psql used to use the native Windows line editing ability --- has that
> >>> changed?
> >>
> >> When did it? Ad what "native" windows line
On 02/17/2011 11:44 AM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 02/17/2011 11:22 AM, Bruce Momjian wrote:
psql used to use the native Windows line editing ability --- has that
changed?
When did it? Ad what "native" windows line editing ability are you
referring to?
There is native W
* Robert Haas (robertmh...@gmail.com) wrote:
> Ugg, wait a minute. This not only adds %U; it also changes the
> behavior of %u, which I don't think we've agreed on. Also, emitting
> 'none' when not SET ROLE has been done is pretty ugly. I'm back to
> thinking we need to push this out to 9.2 and
Andrew Dunstan wrote:
>
>
> On 02/17/2011 11:22 AM, Bruce Momjian wrote:
> > psql used to use the native Windows line editing ability --- has that
> > changed?
>
>
> When did it? Ad what "native" windows line editing ability are you
> referring to?
There is native Windows editing like arrows,
On 02/17/2011 11:22 AM, Bruce Momjian wrote:
psql used to use the native Windows line editing ability --- has that
changed?
When did it? Ad what "native" windows line editing ability are you
referring to?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Tom Lane wrote:
> Would you check whether just casting the function result to (void)
> shuts it up?
Casting the result to (void) didn't change the warning. It shut up
when I declared a local variable and assigned the value to it (which
was then never used).
-Kevin
--
Sent via pgsql-hacker
1 - 100 of 157 matches
Mail list logo
