Craig Ringer ring...@ringerc.id.au writes:
On 07/18/2012 08:31 AM, Tom Lane wrote:
Not sure if we need a whole farm, but certainly having at least one
machine testing this sort of stuff on a regular basis would make me feel
a lot better.
OK. That's something I can actually be useful for.
On Tue, Jul 17, 2012 at 9:16 PM, Bruce Momjian br...@momjian.us wrote:
WAL is not guaranteed to be the same between PG major versions, so doing
anything with WAL is pretty much a no-go.
I understand that the WAL format changes, sometimes dramatically
between versions. What I'm suggesting that
On 18.07.2012 02:48, Peter Geoghegan wrote:
On 17 July 2012 23:56, Tom Lanet...@sss.pgh.pa.us wrote:
This implies that nobody has done pull-the-plug testing on either HEAD
or 9.2 since the checkpointer split went in (2011-11-01), because even
a modicum of such testing would surely have shown
I converted Skytools modules to extensions and found 2 problems:
1) Dumpable sequences are not supported - if sequence is tagged
with pg_catalog.pg_extension_config_dump(), the pg_dump tries
to run COPY on it.
2) If there is schema with functions, but nothing else,
then when later
On Tue, Jul 17, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So I went to fix this in the obvious way (attached), but while testing
it I found that the number of buffers_backend events reported during
a regression test run barely changed; which surprised the heck out of
me, so I dug
On Tue, Jul 17, 2012 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 16, 2012 at 9:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I wonder whether the code that checks for relfilenode conflict
when selecting a pg_class or relfilenode OID
On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote:
However, I have two ideas. First, I don't know _why_ the
primary/standby would be any different after pg_upgrade, so I added the
documentation mention because I couldn't _guarantee_ they were the same.
Actually, if people
On Thu, Jul 12, 2012 at 8:50 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
[ new patch ]
Well, I think it's about time to start getting some of this code into
our tree. However, I'm still not confident that the code that
actually runs the triggers is entirely solid, so I decided to rip
On 14.07.2012 17:50, Jan Urbański wrote:
On 13/07/12 13:38, Jan Urbański wrote:
On 12/07/12 11:08, Heikki Linnakangas wrote:
On 07.07.2012 00:12, Jan Urbański wrote:
So you're in favour of doing unicode - bytes by encoding with UTF-8
and
then using the server's encoding functions?
Sounds
Hello
* renamed erritem to err_generic_string
* fixed CSVlog generation
* new file /utils/error/relerror.c with axillary functions -
declarations are in utils/rel.h
Regards
Pavel
2012/7/11 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
FWIW about the new
I'm chasing up an issue from a client who has this problem (in 9.1):
with q as
(
some query here
)
select q.* from q
yields:
job_scope | checked_col
---+--
Co Revenues:
On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm chasing up an issue from a client who has this problem (in 9.1):
with q as
(
some query here
)
select q.* from q
yields:
job_scope | checked_col
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm chasing up an issue from a client who has this problem (in 9.1):
with q as
(
some query here
)
select q.* from q
yields:
job_scope
Andrew Dunstan and...@dunslane.net writes:
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
there are no null fields, right? if the last field is sometimes null
you'd see that (you probably ruled that out though). when you say
'sometimes', do you mean for some rows and not others? or for some
After fixing the assorted breakage discussed yesterday, I still wasn't
seeing any ForwardFsyncRequest requests coming from the bgwriter during
a regression test run, which made me wonder if there was yet another
bug. What I find is that because of the recent increase in the
out-of-the-box
On 13.07.2012 02:00, Alexander Korotkov wrote:
On Thu, Jul 12, 2012 at 10:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Thanks. Can you do something about TrickFunctionCall2, please? (
http://archives.postgresql.**org/message-id/4FE2C968.**
On 07/18/2012 03:30 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
there are no null fields, right? if the last field is sometimes null
you'd see that (you probably ruled that out though). when you say
'sometimes', do you mean for
On Thu, Jul 19, 2012 at 12:22 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.07.2012 02:00, Alexander Korotkov wrote:
On Thu, Jul 12, 2012 at 10:29 AM, Heikki Linnakangas
heikki.linnakangas@**enterprisedb.comheikki.linnakan...@enterprisedb.com
wrote:
Thanks. Can
On Wed, Jul 18, 2012 at 3:42 PM, Andrew Dunstan and...@dunslane.net wrote:
On 07/18/2012 03:30 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
there are no null fields, right? if the last field is sometimes null
you'd see that
On Wed, Jul 18, 2012 at 3:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
hm, it's the 'group by' -- for example if you add group by
pg_namespace.oid, group by pg_namespace.oid || 'abc', you can invent
columns that come back into the rowtype.
here's a cut down example:
with q as (select max(v)
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 16, 2012 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that argument is exactly why the code is designed the way it is...
but we are now finding out that sending useless fsync requests isn't as
cheap as all that.
I agree, but I
On 07/18/2012 03:59 PM, Tom Lane wrote:
2. It's rather disturbing that a fairly large swath of functionality
just stopped getting tested at all by the buildfarm. Do we want to
rethink the shared_buffers increase? Or artificially bloat the
regression database to make it larger than 128MB? Or
Merlin Moncure mmonc...@gmail.com writes:
hm, it's the 'group by' -- for example if you add group by
pg_namespace.oid, group by pg_namespace.oid || 'abc', you can invent
columns that come back into the rowtype.
Yeah, the whole-row variable is evidently picking up resjunk columns
from the inner
Andrew Dunstan and...@dunslane.net writes:
The buildfarm does have the ability to set config data after initdb has
run (which I just enhanced in the latest release). So a buildfarm owner
could add a config line for shared_buffers which would override what
initdb had set.
Or we could
On 17 July 2012 23:56, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 16, 2012 at 3:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, while we are on the subject: hasn't this split completely broken
the statistics about backend-initiated writes?
Yes, it
Am 17.07.12 19:38, schrieb Tom Lane:
btree knows nothing about the datatypes it's working on except that
they have comparison functions. Converting the values to some sort of
numeric scale that you can interpolate on seems logically dubious and
fraught with practical difficulties. Now, we do
Sorry to raise this once again, but I still find this CHECK NO INHERIT
syntax to a bit funny. We are currently using something like
CHECK NO INHERIT (foo 0)
But we already have a different syntax for attaching attributes to
constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more
On 07/18/2012 05:37 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The buildfarm does have the ability to set config data after initdb has
run (which I just enhanced in the latest release). So a buildfarm owner
could add a config line for shared_buffers which would override
Samuel Vogel s...@muel-vogel.de writes:
Am 17.07.12 19:38, schrieb Tom Lane:
The datum values will be pointers to strings.
I can simply dereference it and read all bytes until a null-byte appears
(depending on the collation and that I know that it actually is a string)?
We use a length word
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org]
On Behalf Of Tom Lane
So that raises two independent sets of questions:
1. Do we like the fact that the bgwriter isn't doing anything in this
situation? It seems arguably OK for writes to happen only for
30 matches
Mail list logo
