Hiroshi Saito [EMAIL PROTECTED] wrote:
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
No, definition of _UNICODE is independent from wcsftime (and
other wcs functions). It affects only _tcs
ITAGAKI Takahiro wrote:
Hiroshi Saito [EMAIL PROTECTED] wrote:
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
No, definition of _UNICODE is independent from wcsftime (and
other wcs functions). It
Hiroshi Inoue [EMAIL PROTECTED] wrote:
Please call setlocale(LC_CTYPE/LC_ALL, ) first.
Ah, it works! But setlocale(*, ) means that we always use platform
locale (Japanese and SJIS in Japan). It could be different from server
encoding and locale in postgres. Is it acceptable? I think we need to
David Rowley wrote:
I've created a query that uses the table in your regression test.
max_salary1 gives incorrect results. If you remove the max_salary2 column it
gives the correct results.
Thanks. I saw this myself yesterday, while hacking on the patch. I
thought it was a bug I had
Robert,
big thanks for your review. I think #1 is still partially valid, because it
contains general cleanups, but part of it is not necessary now. #2, #3 and #4
you can move to return with feedback section.
Thanks Zdenek
Robert Haas napsal(a):
Zdenek -
I am a bit murky on
Rob Kirkbride wrote:
I've introduced a --delete-not-drop option which simply does a DELETE FROM %
rather than 'DROP and then CREATE'.
Beware foreign-keys slowing you - TRUNCATE all relevant tables should be
the fastest method if possible.
I hope this sounds sensible and I haven't missed
ITAGAKI Takahiro wrote:
Hiroshi Inoue [EMAIL PROTECTED] wrote:
Please call setlocale(LC_CTYPE/LC_ALL, ) first.
Ah, it works! But setlocale(*, ) means that we always use platform
locale (Japanese and SJIS in Japan).
Maybe you can call setlocale(LC_CTYPE, .20932) instead and you
would get
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the status to 'waiting on author'.
--
Thanks
Bernd
--
Sent via pgsql-hackers
2008/11/26 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/11/26 David Rowley [EMAIL PROTECTED]:
I'm at a bit of a loss to what to do now. Should I wait for your work
Heikki? Or continue validating this patch?
The best thing I can think to do right now is continue and any
Tom Lane wrote:
AFAICS the only way you'd end up with a zombie postmaster is if pg_ctl
stop fails, but I'm failing to understand why that's likely to happen.
No, the zombies appear if the postmaster dies (briefly) after launch.
--
Sent via pgsql-hackers mailing list
On Tue, Nov 25, 2008 at 10:33:05AM -0500, Tom Lane wrote:
I've been chewing on the problem described here:
http://archives.postgresql.org/pgsql-general/2008-11/msg01220.php
It's not particularly easy to fix without making annoyingly large
changes to the API for PQExpBuffer.
Yup, I've just
2008/11/26 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
I read more, and your spooling approach seems flexible for both now
and the furture. Looking at only current release, the frame with ORDER
BY is done by detecting peers in WinFrameGetArg() and add row number
of peers to
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
The visibility map won't be inquired unless you vacuum. This is a bit
tricky. In vacuum, we only know whether we can set a bit or not, after
we've acquired a cleanup lock on the page, and scanned all the tuples.
While we're holding
Rob Kirkbride [EMAIL PROTECTED] writes:
Richard,
Yes, I've changed it use TRUNCATE rather than DELETE and it's working well for
us now.
I'm a bit surprised actually as it sounded like you were aiming to avoid the
table lock. A TRUNCATE does require an exclusive lock on the table. It still
I must admit I've not read up on the various locks that are set so that's a
good point. Is there a good reference for me to read and understand these?
I'm guessing though that a delete from and then an insert never requires an
exclusive lock, what about adding/deleting constraints?
Rob
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
There is another problem, though, if the map is frequently probed for
pages that don't exist in the map, or the map doesn't exist at all.
Currently, the size of the map file is kept in relcache, in the
rd_vm_nblocks_cache variable.
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-11-25 at 20:33 -0500, Tom Lane wrote:
So we really don't have any methodically-gathered evidence about the
effects of different stats settings. It wouldn't take a lot to convince
us to switch to a different default, I think, but it would
Tom Lane [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] writes:
I also do not believe that there is any value that will be the right
answer. But a table of data might be useful both for people who want to
toy with altering the values and also for those who want to set the
defaults.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, considering how seldom new pages will be added to the visibility
map, it seems to me we could afford to send out a relcache inval event
when that happens. Then rd_vm_nblocks_cache could be treated as
trustworthy.
A relcache
On Wed, Nov 26, 2008 at 3:52 PM, Pavan Deolasee [EMAIL PROTECTED]wrote:
I think whats happening is that ResolveRecoveryConflictWithVirtualXIDs() is
failing to abort the open transaction
Btw, ISTM that SIGINT works only for statement cancellation. So if the
transaction is in idle state,
Tom Lane wrote:
I'd vote for keeping the --temp-port option but not having the Makefile
use it. Seems like it'd still be potentially useful for hand use of
pg_regress.
Sorry, I didn't document this fully. The --temp-port option appears to
be redundant with the --port option, so I figured we
Peter Eisentraut [EMAIL PROTECTED] writes:
Then again, a simple way to avoid the issue altogether on platforms
supporting Unix-domain sockets would be to run the test over Unix-domain
sockets (which we do anyway) placed in a private directory. How about that?
Then the brittleness is still
Hitoshi Harada wrote:
I read more, and your spooling approach seems flexible for both now
and the furture. Looking at only current release, the frame with ORDER
BY is done by detecting peers in WinFrameGetArg() and add row number
of peers to winobj-currentpos. Actually if we have capability to
ISTM that the redo conflict resolution is not working as intended. I did the
following test and it throws some surprises.
On standby:
postgres=# BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
BEGIN
postgres=# SELECT * from test;
a | b
-+---
102 |
103 |
(2 rows)
On primary:
Robert Haas [EMAIL PROTECTED] writes:
Imagine for example:
CREATE TABLE foo (c1 integer, c2 text, c3 boolean, c4 date, c5
timestamp, c6 numeric, c7 varchar);
CREATE OR REPLACE VIEW tricky AS SELECT * FROM foo AS bar (a, b, c);
ALTER TABLE foo ALTER COLUMN c2 POSITION LAST;
After some
On Thu, Nov 20, 2008 at 05:07:40PM -0800, Ron Mayer wrote:
Got it.
Patch attached.
Looks reasonable to me.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304,
Michael Meskes [EMAIL PROTECTED] writes:
On Thu, Nov 20, 2008 at 05:07:40PM -0800, Ron Mayer wrote:
Patch attached.
Looks reasonable to me.
Michael, since that's ecpg code, please take charge of committing it
if you want it.
regards, tom lane
--
Sent via
Today I noticed I cannot login to cvs.pgfoundry.org anymore since the
IP address has been changed am asked password which seems to be
changed. So I cannot use CVS any more. Does anybody why this happens
and how to fix it?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-hackers mailing list
1. htup and bufpage API clean up
2. HeapTuple version extension + code cleanup
3. In-place online upgrade
4. Extending pg_class info + more flexible TOAST chunk size
big thanks for your review. I think #1 is still partially valid, because it
contains general cleanups, but part of it is not
On Wed, Nov 26, 2008 at 2:43 PM, Tatsuo Ishii [EMAIL PROTECTED] wrote:
Today I noticed I cannot login to cvs.pgfoundry.org anymore since the
IP address has been changed am asked password which seems to be
changed. So I cannot use CVS any more. Does anybody why this happens
and how to fix it?
Robert Haas escribió:
With respect to #4, I know that Alvaro submitted a draft patch, but
I'm not clear on whether that needs to be reviewed, because:
- I'm not sure whether it's close enough to being finished for a
review to be a good use of time.
- I'm not sure how much you and Heikki
Alvaro Herrera wrote:
Is it possible to make it retry in case the chosen port is busy? I
guess a simple check should suffice, ignoring the obvious race condition
that someone uses the port after you checked it was OK.
Well, the whole point of this exercise was to avoid that. If we had a
way
Heikki Linnakangas [EMAIL PROTECTED] writes:
There is another problem, though, if the map is frequently probed for
pages that don't exist in the map, or the map doesn't exist at all.
Currently, the size of the map file is kept in relcache, in the
rd_vm_nblocks_cache variable. Whenever a
Richard,
Yes, I've changed it use TRUNCATE rather than DELETE and it's working
well for us now.
The switching of the database is a good idea - thanks. Unfortunately,
we've not got enough disk space currently to do that, but if we get
problems in the future that will definitely be something
Hello
I added two new columns to pg_proc. I have a problem because access
via SearchSysCache doesn't work
/* Search syscache by name only */
catlist = SearchSysCacheList(PROCNAMEARGSNSP, 1,
CStringGetDatum(funcname),
Alvaro Herrera napsal(a):
Robert Haas escribió:
With respect to #4, I know that Alvaro submitted a draft patch, but
I'm not clear on whether that needs to be reviewed, because:
- I'm not sure whether it's close enough to being finished for a
review to be a good use of time.
- I'm not sure how
Pavel Stehule [EMAIL PROTECTED] writes:
I added two new columns to pg_proc. I have a problem because access
via SearchSysCache doesn't work
Well, you blew the catalog modifications somewhere, but since you
haven't shown us what you did it's hard to guess where.
You might want to pull the diffs
some more info:
CATALOG(pg_proc,1255) BKI_BOOTSTRAP
{
NameDataproname;/* procedure name */
Oid pronamespace; /* OID of namespace
containing this proc */
Oid proowner; /* procedure owner */
Hi,
Le mercredi 26 novembre 2008, Tom Lane a écrit :
You might want to pull the diffs for some past pg_proc addition from
CVS and go over the changes. This one is a good minimal example:
http://archives.postgresql.org/pgsql-committers/2005-03/msg00433.php
The following link should help the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, considering how seldom new pages will be added to the visibility
map, it seems to me we could afford to send out a relcache inval event
when that happens. Then rd_vm_nblocks_cache could be treated as
Pavel Stehule [EMAIL PROTECTED] writes:
some more info:
/* VARIABLE LENGTH FIELDS: */
oidvector proargtypes;/* parameter types (excludes
OUT params) */
Oid proallargtypes[1]; /* all
param types (NULL if IN o
char
2008/11/26 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
some more info:
/* VARIABLE LENGTH FIELDS: */
oidvector proargtypes;/* parameter types (excludes
OUT params) */
Oid proallargtypes[1]; /* all
On 11/26/08, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Nov 24, 2008 at 10:25 AM, Marko Kreen [EMAIL PROTECTED] wrote:
IOW, DISCARD ALL should be functionally equivalent to backend exit.
Having done a lot of work with advisory locks, I support this
On Wed, Nov 26, 2008 at 09:31:48AM -0500, Tom Lane wrote:
Michael, since that's ecpg code, please take charge of committing it
if you want it.
Okay, done. I wasn't sure whether this was related to a backend patch that was
still under review.
Michael
--
Michael Meskes
Michael at Fam-Meskes
On Tue, Nov 25, 2008 at 06:59:25PM -0800, Dann Corbit wrote:
I do have a statistics idea/suggestion (possibly useful with some future
PostgreSQL 9.x or something):
It is a simple matter to calculate lots of interesting univarate summary
statistics with a single pass over the data (perhaps
Michael Meskes [EMAIL PROTECTED] writes:
On Wed, Nov 26, 2008 at 09:31:48AM -0500, Tom Lane wrote:
Michael, since that's ecpg code, please take charge of committing it
if you want it.
Okay, done. I wasn't sure whether this was related to a backend patch that was
still under review.
No, the
On Wed, 26 Nov 2008, Dave Page wrote:
It's the same IP address - but try port 35 for ssh. Marc changed it
(temporarily) due to a vast number of malicious connection attempts.
Why wasn't this change communicated to anyone, not even gforge-admins?
How temporary is temporary?
Kris Jurka
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's another updated patch, including all your bug fixes.
I did a very fast pass through this and have a few comments.
* Don't bother manually updating keywords.sgml. As stated therein, that
table is automatically generated. All you'll
On Wed, Nov 26, 2008 at 11:06 AM, Marko Kreen [EMAIL PROTECTED] wrote:
I think this should be back-patched as well:
- The fact that disconnect will clean up used resources has been
always true, thus most clients assume at some level.
- DISCARD ALL was new feature in 8.3. It is highly
Kris Jurka wrote:
On Wed, 26 Nov 2008, Dave Page wrote:
It's the same IP address - but try port 35 for ssh. Marc changed it
(temporarily) due to a vast number of malicious connection attempts.
Why wasn't this change communicated to anyone, not even gforge-admins?
How temporary is
On Wed, 26 Nov 2008, Steve Crawford wrote:
Obscurity should not be your *only* line of defense, but camouflage
helps as well. And even if it didn't, it still reduces server-load,
bandwidth and heaps of logfile cruft.
In order case, thankfully, there was minimal banwidth impact, but the
On Tue, Nov 25, 2008 at 12:23:45PM -0300, Alvaro Herrera wrote:
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use
Rob Kirkbride [EMAIL PROTECTED] writes:
I must admit I've not read up on the various locks that are set so that's a
good point. Is there a good reference for me to read and understand these?
I'm guessing though that a delete from and then an insert never requires an
exclusive lock, what
I see your point but there's a pretty high standard for changing
existing behavior in bugfix releases. It's just as likely to introduce
an application bug as to fix one...suppose the application is using
both 'discard all' for prepared statements and advisory locks for
other purposes. You
Merlin Moncure [EMAIL PROTECTED] writes:
On Wed, Nov 26, 2008 at 11:06 AM, Marko Kreen [EMAIL PROTECTED] wrote:
I think this should be back-patched as well:
- The fact that disconnect will clean up used resources has been
always true, thus most clients assume at some level.
- DISCARD ALL
David Fetter wrote:
It sounds to me like this should use SQL/MED connections, if it's
holding auth information :)
No, the SQL/MED stuff holds authentication information to authenticate
to other data sources. This is about authentication of *incoming*
connections.
--
Heikki Linnakangas
On Sunday 23 November 2008 15:50:09 Andrew Dunstan wrote:
Tom Lane wrote:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes:
Is $SUBJECT possible? If not, do you think it would be worth
implementing this?
No, and no. The feature isn't even in core; it can hardly qualify as
On Nov 25, 2008, at 8:59 PM, Dann Corbit wrote:
It is a simple matter to calculate lots of interesting univarate
summary
statistics with a single pass over the data (perhaps during a vacuum
full).
I don't think that the problem we have is how to collect statistics
(well, except for
On Nov 25, 2008, at 7:06 PM, Gregory Stark wrote:
The thought occurs to me that we're looking at this from the
wrong side of the
coin. I've never, ever seen query plan time pose a problem with
Postgres, even
without using prepared statements.
I certainly have seen plan times be a
On Wed, Nov 26, 2008 at 8:13 PM, Gregory Stark [EMAIL PROTECTED] wrote:
DISCARD ALL was specifically added in 8.3 for the purpose of connection
poolers to be a big hammer that exactly emulates a new session. I'm somewhat
skeptical that there are any applications using it directly at all, and
On Nov 25, 2008, at 9:41 PM, Robert Haas wrote:
Changing physical positioning is purely an internal matter. A
first-cut
implementation should probably just make it identical to logical
positioning, until the latter is changed by the user (after which,
physical positioning continues to reflect
Decibel! [EMAIL PROTECTED] writes:
On Nov 25, 2008, at 7:06 PM, Gregory Stark wrote:
The thought occurs to me that we're looking at this from the wrong side of
the
coin. I've never, ever seen query plan time pose a problem with Postgres,
even
without using prepared statements.
I
Steve Crawford wrote:
I have changed the external ssh port on all machines I administer. The
result is the complete elimination of the previous hundreds to thousands
of daily script-kiddie brute-force attempts I used to see.
+1
We have not used port 22 in our production network for
On Wed, Nov 26, 2008 at 09:15:49PM +0200, Heikki Linnakangas wrote:
David Fetter wrote:
It sounds to me like this should use SQL/MED connections, if it's
holding auth information :)
No, the SQL/MED stuff holds authentication information to authenticate
to other data sources. This is about
On Wed, Nov 26, 2008 at 10:51:23AM -0800, Steve Crawford wrote:
Kris Jurka wrote:
On Wed, 26 Nov 2008, Dave Page wrote:
It's the same IP address - but try port 35 for ssh. Marc changed
it (temporarily) due to a vast number of malicious connection
attempts.
Why wasn't this change
Gregory Stark [EMAIL PROTECTED] writes:
Merlin Moncure [EMAIL PROTECTED] writes:
I see your point but there's a pretty high standard for changing
existing behavior in bugfix releases.
DISCARD ALL was specifically added in 8.3 for the purpose of
connection poolers to be a big hammer that
On Wed, Nov 26, 2008 at 3:42 PM, Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Merlin Moncure [EMAIL PROTECTED] writes:
I see your point but there's a pretty high standard for changing
existing behavior in bugfix releases.
DISCARD ALL was specifically added in 8.3
Guillaume Smet [EMAIL PROTECTED] writes:
I kinda agree with you. The only problem IMHO is that we described in
the doc exactly what it does and not simply as the big hammer it was
supposed to be. See
http://www.postgresql.org/docs/8.3/interactive/sql-discard.html .
Well, the *first* sentence
On Wed, Nov 26, 2008 at 9:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
Well, the *first* sentence there says it resets the session to its
initial state, so it seems to me the intent is clear. But maybe we
should alter the second sentence to read, say, This _currently_ has the
same effect as ...,
On Wed, Nov 5, 2008 at 11:47 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
On Fri, Oct 31, 2008 at 7:42 PM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
Hi Nikhil,
i'm looking at this one:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
'cause the great interest this one has (i'm
i get lost with this one... i thought there were two patches that get
merged into one, but i don't find nor the merged version nor the
actualized version of any of one...
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Decibel! [EMAIL PROTECTED] wrote:
On Nov 25, 2008, at 7:06 PM, Gregory Stark wrote:
The thought occurs to me that we're looking at this from the
wrong side of the
coin. I've never, ever seen query plan time pose a problem with
Postgres, even
without using prepared statements.
I
'cause the great interest this one has (i'm being ironic, just in case
;) can we safely say this was returned with feedback and remove it
from the list of pending patches?
Um... are you referring to lack of interest from the patch author, or
from the community?
If the patch author is no
Kevin Grittner [EMAIL PROTECTED] wrote:
I hadn't
tried it lately, so I just gave it a go with switching from a
default
statistics target of 10 with no overrides to 1000.
Oh, this was on 8.2.7, Linux, pretty beefy machine. Do you want the
whole set of config info and the hardware specs, or
David Fetter wrote:
We should move to a port-knocking
http://dotancohen.com/howto/portknocking.html or other modern
strategy if we're going to move at all.
Yeah, but telling my firewall to move port 22 inside to port
outside took less time than writing this email. Inside the firewall
On Wed, 2008-11-26 at 13:57 -0800, Steve Crawford wrote:
David Fetter wrote:
We should move to a port-knocking
http://dotancohen.com/howto/portknocking.html or other modern
strategy if we're going to move at all.
Yeah, but telling my firewall to move port 22 inside to port
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, November 26, 2008 14:00:59 -0800 Joshua D. Drake
[EMAIL PROTECTED] wrote:
Since were chatting :P. My vote would be to move everything back to port
22 and force key based auth only.
How does that work? Does that kill the
Marc G. Fournier wrote:
How would someone upload their key if they don't have access? Some sort of
web
interface? One wouldn't want to throw extra admin overhead if it can be
avoided ...
pgfoundry already has a web interface for uploading SSH keys.
--
Alvaro Herrera
Marc G. Fournier wrote:
Since were chatting :P. My vote would be to move everything back to port
22 and force key based auth only.
How does that work? Does that kill the script kiddies in their tracks? I'm
guessing so, but had never thought to try it ...
Depends on where the problem is.
On Wed, 2008-11-26 at 18:06 -0400, Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since were chatting :P. My vote would be to move everything back to port
22 and force key based auth only.
How does that work? Does that kill the script kiddies in their tracks? I'm
Joshua D. Drake wrote:
On Wed, 2008-11-26 at 18:06 -0400, Marc G. Fournier wrote:
Since were chatting :P. My vote would be to move everything back to port
22 and force key based auth only.
How does that work? Does that kill the script kiddies in their tracks? I'm
guessing so,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, November 26, 2008 14:12:42 -0800 Joshua D. Drake
[EMAIL PROTECTED] wrote:
Well they can still talk to the port of course but its irrelevant
because unless they have an ssh key, they aren't getting in. Period.
Well, they
Marc G. Fournier [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Well they can still talk to the port of course but its irrelevant
because unless they have an ssh key, they aren't getting in. Period.
Well, they weren't getting in before ... i twas the massive flood of attempts
that was
Marc G. Fournier wrote:
- --On Wednesday, November 26, 2008 14:12:42 -0800 Joshua D. Drake
[EMAIL PROTECTED] wrote:
Well they can still talk to the port of course but its irrelevant
because unless they have an ssh key, they aren't getting in. Period.
Well, they weren't getting in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, November 26, 2008 17:42:12 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Well they can still talk to the port of course but its irrelevant
because unless they have
This patch:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00356.php
which was alleged to prevent memory leaks, seems to have introduced
some. The problem is that shutdown_MultiFuncCall() now performs a
MemoryContextSwitchTo(flinfo-fn_mcxt);
which means that an exiting SRF
On 26/11/2008, Hitoshi Harada [EMAIL PROTECTED] wrote:
2008/11/26 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
-- The following query gives incorrect results on the
-- maxhighbid column
SELECT auctionid,
category,
On Wed, Nov 26, 2008 at 10:52 PM, Robert Haas [EMAIL PROTECTED] wrote:
'cause the great interest this one has (i'm being ironic, just in case
;) can we safely say this was returned with feedback and remove it
from the list of pending patches?
the patch is on the
commitfest wiki[1] and you
2008/11/27 Tom Lane [EMAIL PROTECTED]:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's another updated patch, including all your bug fixes.
I did a very fast pass through this and have a few comments.
Thanks for your comments. The executor part is now being refactored by
Heikki, but
i review it on nov 6, and there were open questions by me and by
Emmanuel none of those has been answered:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php
Hmm, there's only one actual question in that email, which is a
request for ideas about PL/pgsql vs. C. I suspect you
On Wed, Nov 26, 2008 at 4:38 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
i get lost with this one... i thought there were two patches that get
merged into one, but i don't find nor the merged version nor the
actualized version of any of one...
Simon said he would split the infrastructure
Though it is a somewhat separate problem from current patch I'd like to
do something about it before having it all committed, as the fix must
touch the very same places than this patch.
I think it takes two-tree days to figure out proper way to fix it.
I'd like it to just accept ANY* and do
Heikki Linnakangas wrote:
This patch:
commit 35ad25ad66fa3999bbc0bb59ca13cef3d750fb07
Author: Tom Lane [EMAIL PROTECTED]
Date: Sat Jul 26 19:15:35 2008 +
As noted by Andrew Gierth, there's really no need any more to force a
junk
filter to be used when INSERT or SELECT INTO
Can someone remind me why we have --enable-thread-safety? As opposed
to it being default and having --disable-thread-safety.
/Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
94 matches
Mail list logo
