Re: [HACKERS] obj_unique_identifier(oid)

2011/1/7 Jim Nasby : > BTW, if you're looking at making pg_depnd easier to use, see > http://archives.postgresql.org/message-id/129774-sup-2...@alvh.no-ip.org I guess there are more than one ways to do it, C, sql, plperl, plpgsql. :) I guess at least one of the methods should be provided in t

Re: [HACKERS] We need to log aborted autovacuums

On Fri, Jan 07, 2011 at 08:15:12PM -0500, Greg Smith wrote: > [1] Silly aside: I was thinking today that I should draw a chart of > all the common objections to code that show up here, looking like > those maps you see when walking into a mall. Then we can give a > copy to new submitters with a b

Re: [HACKERS] Re: [COMMITTERS] pgsql: New system view pg_stat_replication displays activity of wal sen

On Sat, Jan 8, 2011 at 01:09, Robert Haas wrote: >> Oops, sorry. Additional documentation patch attached. >> Could you proofread the text? > > Done, edited, committed, along with the catversion bump (as noted by Tom). Thanks a lot! -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Remove pg_am.amindexnulls?

Robert Haas writes: > On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane wrote: >> Between >> amclusterable, amsearchnulls, and amoptionalkey, I believe that we have >> quite enough flags already to cover what anything else actually >> needs-to-know about the AM's behavior. > I've pretty much come to the

[HACKERS] pg_upgrade map struct cleanup

The attached, applied patch for pg_upgrade tracks only one copy of namespace/relname in FileNameMap because the old and new values are identical. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to

Re: [HACKERS] Remove pg_am.amindexnulls?

On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane wrote: > David Fetter writes: >> On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: >>> Anyone against simplifying matters by getting rid of >>> pg_am.amindexnulls? > >> I guess the only potential use for it would be for some kind of am >> that *cou

Re: [HACKERS] Fix for pg_upgrade migrating pg_largeobject_metadata

Patch applied. I did not backpatch to 9.0 because you can't migrate from 9.0 to 9.0 with the same catversion (because of tablespace conflict), and a pre-9.0 migration to 9.0 has not large object permissions to migrate. In summary, it didn't seem worth the risk, and was hard to test. ---

Re: [HACKERS] crash-safe visibility map, take three

On Fri, Jan 7, 2011 at 1:28 PM, Jim Nasby wrote: > On Jan 5, 2011, at 8:10 PM, Robert Haas wrote: >> On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh wrote: >>> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit >>> serve? >> >> If we modify a page on which PD_ALL_VISIBLE isn

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote: > I forgot about sequences earlier. If we dump while someone deletes all > rows and resets the sequence the dump might contain rows and still > reset the sequence. This could cause duplicate key errors on restore. > I haven't checked if this is

[HACKERS] More pg_upgrade clarifications

The attached two patches clarify pg_upgrades behavior. Specifically, the first patch updates the C comments regarding pg_upgrade_support. The second patch clarifies that pg_class.oid really needs preserving, not pg_class.relfilenode. We used to use create relfilenode files to preserve pg_class.o

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

"David E. Wheeler" writes: > On Jan 7, 2011, at 4:19 PM, Tom Lane wrote: >> Well, actually, I just committed it. If you want to test, feel free. >> Note that right now only the anyarray && <@ @> operators are genuinely >> fixed ... I plan to hack on tsearch and contrib pretty soon though. > Hrm,

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

On Jan 7, 2011, at 4:19 PM, Tom Lane wrote: > Well, actually, I just committed it. If you want to test, feel free. > Note that right now only the anyarray && <@ @> operators are genuinely > fixed ... I plan to hack on tsearch and contrib pretty soon though. Hrm, the queries I wrote for this sort

Re: [HACKERS] Remove pg_am.amindexnulls?

David Fetter writes: > On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: >> Anyone against simplifying matters by getting rid of >> pg_am.amindexnulls? > I guess the only potential use for it would be for some kind of am > that *couldn't* index nulls out of the gate. Might their be such

Re: [HACKERS] We need to log aborted autovacuums

Josh Berkus wrote: It occurs to me that another way of diagnosis would simply be a way to cause the autovac daemon to spit out output we could camp on, *without* requiring the huge volumes of output also required for DEBUG3. This brings us back to the logging idea again. Right. I don't kno

Re: [HACKERS] Remove pg_am.amindexnulls?

On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: > Now that GIN can index null items, its amindexnulls flag in pg_am > really ought to be set true. However, looking at the usage of that > column, I wonder whether we shouldn't just delete it instead. The > only present usage is a rather c

[HACKERS] Remove pg_am.amindexnulls?

Now that GIN can index null items, its amindexnulls flag in pg_am really ought to be set true. However, looking at the usage of that column, I wonder whether we shouldn't just delete it instead. The only present usage is a rather convoluted test in CLUSTER to see if the index is safely clusterabl

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

"David E. Wheeler" writes: > We (PGX) actually have a client who could use this. Tom, if you have patches > as you work on this (or, better, a branch in a Git repo), I could do some > testing on your client's code with it. It would involve converting from a > GiST to a GIN index and then seeing

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

On Jan 4, 2011, at 3:18 PM, Josh Berkus wrote: > Actually, there's been a *lot* of complaining about the GIN issues. > It's just that most of that complaining doesn't reach -hackers. > > The common pattern I've seen in our practice and on IRC is: > > 1) user has GiST indexes > 2) user tries conv

Re: [HACKERS] LOCK for non-tables

On Jan7, 2011, at 23:56 , Robert Haas wrote: > On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug wrote: >> Thus, all objects which are dumped purely by SQL-level inspection of the >> system catalogs are safe I think. This is true for most objects I guess, >> with the important exception being dumping

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug wrote: > On Jan7, 2011, at 22:21 , Robert Haas wrote: >> So suppose you pg_dump a view and and a function that uses the view. >> In the middle of the dump, someone alters the view and the function in >> a single transaction and commits it.  You might d

Re: [HACKERS] join functions

07.01.2011 13:01, Nicolas Barbier пишет: That seems like a use case for LATERAL, which is not supported yet. Some recent discussion seems to be http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php>. Nicolas Thank you for your answer. Sorry, what i don`t find it myself. But I can`

Re: [HACKERS] estimating # of distinct values

Dne 7.1.2011 20:56, Jim Nasby napsal(a): > On Jan 7, 2011, at 5:32 AM, t...@fuzzy.cz wrote: >> Another thing I'm not sure about is where to store those intermediate >> stats (used to get the current estimate, updated incrementally). I was >> thinking about pg_stats but I'm not sure it's the right p

Re: [HACKERS] LOCK for non-tables

On Jan7, 2011, at 22:21 , Robert Haas wrote: > So suppose you pg_dump a view and and a function that uses the view. > In the middle of the dump, someone alters the view and the function in > a single transaction and commits it. You might dump the function > before the transaction commits and the v

Re: [HACKERS] Streaming base backups

On 05.01.2011 15:54, Magnus Hagander wrote: I've implemented a frontend for this in pg_streamrecv, based on the assumption that we wanted to include this in bin/ for 9.1 - and that it seems like a reasonable place to put it. This can obviously be moved elsewhere if we want to. That code needs a l

Re: [HACKERS] Streaming base backups

On 05.01.2011 15:54, Magnus Hagander wrote: * Suggestion from Heikki: perhaps at some point we're going to need a full bison grammar for walsender commands. Here's a patch for this (Also available at g...@github.com:hlinnaka/postgres.git, branch "streaming_base"). I thought I know our biso

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus wrote: > >> To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would >> be more clear than pg_stat_replication_master and >> pg_stat_replication_slave. > > Let's commit it so that some of us can get a look at the data it > contains, and the

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 7, 2011 at 12:17 PM, Simon Riggs wrote: > On Fri, 2011-01-07 at 08:16 -0500, Robert Haas wrote: > >> One of the things that I ripped out of the SQL/MED syntax patch before >> committing it was the hack that made LOCK TABLE also work on FOREIGN >> TABLEs.  Since we're treating a foreign

Re: [HACKERS] system views for walsender activity

On Fri, 2011-01-07 at 14:51 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote: > >> We try to avoid inidb-requiring changes (like renaming a system > >> object...) during beta. > > > Why? > > So that beta testers won't be forced to do a dum

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 20:51, Tom Lane wrote: > Simon Riggs writes: >> On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote: >>> We try to avoid inidb-requiring changes (like renaming a system >>> object...) during beta. > >> Why? > > So that beta testers won't be forced to do a dump and relo

Re: [HACKERS] obj_unique_identifier(oid)

On Jan 7, 2011, at 1:46 PM, Tom Lane wrote: > Joel Jacobson writes: >> The function obj_unique_identifier(oid) will return a unique name for _any_ >> oid. > > Surely this is broken by design? You can *not* assume that the same OID > isn't in use for different things in different system catalogs

Re: [HACKERS] obj_unique_identifier(oid)

The function should take both classid and oid as input. I'll fix. Sent from my iPhone On 7 jan 2011, at 20:59, Joel Jacobson wrote: > Sent from my iPhone > > On 7 jan 2011, at 20:46, Tom Lane wrote: > >> Joel Jacobson writes: >>> The function obj_unique_identifier(oid) will return a unique na

Re: [HACKERS] obj_unique_identifier(oid)

Sent from my iPhone On 7 jan 2011, at 20:46, Tom Lane wrote: > Joel Jacobson writes: >> The function obj_unique_identifier(oid) will return a unique name for _any_ >> oid. > > Surely this is broken by design? You can *not* assume that the same OID > isn't in use for different things in differ

Re: [HACKERS] estimating # of distinct values

On Jan 7, 2011, at 5:32 AM, t...@fuzzy.cz wrote: > Another thing I'm not sure about is where to store those intermediate > stats (used to get the current estimate, updated incrementally). I was > thinking about pg_stats but I'm not sure it's the right place - depending > on the algorithm, this may

Re: [HACKERS] system views for walsender activity

Simon Riggs writes: > On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote: >> We try to avoid inidb-requiring changes (like renaming a system >> object...) during beta. > Why? So that beta testers won't be forced to do a dump and reload. When and if pg_upgrade is actually 100% trustworthy,

Re: [HACKERS] obj_unique_identifier(oid)

Joel Jacobson writes: > The function obj_unique_identifier(oid) will return a unique name for _any_ > oid. Surely this is broken by design? You can *not* assume that the same OID isn't in use for different things in different system catalogs. They're only guaranteed unique within a catalog. T

Re: [HACKERS] system views for walsender activity

On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote: > On Fri, Jan 7, 2011 at 19:46, Josh Berkus wrote: > > > >> To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would > >> be more clear than pg_stat_replication_master and > >> pg_stat_replication_slave. > > > > Let's commit i

Re: [HACKERS] making an unlogged table logged

> Jan Wieck started a discussion back then to offer the basics we need in > core as far as queuing goes, here: > > http://archives.postgresql.org/pgsql-hackers/2010-05/msg01209.php > > What happened to that effort? Stalled due to lack of manpower, currently. --

Re: [HACKERS] We need to log aborted autovacuums

Greg, > It's already possible to detect the main symptom--dead row percentage is > much higher than the autovacuum threshold, but there's been no recent > autovacuum. That makes me less enthusiastic that there's such a genuine > need to justify the overhead of storing more table stats just to det

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 19:46, Josh Berkus wrote: > >> To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would >> be more clear than pg_stat_replication_master and >> pg_stat_replication_slave. > > Let's commit it so that some of us can get a look at the data it > contains, and then

Re: [HACKERS] system views for walsender activity

> To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would > be more clear than pg_stat_replication_master and > pg_stat_replication_slave. Let's commit it so that some of us can get a look at the data it contains, and then we can fix the name during beta. --

Re: [HACKERS] DISCARD ALL ; stored procedures

* Stephen Frost (sfr...@snowman.net) wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > > Making it part of DISCARD PLANS; and back-patching it to 8.3 where > > > DISCARD was introduced would be awesome for me. :) > > > > I'd need to look at this more closely before committing anything, but

Re: [HACKERS] crash-safe visibility map, take three

On Jan 5, 2011, at 8:10 PM, Robert Haas wrote: > On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh wrote: >> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit >> serve? > > If we modify a page on which PD_ALL_VISIBLE isn't set, we don't > attempt to update the visibility map.

Re: [HACKERS] [COMMITTERS] pgsql: Implement remaining fields of information_schema.sequences view

pete...@gmx.net (Peter Eisentraut) writes: > Implement remaining fields of information_schema.sequences view > > Add new function pg_sequence_parameters that returns a sequence's start, > minimum, maximum, increment, and cycle values, and use that in the view. > (bug #5662; design suggestion by Tom

[HACKERS] obj_unique_identifier(oid)

Hi all! I was a bit frustrated there was no function to generate a unique identifier for any oid. Instead of complaining, I decided to automate the process as far as possible. :) The result is a simple perl function to automatically generate a function for each regclass able to generate a unique

Re: [HACKERS] WIP: Range Types

On Fri, 2011-01-07 at 08:21 +, Florian Weimer wrote: > > > I'm wondering if one of these hint functions can be reused to compute > range lengths. Interesting idea. However, I don't really see a way to make that work. These f

Re: [HACKERS] some comments rewording in recovery.conf.sample about SR

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 07/01/2011 16:58, Robert Haas a écrit : > On Fri, Jan 7, 2011 at 7:23 AM, Jehan-Guillaume (ioguix) de Rorthais > wrote: >> PFA > > Committed, with some additional wordsmithing. Thank you ! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU

Re: [HACKERS] LOCK for non-tables

On Fri, 2011-01-07 at 08:16 -0500, Robert Haas wrote: > One of the things that I ripped out of the SQL/MED syntax patch before > committing it was the hack that made LOCK TABLE also work on FOREIGN > TABLEs. Since we're treating a foreign table as a different kind of > object than a TABLE in some

Re: [HACKERS] Re: [COMMITTERS] pgsql: New system view pg_stat_replication displays activity of wal sen

On Fri, Jan 7, 2011 at 8:47 AM, Itagaki Takahiro wrote: > On Fri, Jan 7, 2011 at 21:49, Magnus Hagander wrote: >>> New system view pg_stat_replication displays activity of wal sender >>> processes. >> >> Umm. SGML updates? > > Oops, sorry. Additional documentation patch attached. > Could you pro

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

I wrote: > 2. Add another output bool parameter to extractQuery that it must set > true (from a default false state) if the query could match with no check > values set. This would prompt the GIN code to search for EMPTY_ITEM > placeholders, but they'd not be part of the check[] array. On further

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 07, 2011 at 10:58:41AM -0500, Robert Haas wrote: > On Fri, Jan 7, 2011 at 10:52 AM, David Fetter wrote: > > I'm not sure I understand this.  Does it mean I'd have to say > > > >    LOCK TABLE my_view; > > No. +1 for #4, then :) Cheers, David. -- David Fetter http://fetter.org/ Pho

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 7, 2011 at 10:52 AM, David Fetter wrote: > I'm not sure I understand this.  Does it mean I'd have to say > >    LOCK TABLE my_view; No. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] some comments rewording in recovery.conf.sample about SR

On Fri, Jan 7, 2011 at 7:23 AM, Jehan-Guillaume (ioguix) de Rorthais wrote: > PFA Committed, with some additional wordsmithing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [HACKERS] LOCK for non-tables

On Fri, Jan 07, 2011 at 08:16:33AM -0500, Robert Haas wrote: > One of the things that I ripped out of the SQL/MED syntax patch before > committing it was the hack that made LOCK TABLE also work on FOREIGN > TABLEs. Since we're treating a foreign table as a different kind of > object than a TABLE i

Re: [HACKERS] DISCARD ALL ; stored procedures

* Robert Haas (robertmh...@gmail.com) wrote: > Really it seems to me that changing the search path ought to discard > anything that might have been done differently had the search path > been different, but I don't think that's back-patch material. I like that idea, but I agree it wouldn't be back

Re: [HACKERS] Streaming base backups

On Fri, Jan 07, 2011 at 10:26:29AM -0500, Garick Hamlin wrote: > On Thu, Jan 06, 2011 at 07:47:39PM -0500, Cédric Villemain wrote: > > 2011/1/5 Magnus Hagander : > > > On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine > > > wrote: > > >> Magnus Hagander writes: > > >>> * Stefan mentiond it might be

Re: [HACKERS] Streaming base backups

On Thu, Jan 06, 2011 at 07:47:39PM -0500, Cédric Villemain wrote: > 2011/1/5 Magnus Hagander : > > On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine > > wrote: > >> Magnus Hagander writes: > >>> * Stefan mentiond it might be useful to put some > >>> posix_fadvise(POSIX_FADV_DONTNEED) > >>>   in the

Re: [HACKERS] [COMMITTERS] pgsql: New system view pg_stat_replication displays activity of wal sen

Magnus Hagander writes: > On Fri, Jan 7, 2011 at 12:42, Itagaki Takahiro > wrote: >> New system view pg_stat_replication displays activity of wal sender >> processes. > Umm. SGML updates? Not to mention a catversion bump? regards, tom lane -- Sent via pgsql-hackers m

Re: [HACKERS] Streaming base backups

On Fri, Jan 7, 2011 at 01:47, Cédric Villemain wrote: > 2011/1/5 Magnus Hagander : >> On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine >> wrote: >>> Magnus Hagander writes: * Stefan mentiond it might be useful to put some posix_fadvise(POSIX_FADV_DONTNEED)   in the process that str

Re: [HACKERS] Streaming base backups

On Fri, Jan 7, 2011 at 02:15, Simon Riggs wrote: > On Wed, 2011-01-05 at 14:54 +0100, Magnus Hagander wrote: > >> The basic implementation is: Add a new command to the replication mode called >> BASE_BACKUP, that will initiate a base backup, stream the contents (in tar >> compatible format) of the

Re: [HACKERS] DISCARD ALL ; stored procedures

On Fri, Jan 7, 2011 at 8:43 AM, Stephen Frost wrote: > To be honest, I agree it's a bug, and I would *love* to have it > back-patched, but I could see an argument for it to be something > explicit from DISCARD PLANS; and would hence require a grammar > change which isn't something we'd typically b

Re: [HACKERS] Snapshot synchronization, again...

On Jan7, 2011, at 12:41 , Joachim Wieland wrote: > On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote: > These are the implementation details and restrictions of the patch: > > The exporting transaction > >- should be read-only (to discourage people from expecting that writes of > t

[HACKERS] Re: [COMMITTERS] pgsql: New system view pg_stat_replication displays activity of wal sen

On Fri, Jan 7, 2011 at 21:49, Magnus Hagander wrote: >> New system view pg_stat_replication displays activity of wal sender >> processes. > > Umm. SGML updates? Oops, sorry. Additional documentation patch attached. Could you proofread the text? -- Itagaki Takahiro pg_stat_replication_docs.pa

Re: [HACKERS] DISCARD ALL ; stored procedures

* Robert Haas (robertmh...@gmail.com) wrote: > If DISCARD ALL doesn't flush this stuff, I'd consider that an outright > bug. Does it? No, it does not, based on my testing against 8.4.5: Simple function: CREATE OR REPLACE FUNCTION test_func() RETURNS boolean AS $_$ D

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 8:09 AM, Itagaki Takahiro wrote: > On Fri, Jan 7, 2011 at 21:48, Magnus Hagander wrote: >>>  * pg_stat_replication >>>  * pg_stat_standby (not yet) >> >> Just to keep the bikeshedding up, should it in this case not be >> pg_stat_replication_master and pg_stat_replication_st

[HACKERS] LOCK for non-tables

One of the things that I ripped out of the SQL/MED syntax patch before committing it was the hack that made LOCK TABLE also work on FOREIGN TABLEs. Since we're treating a foreign table as a different kind of object than a TABLE in some places, we shouldn't confuse the two things elsewhere, at leas

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 21:48, Magnus Hagander wrote: >>  * pg_stat_replication >>  * pg_stat_standby (not yet) > > Just to keep the bikeshedding up, should it in this case not be > pg_stat_replication_master and pg_stat_replication_standby or such? > Replication applies to both master and slave...

Re: [HACKERS] system views for walsender activity

On Fri, Jan 7, 2011 at 12:42, Itagaki Takahiro wrote: > On Fri, Jan 7, 2011 at 19:20, Simon Riggs wrote: >>> "pg_stat_replication" seems to be the most understandable name. >> >> Please go with whatever you think best for now. I'm sure people will ask >> for different names later anyway. Let's ge

Re: [HACKERS] some comments rewording in recovery.conf.sample about SR

Obviously... PFA Le 07/01/2011 13:22, Jehan-Guillaume (ioguix) de Rorthais a écrit : > Hello Hackers, > > I believe comments in the recovery.conf.sample are somehow confusing > about standby and SR: > > # Edit this file to provide the parameters that PostgreSQL needs to > # perform an archi

[HACKERS] some comments rewording in recovery.conf.sample about SR

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Hackers, I believe comments in the recovery.conf.sample are somehow confusing about standby and SR: # Edit this file to provide the parameters that PostgreSQL needs to # perform an archive recovery of a database, or to act as a log-streamin

Re: [HACKERS] system views for walsender activity

ender/receiver as their names because standby activity in slaves could contain not only a wal receiver but also a recovery process. -- Itagaki Takahiro pg_stat_replication-20110107.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] Snapshot synchronization, again...

On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote: > What I am proposing now is the following: > > We return snapshot information as a chunk of data to the client. At > the same time however, we set a checksum in shared memory to protect > against modification of the snapshot. A publishing ba

Re: [HACKERS] estimating # of distinct values

> On Thu, 2010-12-30 at 21:02 -0500, Tom Lane wrote: >> How is an incremental ANALYZE going to work at all? > > How about a kind of continuous analyze ? > > Instead of analyzing just once and then drop the intermediate results, > keep them on disk for all tables and then piggyback the background >

Re: [HACKERS] system views for walsender activity

On Fri, 2011-01-07 at 12:13 +0900, Itagaki Takahiro wrote: > "pg_stat_replication" seems to be the most understandable name. > > > I would very much appreciate it if one of you could complete something > > here and commit in the next few days. That would then allow me to extend > > the view with

Re: [HACKERS] join functions

2011/1/5 Zotov : > Why doesn`t work this query? > select table1.field1, func1.field2 from table1 left outer join > func1(table1.field1) on true where func1.field3 in (20, 100); > > If i have other than LEFT OUTER JOIN I can understand why >   ERROR:  invalid reference to FROM-clause entry for tabl

Re: [HACKERS] making an unlogged table logged

Robert Haas writes: > Adding logical replication would be a lot of > work but we'd get a lot of collateral benefits. Imagine that PG had There has been extensive discussions at last pgcon about that (mainly in the "hallway track", but also in the devroom we had) to work on getting the common b

Re: [HACKERS] WIP: Range Types

* Jeff Davis: > On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote: >> * Jeff Davis: >> >> > 4. For the GiST penalty function, and perhaps some picksplit algorithms, >> > it might be nice to know the length of a range, or do some other kinds >> > of math. It introduces a lot of complexity to

Re: [HACKERS] Intermittent buildfarm failures in sequence test

Le 06/01/2011 16:03, Tom Lane a écrit : Have a look at http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=raven&dt=2011-01-05%2001%3A30%3A12 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2011-01-06%2002%3A30%3A01 I recall seeing a couple of similar failures in the past f

Re: [HACKERS] estimating # of distinct values

On Thu, 2010-12-30 at 21:02 -0500, Tom Lane wrote: > How is an incremental ANALYZE going to work at all? How about a kind of continuous analyze ? Instead of analyzing just once and then drop the intermediate results, keep them on disk for all tables and then piggyback the background writer (or ha

[HACKERS] join functions

Hello, Hackers! We have a project developed at Interbase and Firebird. Now we try use PostgreSQL and have some problem Why doesn`t work this query? select table1.field1, func1.field2 from table1 left outer join func1(table1.field1) on true where func1.field3 in (20, 100); If i have other than