On Sun, Dec 19, 2010 at 21:00, David Christensen 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 records
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 comm
On Mon, Dec 20, 2010 at 03:39, Dimitri Fontaine 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
> entirely.
I think so. It w
Bruce Momjian 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. The shmem ke
On Sun, Dec 19, 2010 at 1:35 PM, Dimitri Fontaine
wrote:
> Tom Lane 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,
On Dec 19, 2010, at 2:20 AM, Alex Hunsaker wrote:
> On Sat, Dec 18, 2010 at 20:29, David E. Wheeler 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
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 su
On Sat, Dec 18, 2010 at 1:24 AM, Alvaro Herrera
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 SignalSomeChild
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 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
Dne 19.12.2010 23:58, Tom Lane napsal(a):
> Tomas Vondra 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 there w
On Dec19, 2010, at 21:10 , Magnus Hagander wrote:
> On Sun, Dec 19, 2010 at 20:16, Florian Pflug 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
>>>
On Mon, Dec 20, 2010 at 01:34, Tom Lane 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 Takahiro
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 l
Tomas Vondra 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, but I underst
Dne 19.12.2010 20:28, Tom Lane napsal(a):
> Tomas Vondra 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 wo
Dne 19.12.2010 21:21, Simon Riggs napsal(a):
> On Mon, 2010-12-13 at 10:38 -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra wrote:
The proposed solution is based on contingency tables, built for selected
groups of columns (not for each poss
Thom Brown-2 wrote:
>
> On 15 November 2010 11:26, Greg Stark 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:
>>
>>
>> http://aws.typepad.co
On Mon, 2010-12-13 at 10:38 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra wrote:
> >> The proposed solution is based on contingency tables, built for selected
> >> groups of columns (not for each possible group). And the contingency
> >> table give
On Sun, Dec 19, 2010 at 20:16, Florian Pflug 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 there is no
On Sun, Dec 19, 2010 at 20:58, Andrew Dunstan 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 some
On Sun, 2010-12-19 at 07:33 -0500, Robert Haas wrote:
> On Sun, Dec 19, 2010 at 7:01 AM, Simon Riggs 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. D
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
htt
Tomas Vondra 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
> snapshot is 'c
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
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
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 secon
On Dec19, 2010, at 17:01 , Robert Haas wrote:
> On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug wrote:
>>> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug 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
Tom Lane 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 along fine with
Itagaki Takahiro 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 SHOW, searching pg_se
Tom Lane 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 invalid placehol
On Dec 18, 2010, at 8:51 PM, Tom Lane wrote:
> Tomas Vondra 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
>>
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".
On Sun, Dec 19, 2010 at 11:21 AM, Tom Lane 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, so it would have
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
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm
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 Pflug wrote:
- serializable lock consistency - I am fairly certain
Magnus Hagander writes:
> On Sun, Dec 19, 2010 at 17:28, Robert Haas wrote:
>> On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane wrote:
>>> perhaps we could have some simple rule based only on what the kernel
>>> knows about the shmem block, like "dump shmem if it's no more than 1GB".
>> Not sure what
Robert Haas writes:
> On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane 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
>> kno
On Sun, Dec 19, 2010 at 17:28, Robert Haas wrote:
> On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane 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
Itagaki Takahiro 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? AFAICS it just
adds
On Sun, Dec 19, 2010 at 11:07 AM, Tom Lane 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 shmem block, l
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 t
Dimitri Fontaine 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 update custom_varia
On Sun, Dec 19, 2010 at 23:45, Robert Haas 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 nail that, and then w
Craig Ringer 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 shared
> memory, too
Magnus Hagander writes:
> On Sun, Dec 19, 2010 at 07:26, Craig Ringer
> 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 would be in shared memory, that seems s
On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug wrote:
>> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug 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
On Sun, Dec 19, 2010 at 14:06, Craig Ringer 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 search order *alway
On Sun, Dec 19, 2010 at 5:41 AM, Dimitri Fontaine
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 in several direction
On Sat, Dec 18, 2010 at 11:59:33PM -0800, Jeff Janes wrote:
> On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly 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 rea
> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug 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 strengths
>>> - 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 fi
On Sun, Dec 19, 2010 at 13:57, Craig Ringer 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 fcinfo->argnull
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 syst
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. I
On Sun, Dec 19, 2010 at 7:01 AM, Simon Riggs 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 would do that
On Sun, Dec 19, 2010 at 12:51, Magnus Hagander wrote:
> On Sun, Dec 19, 2010 at 07:26, Craig Ringer
> wrote:
>> On 18/12/2010 1:13 AM, Magnus Hagander wrote:
>>>
>>> On Fri, Dec 17, 2010 at 17:42, Magnus Hagander
>>> wrote:
On Fri, Dec 17, 2010 at 17:24, Craig Ringer
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.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
On Sun, Dec 19, 2010 at 07:26, Craig Ringer wrote:
> On 18/12/2010 1:13 AM, Magnus Hagander wrote:
>>
>> On Fri, Dec 17, 2010 at 17:42, Magnus Hagander
>> wrote:
>>>
>>> On Fri, Dec 17, 2010 at 17:24, Craig Ringer
>>> wrote:
On 17/12/2010 7:17 PM, Magnus Hagander wrote:
>>>
>>> Now, th
> Tomas Vondra 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 separa
On Sun, Dec 19, 2010 at 5:30 AM, Dimitri Fontaine
wrote:
> Robert Haas 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 type: it'll be a lot easier to
>> get th
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug 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 locker. But be
Robert Haas 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 up
> postgresql.con
Hi,
Thanks for your review and your time. Trying to answer some of your
points there:
Robert Haas 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 type: it'll be
> 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 transa
On Sat, Dec 18, 2010 at 20:29, David E. Wheeler 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
On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly 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
> finally data in shar
67 matches
Mail list logo
