On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly flyusa2...@gmail.com wrote:
hi, folks!
I see that shared cache is implemented by system v shared memory. I wonder
whether data in this area can be swapped out to disk.
Isn't it bad that we read data from disk, put data in shared cache, and
On Sat, Dec 18, 2010 at 20:29, David E. Wheeler da...@kineticode.com wrote:
...
I would argue that it should output the same as the first example. That is,
PL/Perl should have decoded the latin-1 before passing the text to the Perl
function.
Yeah, I don't think you will find anyone who
My understanding of the problem is as follows. Acquiring a lock on a
tuple prevents the tuple from being concurrently updated. You might
take such a lock on a tuple T, make some other modification to the
database M, and commit, in the hope that your lock will prevent a
concurrent
Hi,
Thanks for your review and your time. Trying to answer some of your
points there:
Robert Haas robertmh...@gmail.com writes:
I spent a little time looking at this tonight. I'm going to give you
the same general advice that I've given other people who have
submitted very large patches of
Robert Haas robertmh...@gmail.com writes:
Looking at this a little more, I am inclined to think that
ExtensionSetCVC() is entirely unacceptable. Our backend startup is
high enough already. Sequential scanning the pg_extension catalog on
every startup to spare the DBA the trouble of setting
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug f...@phlo.org wrote:
Yes. Otherwise, B cannot verify that the database is consistent.
Note that it's sufficient to check if B can see the effects of the
*latest* locker of T. If it can see those, it must also see the
effects of any previous
On Sun, Dec 19, 2010 at 5:30 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I spent a little time looking at this tonight. I'm going to give you
the same general advice that I've given other people who have
submitted very large patches of this
Tomas Vondra t...@fuzzy.cz writes:
I've done several small changes to the patch, namely
- added docs for the functions (in SGML)
- added the same thing for background writer
So I think now it's 'complete' and I'll add it to the commit fest in a
few minutes.
Please split this into
On Sun, Dec 19, 2010 at 07:26, Craig Ringer cr...@postnewspapers.com.au wrote:
On 18/12/2010 1:13 AM, Magnus Hagander wrote:
On Fri, Dec 17, 2010 at 17:42, Magnus Hagandermag...@hagander.net
wrote:
On Fri, Dec 17, 2010 at 17:24, Craig Ringercr...@postnewspapers.com.au
wrote:
On
On Fri, 2010-12-17 at 13:35 -0500, Robert Haas wrote:
I'm
thinking it makes sense to commit this part first.
This will break Hot Standby, as previously explained. Don't.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
On Sun, Dec 19, 2010 at 12:51, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 19, 2010 at 07:26, Craig Ringer cr...@postnewspapers.com.au
wrote:
On 18/12/2010 1:13 AM, Magnus Hagander wrote:
On Fri, Dec 17, 2010 at 17:42, Magnus Hagandermag...@hagander.net
wrote:
On Fri, Dec 17,
On Sun, Dec 19, 2010 at 7:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-12-17 at 13:35 -0500, Robert Haas wrote:
I'm
thinking it makes sense to commit this part first.
This will break Hot Standby, as previously explained. Don't.
Uh, why? Skipping the commit record altogether
On 19/12/2010 7:51 PM, Magnus Hagander wrote:
Great. I pulled the latest from your git tree, tested that, and got much
better results. Crashdump size is back to what I expected. In my test code,
fcinfo-args and fcinfo-argnull can be examined without problems.
Backtraces look good; see below. It
On 19/12/2010 8:05 PM, Magnus Hagander wrote:
Actually, looking through it again just before commit, I can't help
but think the whole code about loading the DLL from different places
is unnecessary. The windows DLL search order *always* has the
directory of the EXE first, followed by either
On Sun, Dec 19, 2010 at 13:57, Craig Ringer cr...@postnewspapers.com.au wrote:
On 19/12/2010 7:51 PM, Magnus Hagander wrote:
Great. I pulled the latest from your git tree, tested that, and got much
better results. Crashdump size is back to what I expected. In my test
code,
fcinfo-args and
- Did we decide to ditch the encoding parameter for extension scripts
and mandate UTF-8?
No we didn't, we decided that the default encoding is UTF-8 and that any
contrib script defaults to UTF-8, so that it's not necessary to care
about the 'encoding' parameter in the control file there.
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug f...@phlo.org wrote:
Note that it's sufficient to check if B can see the effects of the
*latest* locker of T. If it can see those, it must also see the
effects of any previous locker. But because of this, B cannot
distinguish different lock
On Sat, Dec 18, 2010 at 11:59:33PM -0800, Jeff Janes wrote:
On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly flyusa2...@gmail.com wrote:
hi, folks!
I see that shared cache is implemented by system v shared memory. I wonder
whether data in this area can be swapped out to disk.
Isn't it bad
On Sun, Dec 19, 2010 at 5:41 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
... users IMO should not be concerned with custom_variable_classes at
all. The only users that know about it have already written an extension
in C.
I agree with the goal.
Now, I can see this mechanism evolving
On Sun, Dec 19, 2010 at 14:06, Craig Ringer cr...@postnewspapers.com.au wrote:
On 19/12/2010 8:05 PM, Magnus Hagander wrote:
Actually, looking through it again just before commit, I can't help
but think the whole code about loading the DLL from different places
is unnecessary. The windows DLL
On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug f...@phlo.org wrote:
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug f...@phlo.org wrote:
Note that it's sufficient to check if B can see the effects of the
*latest* locker of T. If it can see those, it must also see the
effects of any previous
Magnus Hagander mag...@hagander.net writes:
On Sun, Dec 19, 2010 at 07:26, Craig Ringer cr...@postnewspapers.com.au
wrote:
fcinfo-flinfo is still inaccessible, but I suspect it's in shared memory,
as it's at 0x0135 . Ditto fcinfo-resultinfo and fcinfo-context.
Hmm. Not sure why those
Craig Ringer cr...@postnewspapers.com.au writes:
On 17/12/2010 11:17 PM, Tom Lane wrote:
There is absolutely nothing more frustrating than having a crash dump
that hasn't got the information you need. Please turn it on by default.
There have to be limits to that, though. dbghelp.dll can dump
On Sun, Dec 19, 2010 at 23:45, Robert Haas robertmh...@gmail.com wrote:
I think I'd still argue for putting
it in a separate patch. I think that the value of extensions is first
and foremost that they can simplify installing, removing, dumping, and
restoring extensions. I'd rather see us
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Now, for people following but not reading the patch, what's in is that
in order for extensions using custom_variable_classes to work without
the user having to care about it, I've added an step at backend startup
time to seqscan pg_extension and
t...@fuzzy.cz writes:
I can prepare an alternative patch, using just per-database timestamps. So
even a reset for a single table/function would set the timestamp for the
whole database.
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the
On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that having the crash dump code know anything specific about the
contents of shared memory is a nonstarter --- far too fragile. But
perhaps we could have some simple rule based only on what the kernel
knows about the
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Oh, I wasn't aware that Itagaki-san had objected to Tom's proposal.
I agree that the default encoding is UTF-8, but it should be
configurable by the 'encoding' parameter in control files.
Why is it necessary to have such a parameter at all?
On Sun, Dec 19, 2010 at 17:28, Robert Haas robertmh...@gmail.com wrote:
On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that having the crash dump code know anything specific about the
contents of shared memory is a nonstarter --- far too fragile. But
perhaps we
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that having the crash dump code know anything specific about the
contents of shared memory is a nonstarter --- far too fragile. But
perhaps we could have some simple rule
Magnus Hagander mag...@hagander.net writes:
On Sun, Dec 19, 2010 at 17:28, Robert Haas robertmh...@gmail.com wrote:
On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
perhaps we could have some simple rule based only on what the kernel
knows about the shmem block, like dump
On 17.12.2010 18:44, Florian Pflug wrote:
On Dec17, 2010, at 16:49 , Heikki Linnakangas wrote:
On 15.12.2010 16:20, Florian Pflug wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflugf...@phlo.org wrote:
- serializable lock consistency - I am
Seems at least one mingw machine is missing the definitions for
minidumps. It does seem to have the header (dbghelp.h) that's
required, but with incomplete contents?
Can someone who has a working mingw environment look for the
definitions? See
On Sun, Dec 19, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with Robert that that is an utterly horrid, broken concept.
That's a little stronger than what I said, though the same general idea.
Just to point out one concrete problem: the postmaster reads
postgresql.conf too,
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
Does postgres make an effort to create a file with physically continuous
blocks?
AFAIK all files are expanded as needed. I don't think there's any flags you can
pass to the filesystem to tell it this file will eventually be 1GB in size.
So,
On Dec 18, 2010, at 8:51 PM, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I've done several small changes to the patch, namely
- added docs for the functions (in SGML)
- added the same thing for background writer
So I think now it's 'complete' and I'll add it to the commit fest in a
Tom Lane t...@sss.pgh.pa.us writes:
Just to point out one concrete problem: the postmaster reads
postgresql.conf too, so it would have to do this as well in order to
parse postgresql.conf correctly.
Well, if I parse you correctly, in my patch, it does. There's another
GUC array where to store
Itagaki Takahiro itagaki.takah...@gmail.com writes:
+1 to split the custom_variable_classes issue. It's a longstanding
TODO item, but EXTENSION is still very useful without the fix.
It's my guess that ExtensionSetCVC() can initialize modules one-by-one
and be called on demand, for example, at
Tom Lane t...@sss.pgh.pa.us writes:
Why is it necessary to have such a parameter at all? AFAICS it just
adds complexity for little if any gain. Most extension files will
probably be pure ASCII anyway. Dictionary files are *far* more likely
to contain non-ASCII characters. If we've gotten
On Dec19, 2010, at 17:01 , Robert Haas wrote:
On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug f...@phlo.org wrote:
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug f...@phlo.org wrote:
Note that it's sufficient to check if B can see the effects of the
*latest* locker of T. If it can see those, it
On Dec19, 2010, at 00:54 , Bruce Momjian wrote:
I wonder if we should write the port number as the 4th line in
postmaster.pid and return in a few major releases and use that. We
could fall back and use our existing code if there is no 4th line.
What if the postmaster instead created a second
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite work. I need is to know whether the
snapshot is 'consistent' i.e. whether I can
Dne 19.12.2010 19:13, Jim Nasby napsal(a):
Is there a reason this info needs to be tracked in the stats table?
I know it's the most obvious place, but since we're worried about the
size of it, what about tracking it in pg_class or somewhere else?
I guess this is the best place for this kind of
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite work. I need is to know whether the
On 12/19/2010 12:23 PM, Magnus Hagander wrote:
Seems at least one mingw machine is missing the definitions for
minidumps. It does seem to have the header (dbghelp.h) that's
required, but with incomplete contents?
Can someone who has a working mingw environment look for the
definitions? See
On Sun, 2010-12-19 at 07:33 -0500, Robert Haas wrote:
On Sun, Dec 19, 2010 at 7:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-12-17 at 13:35 -0500, Robert Haas wrote:
I'm
thinking it makes sense to commit this part first.
This will break Hot Standby, as previously
On Sun, Dec 19, 2010 at 20:58, Andrew Dunstan and...@dunslane.net wrote:
On 12/19/2010 12:23 PM, Magnus Hagander wrote:
Seems at least one mingw machine is missing the definitions for
minidumps. It does seem to have the header (dbghelp.h) that's
required, but with incomplete contents?
Can
On Sun, Dec 19, 2010 at 20:16, Florian Pflug f...@phlo.org wrote:
On Dec19, 2010, at 00:54 , Bruce Momjian wrote:
I wonder if we should write the port number as the 4th line in
postmaster.pid and return in a few major releases and use that. We
could fall back and use our existing code if
On Mon, 2010-12-13 at 10:38 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
The proposed solution is based on contingency tables, built for selected
groups of columns (not for each possible group). And the
Thom Brown-2 wrote:
On 15 November 2010 11:26, Greg Stark st...@mit.edu wrote:
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:
Dne 19.12.2010 21:21, Simon Riggs napsal(a):
On Mon, 2010-12-13 at 10:38 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
The proposed solution is based on contingency tables, built for selected
groups of
Dne 19.12.2010 20:28, Tom Lane napsal(a):
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite
Tomas Vondra t...@fuzzy.cz writes:
Plus I won't have time to write the other patch for at least a week, so
let's see whether there are serious objections agains the current patch.
If you think this objection is not serious, you're mistaken.
I've never had problems with the pgstat.dat file,
I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a 9% increase in the size of the stats file, and consequently
about a 9% increase in the cost of updating it.
Wups, sorry, I was
On Mon, Dec 20, 2010 at 01:34, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that the default encoding is UTF-8, but it should be
configurable by the 'encoding' parameter in control files.
Why is it necessary to have such a parameter at all?
UTF-8 is not a superset of all encodings.
--
Itagaki
On Dec19, 2010, at 21:10 , Magnus Hagander wrote:
On Sun, Dec 19, 2010 at 20:16, Florian Pflug f...@phlo.org wrote:
On Dec19, 2010, at 00:54 , Bruce Momjian wrote:
I wonder if we should write the port number as the 4th line in
postmaster.pid and return in a few major releases and use that. We
Dne 19.12.2010 23:58, Tom Lane napsal(a):
Tomas Vondra t...@fuzzy.cz writes:
Plus I won't have time to write the other patch for at least a week, so
let's see whether there are serious objections agains the current patch.
If you think this objection is not serious, you're mistaken.
I know
On Dec 19, 2010, at 12:20 AM, Alex Hunsaker wrote:
I would argue that it should output the same as the first example. That is,
PL/Perl should have decoded the latin-1 before passing the text to the Perl
function.
Yeah, I don't think you will find anyone who disagrees :) PL/TCL and
On Dec19, 2010, at 18:06 , Heikki Linnakangas wrote:
I think this patch is in pretty good shape now.
Apart from the serious deficiency Robert found :-(
I'll still comment on your suggestions though, since
they'd also apply to the solution I suggested on the
other thread.
The one thing I'm not
On Sat, Dec 18, 2010 at 1:24 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Fujii Masao's message of mié dic 15 00:54:39 -0300 2010:
Hi,
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently
Bruce Momjian wrote:
Andrew Dunstan wrote:
On 12/18/2010 06:23 PM, Bruce Momjian wrote:
If you really think that pulling a port number out of the pid file is an
improvement over what pg_ctl does now, then you need to start by storing
the port number, as such, in the pid file.
On Dec 19, 2010, at 2:20 AM, Alex Hunsaker wrote:
On Sat, Dec 18, 2010 at 20:29, David E. Wheeler da...@kineticode.com wrote:
...
I would argue that it should output the same as the first example. That is,
PL/Perl should have decoded the latin-1 before passing the text to the Perl
On Sun, Dec 19, 2010 at 1:35 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Just to point out one concrete problem: the postmaster reads
postgresql.conf too, so it would have to do this as well in order to
parse postgresql.conf correctly.
Well, if I
Bruce Momjian br...@momjian.us writes:
I wonder if we should write the port number as the 4th line in
postmaster.pid and return in a few major releases and use that. We
could fall back and use our existing code if there is no 4th line.
No. If it goes in, it should go in as the third line.
On Mon, Dec 20, 2010 at 03:39, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Just so that we're on the same line here, if we are to remove
custom_variable_classes then we don't keep any GUC related code into the
extension patch, right? So that ExtensionSetCVC() and friends disappear
On 19.12.2010 20:57, Florian Pflug wrote:
If we reuse the legacy field xvac to store xlast, we don't get into
trouble with binary upgrades either. We' need to find a way to deal
with tuples where HEAP_MOVED_IN or HEAP_MOVED_OUT is set, but that
seems manageable..
xvac shares the field with
On Sun, Dec 19, 2010 at 21:00, David Christensen da...@endpoint.com wrote:
On Dec 19, 2010, at 2:20 AM, Alex Hunsaker wrote:
With the attached we:
- for function arguments, convert (using pg_do_encoding_conversion) to
utf8 from the current database encoding.
How does this deal with input
67 matches
Mail list logo
