On Wed, Dec 9, 2009 at 6:25 PM, Fujii Masao wrote:
> Here is the patch:
>
> - Write an XLOG UNLOGGED record in WAL if WAL-logging is skipped for only
> the reason that WAL archiving is not enabled and such record has not been
> written yet.
>
> - Cause archive recovery to end if an XLOG UNLOGGED
Hi,
I want to add some hard-wired extra authentication codes in my PG. The only
problem is how to access tables to get/change information from core
(auth.c)?
I have changed the SPI functions to use them but it was not effective (lots
of different errors!)
In fact, i want to add a table to system ca
On Mon, Jan 4, 2010 at 9:55 PM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Here's is modified patch that adds a new backupStartPoint field to
>> pg_control for that + some other minor editorialization.
>
> I've committed this now.
Thanks a lot!
src/backend/access/transam/xlog.c
> e
Bruce Momjian writes:
> Well, when you restore the old dump's schema into the new server, the
> tablespace directory path will be the same, so we had better not have
> any directory there.
If we implicitly added "/8.5" etc at the end of the specified tablespace
path, the problems go away.
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> I thought it was impossible to use bare mountpoints as tablespaces due
>> to ownership problems ... Is that not the case? -1 for special hacks
>> that work around bogus setups, if that means intrusive changes to the
>> core code.
> I talked to the
On Jan 4, 2010, at 8:18 PM, Robert Haas wrote:
> Is this something you are planning to work on for the 2010-01-15
> CommitFest? If not, I think we should go ahead and mark the patch
> which was the original subject of this thread "Returned with
> Feedback", as it does not seem to make sense to ad
Robert Haas writes:
> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule wrote:
>> I don't have a problem to write second and safe fmtId
>> function (with technique used in dumputils don't need to modify
>> libpq), although fmtId do exactly what I need. I would to understand
>> to behave.
> I think y
In talking to developers, it appears that index-only scans will not be
implemented in Postgres 8.5 due to development time being spend on hot
standby and streaming replication. The current index-only scan status
is summarized here:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg0
On Sun, Jan 3, 2010 at 1:51 PM, David E. Wheeler wrote:
> On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
>
>> I think the minimal functionality I'd want is:
>>
>> convert record to JSON
>> convert JSON to record
>
> With caveats as to dealing with nested structures (can a record be an
> at
On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule wrote:
> 2010/1/4 Tom Lane :
>> Pavel Stehule writes:
>>> I have one question. If I understand well, the function fmtId isn't
>>> multibyte safe? So why is possible to use it in pg_dump?
>>
>> pg_dump is only guaranteed to work correctly in the server
On Mon, Jan 4, 2010 at 11:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think you're dismissing the idea too cavalierly. If A generates B,
>> A is inevitably changed frequently, but the changes to A affect B only
>> rarely, this is a good trick.
>
> The only output file that is unlikely to c
Robert Haas writes:
> I think you're dismissing the idea too cavalierly. If A generates B,
> A is inevitably changed frequently, but the changes to A affect B only
> rarely, this is a good trick.
The only output file that is unlikely to change is schemapg.h, which is
depended on by exactly one .
Greg Stark escribió:
> I think there's a trick to cover this case but I don't recall what it is.
>
> Does generating a stamp file help? If you had a rule saying to trigger
> generating the output files because the stamp file is out of date
> which might or might not touch the .h file which would
On Mon, Jan 4, 2010 at 10:53 PM, Greg Stark wrote:
> On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote:
>>> Log Message:
>>> ---
>>> Remove too-smart-for-its-own-good optimization of not overwriting the output
>>> files when they haven't
On Mon, Jan 4, 2010 at 10:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote:
>>> Log Message:
>>> ---
>>> Remove too-smart-for-its-own-good optimization of not overwriting the output
>>> files when they haven't changed. This confuses make bec
On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas wrote:
> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote:
>> Log Message:
>> ---
>> Remove too-smart-for-its-own-good optimization of not overwriting the output
>> files when they haven't changed. This confuses make because the build fails
>> to
Robert Haas writes:
> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote:
>> Log Message:
>> ---
>> Remove too-smart-for-its-own-good optimization of not overwriting the output
>> files when they haven't changed. This confuses make because the build fails
>> to update the file timestamps, an
On Mon, Jan 4, 2010 at 10:44 PM, Takahiro Itagaki
wrote:
> Robert Haas wrote:
>
>> What is currently done for other, similar error messages?
>
> Current error messages are:
> for commands: ": out of memory"
> for others : "Couldn't allocate memory for variable"
>
> The new message is: ": out o
Robert Haas wrote:
> What is currently done for other, similar error messages?
Current error messages are:
for commands: ": out of memory"
for others : "Couldn't allocate memory for variable"
The new message is: ": out of memory for variable ''"
Regards,
---
Takahiro Itagaki
NTT Open Sou
On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote:
> Log Message:
> ---
> Remove too-smart-for-its-own-good optimization of not overwriting the output
> files when they haven't changed. This confuses make because the build fails
> to update the file timestamps, and so it keeps on doing the a
On Mon, Jan 4, 2010 at 10:00 PM, Takahiro Itagaki
wrote:
>
> Takahiro Itagaki wrote:
>
>> We can remove the complexity if we give up showing the command (arg0)
>> in error messages. Shall we remove it? Simplified patch attached.
>
> Here is the proposal for the arg0 issue.
> I added "context" arg
Bruce Momjian wrote:
> 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 be
Bruce Momjian wrote:
> 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 be
FWIW, the old make rule was
fmgroids.h fmgrtab.c: (deps)
which is now
fmgroids.h: fmgrtab.c ;
fmgrtab.c: (deps)
I was going by this comment in parser/Makefile:
# There is no correct way to write a rule that generates two files.
# Rules with two targets don't have that meaning, they are merel
Takahiro Itagaki wrote:
> We can remove the complexity if we give up showing the command (arg0)
> in error messages. Shall we remove it? Simplified patch attached.
Here is the proposal for the arg0 issue.
I added "context" argument to putVariable(). The context is a command
name for \setXXX com
The old Gen_fmgrtab.sh script used temporary file names that included
its process PID. It had this comment about that:
# We use the temporary files to avoid problems with concurrent runs
# (which can happen during parallel make).
The new implementation uses temp files that just have ".tmp" appen
On Mon, Jan 4, 2010 at 8:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs wrote:
>>> Changes required to remove it are at least these places
>>>
>>> * most of vacuum.c
>>> * visibility checks
>>> * heap tuple flags and xvac
>>> * nontransactional valida
On Mon, Jan 4, 2010 at 1:51 PM, Boszormenyi Zoltan wrote:
> new patch is attached. Modified according to
> the new DB2 / Sybase compatible SQLDA structure.
> ECPGdescribe() has an "int compat" parameter, because:
> - the (struct prepared_statement *)->stmt ->compat is not set, and
> - it's more se
Robert Haas writes:
> On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs wrote:
>> Changes required to remove it are at least these places
>>
>> * most of vacuum.c
>> * visibility checks
>> * heap tuple flags and xvac
>> * nontransactional validation
>> * minor points and follow up in >7 files, >12 pla
On Mon, Jan 4, 2010 at 8:12 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> I did a quick read-through of this, and one question that immediately
>> occurred to me is that rbtree.c says that it is adopted from
>> http://algolist.manual.ru/ds/rbtree.php. But I'm not sure what
>> license that
Robert Haas escribió:
> I did a quick read-through of this, and one question that immediately
> occurred to me is that rbtree.c says that it is adopted from
> http://algolist.manual.ru/ds/rbtree.php. But I'm not sure what
> license that code is under, so I'm not sure whether it's OK for us to
> u
Tom,
It seems I introduced a couple errors in src/tools/msvc/clean.bat in
the bki patch. I'm attaching a cumulative fix. I can resend the
complete updated patch, if you like...
Sorry! :-)
John
> I'm planning to go look at Naylor's bki refactoring patch now. Assuming
> there isn't any showstoppe
On Mon, 2010-01-04 at 16:41 -0500, Robert Haas wrote:
> > I propose we have a WARNING if VFI being run when recovery_connections =
> > on, since I probably know what I'm doing if I go out of my way to use
> > new syntax after presumably having read the manual.
>
> I think I'd vote for throwing an
I wrote:
> Peter Eisentraut writes:
>> This should in principle work. My guess is an old make version being
>> confused.
> Well, I am testing with relatively old make and gcc too, but what it
> looks like to me is that we need to add a "-I." switch in places where we
> might need to #include a f
> I think I'd vote for throwing an ERROR. By the time you see the
> WARNING it may be too late. Since this is only for emergencies, the
> user can shut off recovery_connections first if they really need it.
I'm with Robert on this one. If running VFI will cause unrecoverable
failure on the sla
Peter Eisentraut writes:
> On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
>> I thought the current plan was that derived files should be generated in
>> the build tree (as indeed it seems to be doing) ... but there are
>> apparently parts of the Makefiles that are not in sync with this plan.
On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
> It seems like VPATH building is broken at the moment, at least if you
> are working from a maintainer-clean source tree.
>
> make -C bootstrap all
> make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
> /usr/local/bin/bison
It seems like VPATH building is broken at the moment, at least if you
are working from a maintainer-clean source tree.
make -C bootstrap all
make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
/usr/local/bin/bison -o bootparse.c
/home/postgres/pgsql/src/backend/bootstrap/boo
On Jan 4, 2010, at 3:29 PM, Peter Eisentraut wrote:
> If you're not deep into Perl, perhaps ignore the Test::More comment for
> the moment and just use DBI to connect to several database sessions,
> execute your queries and check if the results are what you want. Once
> you have gotten somewhere
Andrew Dunstan wrote:
Yes. I believe the test is highlighting an existing problem: that plperl
function in non-PG_UTF8 databases can't use regular expressions that
require unicode character meta-data.
Either the (GetDatabaseEncoding() == PG_UTF8) test in plperl_safe_init()
should be removed,
On mån, 2010-01-04 at 17:10 -0600, Kevin Grittner wrote:
> "David E. Wheeler" wrote:
>
> > I think the consensus was, failing support for concurrent sessions
> > in psql, to use a Perl script to control multiple psql sessions
> > and perhaps use Test::More to do the testing.
>
> Are there any
"David E. Wheeler" wrote:
> I think the consensus was, failing support for concurrent sessions
> in psql, to use a Perl script to control multiple psql sessions
> and perhaps use Test::More to do the testing.
Are there any examples of that? While I can hack my way through
regular expressions
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey wrote:
> I'm sure whatever conclusion -hackers comes to in the end will be the
> best for pgsql, and I'll be supportive. But until then, let me note
> from the PostGIS point-of-view: sure would be great to get this in for
> 8.5 :)
That's good to know.
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view: sure would be great to get this in for
8.5 :)
P.
On Thu, Dec 31, 2009 at 4:26 AM, Greg Stark wrote:
> On Wed, Dec 30, 2009 at
Robert Haas wrote:
> >> But can't we just call a special function first before running the
> >> CREATE TABLESPACE, like:
> >>
> >> pg_tablespace_dont_really_create_this_tablespace_because_we_are_in_pg_migrator()?
> >>
> >> Sorta like what you did to preserve ENUM OIDs, etc.?
> >
> > Well, the probl
On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> >> What doesn't work if we just don't rename the tablespace at all? ?And
>> >> >> can't we put some smarts into the backend to handle that thing?
>> >> >
>> >> > Well, when you restore the old dump's schema into the ne
Robert Haas wrote:
> >> >> What doesn't work if we just don't rename the tablespace at all? ?And
> >> >> can't we put some smarts into the backend to handle that thing?
> >> >
> >> > Well, when you restore the old dump's schema into the new server, the
> >> > tablespace directory path will be the s
On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
>> >> > Alvaro Herrera wrote:
>> >> >> > 2) ?Right now pg_migrator renames old tabl
On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs wrote:
> On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote:
>> >> What I should have said, in addition: VFI will be kept as a non-default
>> >> option, in case it is required. We will document that use of VFI will
>> >> not work correctly with HS and
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>> Guillaume Lelarge writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
> I think we were stalled on the question of whether to use one array
>
Tom Lane wrote:
> Magnus Hagander writes:
>> ...oom_adj...
>
> One interesting thing I read there is:
> Swapped out tasks are killed first. Half of each child's memory size is
> added to the parent's score if they do not share the same memory.
> ^^^
On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote:
> >> What I should have said, in addition: VFI will be kept as a non-default
> >> option, in case it is required. We will document that use of VFI will
> >> not work correctly with HS and that its use is deprecated and should be
> >> in emergenc
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > > if the tablespaces are on mount points. I have already received a
> > > report of such a failure.
> >
> > I thought it was impossible to use bare mountpoints as tablespa
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> >> > Alvaro Herrera wrote:
> >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
> >> >> > if the tablespaces are
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
>> > Alvaro Herrera wrote:
>> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
>> >> > if the tablespaces are on mount points. ?I have alrea
>> What I should have said, in addition: VFI will be kept as a non-default
>> option, in case it is required. We will document that use of VFI will
>> not work correctly with HS and that its use is deprecated and should be
>> in emergencies only in any case. I will enjoy removing VFI when that
>>
Josh Berkus writes:
>> Great. When you have it set up, you might want to play with enabling
>> the mergejoinscansel change as well, and see if that is a net plus or
>> minus for you.
> How would I *disable* it?
It's #ifdef NOT_USED in CVS at the moment.
regards, tom lan
> Great. When you have it set up, you might want to play with enabling
> the mergejoinscansel change as well, and see if that is a net plus or
> minus for you.
How would I *disable* it?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Mon, Jan 4, 2010 at 11:57 AM, Simon Riggs wrote:
> On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs wrote:
>> > This is a more cautious approach. Completely removing VFI in this
>> > release is a big risk that we need not take; we have little
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
> >> > if the tablespaces are on mount points. ?I have already received a
> >> > report of such a failure.
> >>
> >> I t
Tom Lane wrote:
> Bruce Momjian writes:
> > I was just really asking if disallowing pg_resetxlog -n on a live server
> > is planned behavior or an oversight. I can see the logic that it should
> > be disallowed but I am just looking for confirmation from someone and I
> > can then drop the issue.
2010/1/4 Tom Lane :
> Pavel Stehule writes:
>> I have one question. If I understand well, the function fmtId isn't
>> multibyte safe? So why is possible to use it in pg_dump?
>
> pg_dump is only guaranteed to work correctly in the server encoding.
> If you force it to use a client_encoding differe
On Mon, Jan 4, 2010 at 5:17 AM, Leonardo F wrote:
> Re-reading the docs it looks like the only thing missing is get/set_bit for
> bit string.
>
> Substring is already implemented for bit string, and I don't really know if
> replace is useful at all.
>
> (sorry if the other mail came with a diffe
Tom Lane írta:
> Alvaro Herrera writes:
>
>> I'm not sure how portable is the LONG_BIT business.
>>
>
> I think checking SIZEOF_LONG would be preferred, since that's what
> we use elsewhere. Although actually I wonder why this code exists
> at all --- wouldn't it be easier to make these d
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
>> > if the tablespaces are on mount points. I have already received a
>> > report of such a failure.
>>
>> I thought it was impossible to use b
Alvaro Herrera writes:
> I'm not sure how portable is the LONG_BIT business.
I think checking SIZEOF_LONG would be preferred, since that's what
we use elsewhere. Although actually I wonder why this code exists
at all --- wouldn't it be easier to make these depend on "int64"?
Bruce Momjian writes:
> I was just really asking if disallowing pg_resetxlog -n on a live server
> is planned behavior or an oversight. I can see the logic that it should
> be disallowed but I am just looking for confirmation from someone and I
> can then drop the issue.
Well, it's not only a ma
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> My only objection to that is that if we're going to add attoptions
>> also, I'd like to get this committed first before I start working on
>> that, and we're running short on time. If you can commit his patch in
>> the next
Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
> I happened to notice this by chance:
>
>
>> + #if (LONG_BIT == 64)
>> + #defineSQLINT8 ECPGt_long
>> + #defineSQLSERIAL8 ECPGt_long
>> + #else
>> + #defineSQLINT8 ECPGt_long_long
>> + #defineSQLSERIAL8
Alvaro Herrera wrote:
> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > if the tablespaces are on mount points. I have already received a
> > report of such a failure.
>
> I thought it was impossible to use bare mountpoints as tablespaces due
> to ownership problems .
Boszormenyi Zoltan wrote:
I happened to notice this by chance:
> + #if (LONG_BIT == 64)
> + #define SQLINT8 ECPGt_long
> + #define SQLSERIAL8 ECPGt_long
> + #else
> + #define SQLINT8 ECPGt_long_long
> + #define SQLSERIAL8 ECPGt_long_long
> + #endif
I'm n
On Mon, Jan 4, 2010 at 10:42 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> Hmm, I see this needs to be rebased over Tom's latest changes, but the
>> conflict I got was in syscache.h, rather than syscache.c. Not sure if
>> that's what you were going for or if there's another issue. Updat
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > I considered that but realize that pg_migrator has to read
> > pg_controldata in both the old and new servers, meaning it would need
> > access to both C structures, and considering they both have the same
> > structure names, that would requir
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > 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 preserv
> I've applied a patch to HEAD that does the above. Can you test it to
> see how well it fixes your problem?
Sure. It'll take us a while to set up a test environment; the database
is 1TB in size so converting it to 8.5 isn't quick.
Will report back.
--Josh
--
Sent via pgsql-hackers mailing
Robert Haas writes:
> My only objection to that is that if we're going to add attoptions
> also, I'd like to get this committed first before I start working on
> that, and we're running short on time. If you can commit his patch in
> the next day or two, then I am fine with rebasing mine afterwar
Josh Berkus writes:
>> I've applied a patch to HEAD that does the above. Can you test it to
>> see how well it fixes your problem?
> Sure. It'll take us a while to set up a test environment; the database
> is 1TB in size so converting it to 8.5 isn't quick.
Great. When you have it set up, you
On Mon, Jan 4, 2010 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, I see this needs to be rebased over Tom's latest changes, but the
>> conflict I got was in syscache.h, rather than syscache.c. Not sure if
>> that's what you were going for or if there's another issue. Updated
>> patc
Robert Haas writes:
> Hmm, I see this needs to be rebased over Tom's latest changes, but the
> conflict I got was in syscache.h, rather than syscache.c. Not sure if
> that's what you were going for or if there's another issue. Updated
> patch attached.
I'm planning to go look at Naylor's bki re
Tom Lane wrote:
> This suggests that PG's shared memory ought not be counted in the
> postmaster's OOM score, which would mean that the problem
> shouldn't be quite as bad as we've believed. I wonder if that is
> a recent change? Or maybe it's supposed to be that way and is not
> implemented c
Bruce Momjian escribió:
> I considered that but realize that pg_migrator has to read
> pg_controldata in both the old and new servers, meaning it would need
> access to both C structures, and considering they both have the same
> structure names, that would require some odd C tricks. Add to that
On Sun, Jan 3, 2010 at 11:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2010/1/3 KaiGai Kohei :
>>> if (number_of_attribute_origin(myrelid, oldattname) > 1)
>>> ereport(ERROR, ...);
>>>
>>> Am I missing something?
>
>> That sounds about right to me,
>
> It looks remarkably inefficient to
Robert Haas wrote:
> >> 4) ?I have implemented the ability to run pg_migrator --check on a live
> >> old server. ?However, pg_migrator uses information from controldata to
> >> check things, and it also needs xid information that is only available
> >> via pg_resetxlog -n(no update) to perform the
Magnus Hagander writes:
> I realize this is a very platform-specific thing, but should we
> consider setting the value of /proc//oom_adj when running on
> linux? See:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9b
Robert Haas wrote:
> >> 3) ?There is no easy way to analyze all databases. ?vacuumdb --analyze
> >> does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> >> unnecessary vacuum. ?Right now I recommend ANALYZE in every database,
> >> but it would be nice if there were a single comman
Alvaro Herrera wrote:
> > 3) There is no easy way to analyze all databases. vacuumdb --analyze
> > does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> > unnecessary vacuum. Right now I recommend ANALYZE in every database,
> > but it would be nice if there were a single command
On Fri, Jan 1, 2010 at 20:45, Magnus Hagander wrote:
> On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada wrote:
>>
>> 2) use appropriate macro and datatypes for Windows API.
>> enables more than 32bits shared memory.
>
> Are you sure this one should use __noop, and not __nop?
>
> __noop: http://msdn
2009/12/31 Hitoshi Harada :
> Attached is the fix pointed out in the previous CommitFest plus RANGE
> offset support.
Improved version attached. In this revision I fixed type mismatch case
like "ORDER BY int4_data RANGE BETWEEN int8_data PRECEDING ...".
Update of comments and fix typos in documen
Magnus Hagander wrote:
> On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera
> wrote:
> > BTW, is it possible for pg_ctl to disable OOM-killer? I guess not,
> > since it's not run by root ...
>
> No, it has to run as root.
We could at least make it work on Windows, since it is often run as
Administr
Alvaro Herrera writes:
> Is there a way to disable memory overcommit for particular processes?
I would think not --- the very essence of overcommit is that you're
promising more total memory than the system has got, and that's
inherently a global proposition.
regards, tom
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Right. Which is why I like the idea of disabling the OOM killer for
>> the *postmaster*, but not the regular backends. Gives it a chance to
>> recover. It's not nice, but it's better than nothing.
>
> It doesn't soun
On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
> On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs wrote:
> > This is a more cautious approach. Completely removing VFI in this
> > release is a big risk that we need not take; we have little to gain from
> > doing so and putting it back again will
Magnus Hagander wrote:
> Right. Which is why I like the idea of disabling the OOM killer for
> the *postmaster*, but not the regular backends. Gives it a chance to
> recover. It's not nice, but it's better than nothing.
It doesn't sound like the init script can reenable the killer for the
child p
Greg Smith writes:
> In http://archives.postgresql.org/pgsql-hackers/2008-02/msg00049.php Tom
> points out that while you could make this adjustment in the init scripts
> for PostgreSQL, actually doing so is quite questionable as a packaging
> decision.
I just wondered if it would be questione
On Mon, Jan 4, 2010 at 17:40, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
>
> Magnus Hagander wrote:
>>
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value
Mark Cave-Ayland writes:
> Hmmm it looks as if the code was correct but I missed the comment at the
> top of the file. Sorry for the confusion - revised version attached.
Applied with minor fixups (mostly improving the documentation, which
was not in very good shape beforehand...)
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id/2
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
>> wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//o
On Wed, 2009-12-30 at 17:16 +0100, Tom Lane wrote:
> I think the cleanest solution to this would be to make ANALYZE
> cheaper, perhaps by finding some way for it to work incrementally.
What if when inserting/deleting a tuple, some random sample of them
would be passed into an auto-analyze buffer ?
1 - 100 of 128 matches
Mail list logo
