Re: [HACKERS] Using pg_upgrade on log-shipping standby servers

On Wed, Jul 18, 2012 at 09:36:51AM -0400, Robert Haas wrote: > On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian 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'

Re: [HACKERS] bgwriter, regression tests, and default shared_buffers settings

> 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

Re: [HACKERS] b-tree index search algorithms

Samuel Vogel 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 and then data

Re: [HACKERS] bgwriter, regression tests, and default shared_buffers settings

On 07/18/2012 05:37 PM, Tom Lane wrote: Andrew Dunstan 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

[HACKERS] CHECK NO INHERIT syntax

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

Re: [HACKERS] b-tree index search algorithms

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 ha

Re: [HACKERS] Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)

On 17 July 2012 23:56, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jul 16, 2012 at 3:18 PM, Tom Lane wrote: >>> BTW, while we are on the subject: hasn't this split completely broken >>> the statistics about backend-initiated writes? > >> Yes, it seems to have done just that. > > So I went t

Re: [HACKERS] bgwriter, regression tests, and default shared_buffers settings

Andrew Dunstan 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 provide an initdb fl

Re: [HACKERS] row literal problem

Merlin Moncure 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 query. Haven

Re: [HACKERS] bgwriter, regression tests, and default shared_buffers settings

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 d

Re: [HACKERS] [PERFORM] DELETE vs TRUNCATE explanation

Robert Haas writes: > On Mon, Jul 16, 2012 at 12:36 PM, Tom Lane 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 think the problem can be solved fo

Re: [HACKERS] row literal problem

On Wed, Jul 18, 2012 at 3:56 PM, Merlin Moncure 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) from (select 1

Re: [HACKERS] row literal problem

On Wed, Jul 18, 2012 at 3:42 PM, Andrew Dunstan wrote: > > On 07/18/2012 03:30 PM, Tom Lane wrote: >> >> Andrew Dunstan 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 ru

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

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.com> >> wrote: >> >> Thanks. Can you do something ab

Re: [HACKERS] row literal problem

On 07/18/2012 03:30 PM, Tom Lane wrote: Andrew Dunstan 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 o

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

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.** 2010...@enterprisedb.com

[HACKERS] bgwriter, regression tests, and default shared_buffers settings

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 shared_b

Re: [HACKERS] row literal problem

Andrew Dunstan 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 >> queries? >

Re: [HACKERS] row literal problem

On 07/18/2012 03:18 PM, Merlin Moncure wrote: On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan 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_co

Re: [HACKERS] row literal problem

On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan 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 > -

[HACKERS] row literal problem

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:

Re: [HACKERS] enhanced error fields

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 : > Alvaro Herrera writes: >> FWIW about the new include: I feel a strong dislike about the for

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.

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 re

Re: [HACKERS] Event Triggers reduced, v1

On Thu, Jul 12, 2012 at 8:50 AM, Dimitri Fontaine 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 that stuff out and commit

Re: [HACKERS] Using pg_upgrade on log-shipping standby servers

On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian 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 can test this

Re: [HACKERS] CompactCheckpointerRequestQueue versus pad bytes

On Tue, Jul 17, 2012 at 1:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jul 16, 2012 at 9:58 PM, Tom Lane wrote: >>> BTW, I wonder whether the code that checks for relfilenode conflict >>> when selecting a pg_class or relfilenode OID tries both file naming >>> conventions? If not, sho

[HACKERS] Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)

On Tue, Jul 17, 2012 at 6:56 PM, Tom Lane 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 deeper. The cause

[HACKERS] [9.1] 2 bugs with extensions

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 conver

Re: [HACKERS] Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)

On 18.07.2012 02:48, Peter Geoghegan wrote: On 17 July 2012 23:56, Tom Lane 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 that we're failing t