2011/5/10 Bruce Momjian :
> Christopher Browne wrote:
>> > Multiple resultsets in one call would be a good thing, though, no?
>> >
>> > cheers
>>
>> I *thought* the purpose of having stored procedures was to allow a
>> substrate supporting running multiple transactions, so it could do
>> things lik
Bruce Momjian writes:
> Late reply, but we are basically ignoring 'local' lines if the build
> doesn't support unix domain sockets (windows), but throwing an error for
> hostssl usage if ssl is not compiled in. Is the only logic here that
> 'local' is part of the default pg_hba.conf and hostssl i
"J. Greg Davidson" writes:
> * Tighten casting checks for domains based on arrays (Tom Lane)
> When a domain is based on an array type,..., such a domain type
> is no longer allowed to match an anyarray parameter of a
> polymorphic function, except by explic
Christopher Browne wrote:
> > Multiple resultsets in one call would be a good thing, though, no?
> >
> > cheers
>
> I *thought* the purpose of having stored procedures was to allow a
> substrate supporting running multiple transactions, so it could do
> things like:
> - Managing vacuums
> - Managi
On Sun, May 08, 2011 at 06:25:27PM -0400, Andrew Dunstan wrote:
> On 04/27/2011 11:41 PM, Noah Misch wrote:
>> On Wed, Apr 27, 2011 at 11:22:37PM -0400, Andrew Dunstan wrote:
>>> On 04/27/2011 05:30 PM, Noah Misch wrote:
To make things worse, the dump/reload problems seems to depend on your
>
On Mon, May 9, 2011 at 10:25 PM, Robert Haas wrote:
> So, what do we need in order to find our way to index-only scans?
>
> 1. The visibility map needs to be crash-safe. The basic idea of
> index-only scans is that, instead of checking the heap to find out
> whether each tuple is visible, we firs
On Fri, May 6, 2011 at 5:47 PM, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 8:52 AM, Heikki Linnakangas
> wrote:
>>> Another question:
>>> To address the problem in
>>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php
>>> , should we just clear the vm before the log of insert/up
So, what do we need in order to find our way to index-only scans?
1. The visibility map needs to be crash-safe. The basic idea of
index-only scans is that, instead of checking the heap to find out
whether each tuple is visible, we first check the visibility map. If
the visibility map bit is set,
On Mon, May 9, 2011 at 9:21 PM, Andrew Dunstan wrote:
>
>
> On 05/09/2011 08:20 PM, Bruce Momjian wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut writes:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
>
> (1) All the \d commands in psql should be implemented in
On 05/09/2011 09:43 PM, Greg Smith wrote:
When I last did a talk about getting started writing patches, I had a
few people ask me afterwards if I'd ever run into problems with having
patch submissions rejected. I said I hadn't.
Part of the trouble is in the question. Having a patch reject
On Mon, May 9, 2011 at 8:27 PM, Peter Geoghegan wrote:
> On 9 May 2011 11:19, Heikki Linnakangas
> wrote:
>
>> Can't we use the pipe trick on Windows? The API is different, but we use
>> pipes on Windows for other things already. When a process is launched, open
>> a pipe between postmaster and t
On Fri, May 6, 2011 at 2:47 PM, Robert Haas wrote:
> Comments?
At my day job there is saying: "Silence is consent".
I am surprised there has not been more discussion of this change,
considering the magnitude of the possibilities it unlocks.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql
On Mon, May 9, 2011 at 6:25 PM, J. Greg Davidson wrote:
>
> E.1.2.2. Casting
>
> * Tighten casting checks for domains based on arrays (Tom Lane)
>
> When a domain is based on an array type,..., such a domain type
> is no longer allowed to match an anyarray parameter of a
>
Josh Berkus wrote:
As I don't think we can change this, I think the best answer is to tell people
"Don't submit a big patch to PostgreSQL until you've done a few small
patches first. You'll regret it".
When I last did a talk about getting started writing patches, I had a
few people ask me
On 05/09/2011 08:20 PM, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut writes:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
equivalent to one \
Excerpts from Greg Stark's message of lun may 09 19:44:15 -0400 2011:
> Honestly it's not even that clear. It took me years to realize that
> when Tom says "There's problems x, y, z" he doesn't mean "give up now
> there are all these fatal flaws" but rather "think about these things
> and maybe th
Tom Lane wrote:
> Peter Eisentraut writes:
> > On m??n, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
> >> (1) All the \d commands in psql should be implemented in SPs so
> >> that they are available from any client, through calling one SP
> >> equivalent to one \d command.
>
> > You don't ne
Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > what would be the actual use cases of any of these features?
> > Let's collect some, so we can think of ways to make them work.
>
> The two things which leap to mind for me are:
>
> (1) All the \d commands in psql should be implemented
Tom Lane wrote:
> Peter Eisentraut writes:
> > On m??n, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
> >> In the particular case at hand, if someone is trying to use the same
> >> hostssl-containing pg_hba.conf across multiple systems, is it not
> >> reasonable to suppose that he should have SSL tur
On Mon, May 9, 2011 at 7:18 PM, Robert Haas wrote:
> Ah ha! Now we're getting somewhere. As was doubtless obvious from my
> previous responses, I don't agree that the process is as broken as I
> felt you were suggesting, and I think we've made a lot of
> improvements. However, I am in complete
On 05/09/2011 05:23 PM, J. Greg Davidson wrote:
It would be good if the Server Programming Interface were
sufficiently documented that most of the contributed
extensions which ship with PostgreSQL and most of the
SPI-based modules in the backend were using ONLY the
documented features of the SP
On 05/09/2011 02:31 PM, Robert Haas wrote:
I don't think we should be too obstinate about trying to twist the arm
of packagers who (as Tom points out) will do whatever they want in
spite of us, but the current state of contrib, with all sorts of
things of varying type, complexity, and value mixed
On 05/09/2011 03:31 PM, Alvaro Herrera wrote:
For executables we already have src/bin. Do we really need a separate
place for, say, pg_standby or pg_upgrade?
There's really no executables in contrib that I find myself regularly
desperate for/angry at because they're not installed as an int
The documentation for the Server Programming Interface
is underspecified such that it is impossible to create
real extensions using only the documented interface.
For example, in the example 43.5
http://www.postgresql.org/docs/9.1/static/spi-examples.html
a variable of type SPITupleTable is being
E.1.2.2. Casting
* Tighten casting checks for domains based on arrays (Tom Lane)
When a domain is based on an array type,..., such a domain type
is no longer allowed to match an anyarray parameter of a
polymorphic function, except by explicitly down
Excerpts from Josh Berkus's message of lun may 09 16:43:10 -0400 2011:
> Now, that's a good point. And I don't expect that pg_dump can
> distinguish between a serial and an sequence with a dependency?
They're the same thing, so no.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, In
Tom Lane writes:
> Sure, but that's a documentation issue, which again is not going to be
> helped by a source-tree rearrangement.
So we have several problem to solve here, and I agree that source code
rearrangement is fixing none of them. Maybe it would ease maintaining
down the road, though, b
> As a counterexample, consider the case where multiple tables share the
> same sequence. Suppressing one of the tables with -T ought not lead to
> suppressing the sequence.
Now, that's a good point. And I don't expect that pg_dump can
distinguish between a serial and an sequence with a depende
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of lun may 09 14:31:33 -0400 2011:
>> I'm happy enough with that set of guidelines: namely, that we'd use
>> src/extension only for things that don't require additional
>> dependencies, and not for things that build standalone executable
Josh Berkus writes:
> It seems that if I exclude a table using -T, its dependant sequences do
> not get excluded. But if I include it using -t, its dependent sequences
> *do* get included.
> Is there a reason this is a good idea, or is it just an oversight?
It's not immediately clear to me that
On Mon, May 9, 2011 at 2:58 PM, Bruce Momjian wrote:
> Tom this collation stuff has seen more post-feature-commit cleanups than
> I think any patch I remember. Is there anything we can learn from this?
How about "don't commit all the large patches at the end of the cycle"?
--
Robert Haas
Enter
On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Peter,
>>
>> > I would like to collect some specs on this feature. So does anyone have
>> > links to documentation of existing implementations, or their own spec
>> > writeup? A lot of people appear to have a very clear
Bruce Momjian writes:
> Tom this collation stuff has seen more post-feature-commit cleanups than
> I think any patch I remember. Is there anything we can learn from this?
The pre-commit review was obviously woefully inadequate.
regards, tom lane
--
Sent via pgsql-hacke
Excerpts from Robert Haas's message of lun may 09 14:31:33 -0400 2011:
> I'm happy enough with that set of guidelines: namely, that we'd use
> src/extension only for things that don't require additional
> dependencies, and not for things that build standalone executables.
> If we're going to move
Attached is an updated version of the 'hint bit cache'.
What's changed:
*) 'bucket' was changed to 'page' everywhere
*) rollup array is now gets added during 'set', not the 'get' (pretty
dumb the way it was before -- wasn't really dealing with non-commit
bits yet)
*) more source comments, includin
On 05/09/2011 11:43 AM, Robert Haas wrote:
Interesting. You could argue that once 8.3 is our earliest supported
release that we could even shrink the support window because the
argument "I can't dump/reload my data" would be gone.
Personally, I think the support window is on the borderline of
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
> >> Interesting. ?You could argue that once 8.3 is our earliest supported
> >> release that we could even shrink the support window because the
> >> argument "I can't dump/reload my data" would be gon
All,
Just encountered this:
create table josh ( id serial not null, desc text );
pg_dump -Fc -T josh -f no_josh_dump postgres
pg_dump -Fc -t josh -f josh_dump postgres
pg_restore -d new no_josh_dump
pg_restore -d new josh_dump
pg_restore: [archiver (db)] Error from TOC entry 2645; 1259 49910
On Mon, May 9, 2011 at 12:51 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie may 06 23:25:09 -0300 2011:
>> On Fri, Apr 22, 2011 at 4:13 AM, Leonardo Francalanci
>> wrote:
>> >> Maybe you should change xl_act_commit to have a separate list of rels to
>> >> drop the init f
Robert Haas writes:
> On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
>> Interesting. You could argue that once 8.3 is our earliest supported
>> release that we could even shrink the support window because the
>> argument "I can't dump/reload my data" would be gone.
> Personally, I think
Tom this collation stuff has seen more post-feature-commit cleanups than
I think any patch I remember. Is there anything we can learn from this?
Yes, this is coming from me, who some consider to be the king of
post-commit cleanups, namely, cleaning up my own commits.
---
On Mon, May 9, 2011 at 2:41 PM, Josh Berkus wrote:
> Robert,
>
>> I can't disagree with this, either. I'm not sure where it would be
>> possible for us to document this that people would actually see and
>> read, and I think it's a tough to understand just from reading a wiki
>> page or a blog po
Greg Smith wrote:
> [There were complaints upthread about things like how Aster's patch
> submissions were treated. Those were WIP patches that half implemented
> some useful ideas. But they were presented as completed features, and
> they seemed to expect the community would pick those up and
Robert Haas wrote:
> > Interesting. ?You could argue that once 8.3 is our earliest supported
> > release that we could even shrink the support window because the
> > argument "I can't dump/reload my data" would be gone.
>
> Personally, I think the support window is on the borderline of being
> too
On Mon, May 9, 2011 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 8, 2011 at 1:04 AM, Tom Lane wrote:
>>> Yes, definitely. Perhaps summarize as "rethink how we handle partially
>>> correct postgresql.conf files". Or maybe Robert sees it as "rethink
>>> approach to making su
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
> Greg Smith wrote:
>> On 04/21/2011 12:39 PM, Robert Haas wrote:
>> > In fact, I've been wondering if we shouldn't consider extending the
>> > support window for 8.2 past the currently-planned December 2011.
>> > There seem to be quite a lot o
Josh Berkus wrote:
> Peter,
>
> > I would like to collect some specs on this feature. So does anyone have
> > links to documentation of existing implementations, or their own spec
> > writeup? A lot of people appear to have a very clear idea of this
> > concept in their own head, so let's start
Robert,
> I can't disagree with this, either. I'm not sure where it would be
> possible for us to document this that people would actually see and
> read, and I think it's a tough to understand just from reading a wiki
> page or a blog post:
Still, if we had a wiki page which was a really compre
On Mon, May 9, 2011 at 1:14 PM, Greg Smith wrote:
> On 05/09/2011 10:53 AM, Robert Haas wrote:
>>
>> I would really like to see us try to group things by topic, and not
>> just by whether or not we can all agree that the extension is
>> important enough to be first-class (which is bound to be a bi
On Mon, May 9, 2011 at 1:53 PM, Josh Berkus wrote:
> While the first was specific to the Aster submissions, I've seen the
> second problem with lots of first-time submissions to this list. Our
> feedback to submitters of big patches requires a lot of comprehension of
> project personalities and p
FYI, does wal.c need updated comments to explain the file system
semantics we expect, and how our code triggers it?
---
Greg Smith wrote:
> On 04/23/2011 09:58 AM, Matthew Woodcraft wrote:
> > As far as I can make out, the c
Greg,
>> [There were complaints upthread about things like how Aster's patch
>> submissions were treated. Those were WIP patches that half implemented
>> some useful ideas.
There are two reasons why I think we failed with the Aster patches:
1) I passed Aster along to Bruce, who said he would
Tom Lane wrote:
> I am thinking about a new target "installcheck-collations" in
> src/test/regress/GNUmakefile that creates a UTF8-encoding database
> and runs a different test schedule than the regular tests.
I don't know the best way to do this (or how many people agree we
should), but I fou
On 05/09/2011 12:06 PM, Andrew Dunstan wrote:
The fact that we can do in place upgrades of the data only addresses
one pain point in upgrading. Large legacy apps require large retesting
efforts when upgrading, often followed by lots more work renovating
the code for backwards incompatibilities.
All,
> I agree that we should not reduce the support window. The fact that we
> can do in place upgrades of the data only addresses one pain point in
> upgrading. Large legacy apps require large retesting efforts when
> upgrading, often followed by lots more work renovating the code for
> backward
Excerpts from Robert Haas's message of vie may 06 23:25:09 -0300 2011:
> On Fri, Apr 22, 2011 at 4:13 AM, Leonardo Francalanci
> wrote:
> >> Maybe you should change xl_act_commit to have a separate list of rels to
> >> drop the init fork for (instead of mixing those with the list of files to
>
Robert Haas writes:
> On Mon, May 9, 2011 at 10:39 AM, Tom Lane wrote:
>> No objection here, but how will we do that? The regression tests are
>> designed to work in any locale/encoding, and would become significantly
>> less useful if they weren't.
> I'm just shooting from the hip here, but ma
Greg Smith wrote:
> On 04/21/2011 12:39 PM, Robert Haas wrote:
> > In fact, I've been wondering if we shouldn't consider extending the
> > support window for 8.2 past the currently-planned December 2011.
> > There seem to be quite a lot of people running that release precisely
> > because the casti
Robert Haas writes:
> On Sun, May 8, 2011 at 1:04 AM, Tom Lane wrote:
>> Yes, definitely. Perhaps summarize as "rethink how we handle partially
>> correct postgresql.conf files". Or maybe Robert sees it as "rethink
>> approach to making sure all backends share the same value of critical
>> sett
On Mon, May 9, 2011 at 10:58 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > ... Maybe someone out there is under the impression
>> > that I get high off of rejecting patches; but the statistics you cite
>> > from the CF app don't exactly support the contention that I'm goi
Tom Lane wrote:
> Robert Haas writes:
> > ... Maybe someone out there is under the impression
> > that I get high off of rejecting patches; but the statistics you cite
> > from the CF app don't exactly support the contention that I'm going
> > around looking for reasons to reject things, or if I a
On Mon, May 9, 2011 at 10:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, since any problems in this are are going to bite us eventually
>> in 9.0+ even without any further action on our part, maybe it would be
>> wise to think up something we could add to the regression tests. That
>> wou
On Sun, May 8, 2011 at 12:02 AM, Greg Smith wrote:
> Attached patch is a first cut at what moving one contrib module (in this
> case pg_buffercache) to a new directory structure might look like. The idea
> is that src/extension could become a place for "first-class" extensions to
> live. Those a
Robert Haas writes:
> Well, since any problems in this are are going to bite us eventually
> in 9.0+ even without any further action on our part, maybe it would be
> wise to think up something we could add to the regression tests. That
> would give us some immediate feedback from the buildfarm, a
On Sun, May 8, 2011 at 1:04 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane wrote:
So I'm thinking we should adopt a strategy that's less likely to result
in divergent behavior among different backends. ?The idea I have in
On Sat, May 7, 2011 at 12:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On the flip side, the risk of it flat-out blowing up seems pretty
>> small. For someone to invent their own version of wchar_t that uses
>> something other than Unicode code points would be pretty much pure
>> masochism, w
Andrew Dunstan writes:
> What's a bit annoying is that these tests were checked in without a
> vestige of MSVC support, and nobody pinged the usual suspects (i.e.
> Magnus and me) to ask for help in providing it,
Speaking of pinging Windows people, have either of you noticed the
reports that CR
Simon Riggs writes:
> I agree with Tom about the need for a fix that prevents generation of
> repeated WAL records.
> OTOH, I also like Joe's fix in the recovery code to avoid responding
> to repeated records.
> Can we have both please?
Why? The patch in the recovery code is seriously ugly, an
On Sat, May 7, 2011 at 2:01 PM, Peter Eisentraut wrote:
> On fre, 2011-05-06 at 21:53 +0200, Cédric Villemain wrote:
> >
> > I think it might be better if the association don't need (or have )
> > activity other than 'technical' and to set up another nonprofit
> > association for real activity.
>
On 05/08/2011 09:54 PM, Andrew Dunstan wrote:
On 05/08/2011 07:35 PM, Tom Lane wrote:
I believe that the "make check" target in src/test/isolation is
fundamentally unportable, as is illustrated by the fact that buildfarm
member coypu is currently choking on it. The reason is that the
pg_iso
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian wrote:
> Is this a TODO?
I think so.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On 9 May 2011 11:19, Heikki Linnakangas
wrote:
> Can't we use the pipe trick on Windows? The API is different, but we use
> pipes on Windows for other things already. When a process is launched, open
> a pipe between postmaster and the child process. In the child, spawn a
> thread that just calls
Il 09/05/11 09:14, Simon Riggs ha scritto:
Anyway, I hope I can give you more detailed information tomorrow. Thanks.
Did you find anything else of note, or is your patch ready to commit?
Unfortunately I did not have much time to run further tests.
The ones I have done so far show that it most
On 09.05.2011 12:20, Peter Geoghegan wrote:
I've taken a look into it, and I'm not optimistic about the likelihood
of the way I've suggested that we can register a callback on process
termination on windows being acceptable. It seems to be a kludge too
far. It does work on Vista, just not very we
All right, what would we be the best way to debug such a problem?
Yves
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Greg Stark
Sent: Sunday, May 08, 2011 6:36 PM
To: weis...@rbg.informatik.tu-darmstadt.de
Cc: pgsql-ha
I've taken a look into it, and I'm not optimistic about the likelihood
of the way I've suggested that we can register a callback on process
termination on windows being acceptable. It seems to be a kludge too
far. It does work on Vista, just not very well. There is a
considerable delay on closing t
On Fri, May 6, 2011 at 4:22 AM, Tom Lane wrote:
>> The attached fix-clogredo diff is my proposal for a fix for this.
>
> That seems pretty grotty :-(
>
> I think a more elegant fix might be to just swap the order of the
> ExtendCLOG and ExtendSUBTRANS calls in GetNewTransactionId. The
> reason t
On Mon, May 2, 2011 at 6:15 PM, Gabriele Bartolini
wrote:
> You can easily spot in the graphs the point where VACUUM FULL terminates,
> then it is just a matter of flushing the WAL delay for replication.
Agreed.
> Anyway, I hope I can give you more detailed information tomorrow. Thanks.
Did yo
78 matches
Mail list logo
