[HACKERS] Privileges and inheritance

I would like to propose a change in the way privilege checking is done with inheritance hierarchies. Currently, selecting from a table that has children requires explicit privileges on all the children. This is inconsistent with all other commands, which treat children as implicitly part of the p

Re: [HACKERS] clang's static checker report.

new version under: http://zlew.org/postgresql_static_check/scan-build-2009-10-03-1/ What's strange, is the increase of 48.2 percent in reports, that happened about two weeks before (weekend before the previous one). enjoy. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] FSM search modes

On Oct 1, 2009, at 4:18 PM, Robert Haas wrote: On Thu, Oct 1, 2009 at 5:08 PM, Tom Lane wrote: Robert Haas writes: The elephant in the room here is that if the relation is a million pages of which 1-100,000 and 1,000,000 are in use, no amount of bias is going to help us truncate the relatio

ECPG dynamic cursorname patch revised and split Re: [HACKERS] CommitFest 2009-09, two weeks on

Robert Haas írta: > On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan wrote: > >> Hi, >> >> Michael Meskes írta: >> >>> It is accepted either way. I was just pointing out that it might be easier >>> to >>> review/commit at least parts of your patches if they can be applied >>> seperatel

Re: [HACKERS] Getting the red out (of the buildfarm)

Peter Eisentraut writes: > On Wed, 2009-09-23 at 10:20 -0400, Tom Lane wrote: >> comet_moth, gothic_moth: these are failing the new plpython_unicode >> test >> in locale cs_CZ.ISO8859-2. Somebody needs to do something about that. >> If it's left to me I'll probably just remove the test that has >

Re: [HACKERS] latest hstore patch

> "Bruce" == Bruce Momjian writes: >> There's still the issue of how to get the improved module >> definition (new functions etc) into a migrated database. That's >> not specific to hstore in any way though, it would affect any >> contrib module that had added stuff in a new release. B

Re: [HACKERS] FSM search modes

Kevin Grittner wrote: > Tom Lane wrote: > > > (Hm, so we might want to make the probability depend on > > max_connections?) > > Without doing rigorous math on it, I'd guess that to prevent > contention among n connections you'd want the probably of resetting > the sweep to be about 1 / (n * 2

Re: [HACKERS] Postgres server goes in recovery mode repeteadly

On Fri, Oct 02, 2009 at 10:41:07AM -0400, Alvaro Herrera wrote: > daveg escribió: > > > I work with Kunal and have been looking into this. It appears to be the same > > as the bug described in: > > > > http://archives.postgresql.org/pgsql-bugs/2009-09/msg00355.php > > > > as I have localized i

Re: [HACKERS] CommitFest 2009-09, two weeks on

On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan wrote: > Hi, > > Michael Meskes írta: >> It is accepted either way. I was just pointing out that it might be easier to >> review/commit at least parts of your patches if they can be applied >> seperately. >> > > I have split up (and cleaned up a

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Friday 02 October 2009 04:21:35 Roger Leigh wrote: > On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote: > > Roger Leigh writes: > > >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote: > > >>> Thinking about this some more, ISTM a much better way of approaching > > >>> it would be

Re: [HACKERS] Rejecting weak passwords

Tom Lane wrote: > Magnus Hagander writes: > > That said, it would still be good to have something actually *useful* > > in contrib. A bit more than just comparing userid and password. > > Perhaps at least being able to set the min length, and the requirement > > on having >1 "character class"? >

[HACKERS] 8.5 TODO: any info on "Create dump tool for write-ahead logs..." in PITR section (1.4)?

Can anyone elaborate (or point me to some additional info) on the 8.5 TODO item in the "Point-In-Time Recover (PITR) section (1.4)": Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery This is useful for checking PITR recovery. I poked arou

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

Jim Cox wrote: > On Fri, Oct 2, 2009 at 6:11 PM, Bruce Momjian wrote: > > Tom Lane wrote: > >> Bruce Momjian writes: > >> > Are we sure we don't want a date/time in the ASCII dump? ?It would > >> > affect database diffs, but I can see it useful too. > >> > >> We used to have one, and it was remov

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

On Fri, Oct 2, 2009 at 6:11 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >> > Are we sure we don't want a date/time in the ASCII dump?  It would >> > affect database diffs, but I can see it useful too. >> >> We used to have one, and it was removed by popular demand >> (or a

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

Tom Lane wrote: > Bruce Momjian writes: > > Are we sure we don't want a date/time in the ASCII dump? It would > > affect database diffs, but I can see it useful too. > > We used to have one, and it was removed by popular demand > (or actually demoted to be printed only in verbose mode, IIRC). >

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

Bruce Momjian writes: > Are we sure we don't want a date/time in the ASCII dump? It would > affect database diffs, but I can see it useful too. We used to have one, and it was removed by popular demand (or actually demoted to be printed only in verbose mode, IIRC). I don't feel a need to revisit

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

Jim Cox wrote: > On Tue, Sep 29, 2009 at 12:00 AM, Alvaro Herrera > wrote: > > Jim Cox escribi?: > > > >> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating > >> version > >> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2). > > > > Hmm, what happens

Re: [HACKERS] latest hstore patch

"David E. Wheeler" writes: > On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote: >> Yes, that's my point too, against David's argument that "surely someone >> must have solved it". What we have here is a new problem, so it's not >> so clear that there's any solution at all (yet). > > Yeah, I didn'

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 18:04 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > I will add code to make a shutdown checkpoint be a valid starting place > > for Hot Standby, as long as there are no in-doubt prepared transactions. > > That way we know there are no xids still running and no loc

Re: [HACKERS] Hot Standby 0.2.1

On Sun, 2009-09-27 at 14:59 +0300, Heikki Linnakangas wrote: > The locking in smgr_redo_commit and smgr_redo_abort doesn't look right. > First of all, smgr_redo_abort is not holding XidGenLock and > ProcArrayLock while modifying ShmemVariableCache->nextXid and > ShmemVariableCache->latestCompleted

Re: [HACKERS] Triggers on columns

On Thu, 2009-10-01 at 10:40 +0900, Itagaki Takahiro wrote: > > Peter Eisentraut wrote: > > > If you want a "pretty" option on pg_get_triggerdef(), you could nowadays > > > also implement that via a parameter default value instead of a second > > > function. > > > > OK, I'll rewrite it to use defa

Re: [HACKERS] latest hstore patch

David E. Wheeler wrote: > On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote: > > > Well, if it is just changed syntax, we could wack around the system > > catalogs. If storage changes, we have to dump/reload that data type. > > Andrew solved this problem for hstore by making the new version able

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote: Well, if it is just changed syntax, we could wack around the system catalogs. If storage changes, we have to dump/reload that data type. Andrew solved this problem for hstore by making the new version able to read the old representation. It

Re: [HACKERS] LIMIT 1 == EXISTS optimization?

Richard Rowell writes: > I'm no backend guru, so I was hoping someone could explain what the original > query-plan was doing. If all you need to know is if a row exists, why loop > over all 3M rows? It seems very simplistic to assume the a LIMIT 1 clause > on the end of all EXISTS subqueries wou

[HACKERS] remove useless set of active snap

This patch removes a useless pushing of an active snapshot on PortalStart. Instead of push/get/pop of the active snapshot, without any intervening use of the active snapshot, we just pass a local snapshot down to CreateQueryDesc. -- Alvaro Herrerahttp://www.Comman

Re: [HACKERS] latest hstore patch

David E. Wheeler wrote: > On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote: > > >> Plus lots of stuff on pgFoundry. It's a problem that needs to be > >> solved. Surely someone, somewhere, has solved this problem, no? > > > > Dump & reload? > > Hahahahaha. No, really. "Dump & reload" is a phrase t

[HACKERS] LIMIT 1 == EXISTS optimization?

I was just troubleshooting a slow query SELECT * FROM da_answer a WHERE a.provider_id IN ( SELECT visibility_bypass_providers( 0, 0 ) ) OR -- ownership ( EXISTS ( -- Visibility grant SELECT v.client_answer_id FROM sp_client_answervisibility v JOIN sp_sharing_grou

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

2009/10/2 Stephen Frost : > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> My inclination is to think that the right behavior for REPLACE FUNCTION >> is to keep the old proowner and proacl values, because that's what it >> always has done and nobody's complained. > > +1. +1 Pavel > >        Stephen >

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote: The point is it's *not* solved in the context of using pg_migrator. Yes, that's my point too, against David's argument that "surely someone must have solved it". What we have here is a new problem, so it's not so clear that there's any sol

[HACKERS] Inappropriate failure conditions in foreign_data regression test

By chance I noticed that the foreign_data regression test fails if run in an installation where "bob" is a live user. It appears to be assuming that half a dozen other fairly common names don't belong to real users, either. Could we make this a little less fragile? Maybe call them no_such_user_N

Re: [HACKERS] latest hstore patch

Tom Lane wrote: > Alvaro Herrera writes: > > David E. Wheeler wrote: > >> Plus lots of stuff on pgFoundry. It's a problem that needs to be > >> solved. Surely someone, somewhere, has solved this problem, no? > > > Dump & reload? > > The point is it's *not* solved in the context of using pg_migra

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

* Tom Lane (t...@sss.pgh.pa.us) wrote: > My inclination is to think that the right behavior for REPLACE FUNCTION > is to keep the old proowner and proacl values, because that's what it > always has done and nobody's complained. +1. Stephen signature.asc Description: Digital signature

Re: [HACKERS] latest hstore patch

Alvaro Herrera writes: > David E. Wheeler wrote: >> Plus lots of stuff on pgFoundry. It's a problem that needs to be >> solved. Surely someone, somewhere, has solved this problem, no? > Dump & reload? The point is it's *not* solved in the context of using pg_migrator. re

Re: [HACKERS] [PATCH] DefaultACLs

Petr Jelinek napsal(a): Robert Haas napsal(a): I'm going to reiterate what I suggested upthread... let's let the default, global default ACL contain the hard-wired privileges, instead of making them hardwired. Then your objects will get those privileges not because they are hard-wired, but bec

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote: Plus lots of stuff on pgFoundry. It's a problem that needs to be solved. Surely someone, somewhere, has solved this problem, no? Dump & reload? Hahahahaha. No, really. "Dump & reload" is a phrase that end users will not put up with for much

Re: [HACKERS] latest hstore patch

David E. Wheeler wrote: > Plus lots of stuff on pgFoundry. It's a problem that needs to be > solved. Surely someone, somewhere, has solved this problem, no? Dump & reload? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom D

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

I wrote: > Whichever way you think it should work, there's a bug here that goes > back several versions, and I rather suspect we may have the same issue > for other REPLACE-type commands ... BTW, I looked around for related problems and don't see any. We only have CREATE OR REPLACE for functions,

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Oct 2, 2009, at 8:49 AM, Tom Lane wrote: The ideal is that backends will start using the new function implementation on the next call after the REPLACE commits (but any evaluations already in progress must of course continue with the text they have). We have been gradually getting closer to

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

"David E. Wheeler" writes: > Okay, this convinces me otherwise. But is it not in fact the case that > CREATE OR REPLACE FUNCTION doesn't expire the old version of the > function in the cache of other processes? It is not. > Don't those processes have > to reconnect in order to see the new

Re: [HACKERS] Issues for named/mixed function notation patch

On Fri, 2009-10-02 at 16:06 +0200, Pavel Stehule wrote: > see attachment, please Thank you, marked as "ready for committer". Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 8:20 AM, Bruce Momjian wrote: Most modules just install functions, which are easily uninstalled/reinstalled. A data type like hstore is more complicated assuming it is the data type that is changing and not the support functions. Lots of modules install data types. From con

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Fri, Oct 2, 2009 at 10:25 AM, Caleb Welton wrote: > Right - so the subtle point here is that ALTER means something > different from CREATE OR REPLACE.  "ALTER" means to make a > modification to something; to change it; to adjust one particular > property of the object without disturbing the oth

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Oct 2, 2009, at 7:49 AM, Tom Lane wrote: But in fact CREATE OR REPLACE is *not* meant to be the same as DROP followed by CREATE. What it is meant to do is allow you to replace the implementation of the function while existing callers see it as still being the same function. Thus we preve

Re: [HACKERS] latest hstore patch

Tom Lane wrote: > Bruce Momjian writes: > > Are there any pg_migrator affects in this patch? We had discussed this > > issue in the past with this patch. > > The code is upward compatible with the old on-disk format, so that > end of things is fine. > > There's still the issue of how to get the

Re: [HACKERS] latest hstore patch

Bruce Momjian writes: > Are there any pg_migrator affects in this patch? We had discussed this > issue in the past with this patch. The code is upward compatible with the old on-disk format, so that end of things is fine. There's still the issue of how to get the improved module definition (new

Re: [HACKERS] latest hstore patch

Tom Lane wrote: > Andrew Gierth writes: > > Hstore patch incorporating changes as previously discussed. > > In addition the requested new features of conversions to and from > > array formats have been added (with docs). > > Applied with some mostly-cosmetic editorialization. Are there any pg_mi

Re: [HACKERS] latest hstore patch

Tom Lane wrote: > > I intentionally avoided hstore_to_array because it would be unclear > > which one it meant (the 1-d or 2-d result). > > hstore_to_list seems like a pretty horrible name though for something > that produces an array. I also note that "array" means "1-D array" > according to no

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > I will add code to make a shutdown checkpoint be a valid starting place > for Hot Standby, as long as there are no in-doubt prepared transactions. > That way we know there are no xids still running and no locks, without > needing to write a record to say so. Ok, I can live wit

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

KaiGai Kohei writes: > Robert Haas wrote: >> I disagree. I think David has this one right. I expect the results >> of CREATE OR REPLACE to be the same as the result of CREATE would have >> been had the object not existed. > If so, it seems to me CREATE OR REPLACE is equivalent to a pair of > ac

Re: [HACKERS] Postgres server goes in recovery mode repeteadly

daveg escribió: > I work with Kunal and have been looking into this. It appears to be the same > as the bug described in: > > http://archives.postgresql.org/pgsql-bugs/2009-09/msg00355.php > > as I have localized it to a NULL pointer deference in > RelationCacheInitializePhase2() as well. Tom

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On 10/1/09 9:26 PM, "Robert Haas" wrote: 2009/10/1 KaiGai Kohei : > Robert Haas wrote: >> On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira >> wrote: >>> David E. Wheeler escreveu: On Oct 1, 2009, at 3:42 PM, Tom Lane wrote: > My inclination is to think that the right behav

Re: [HACKERS] CommitFest 2009-09, two weeks on

Michael Meskes írta: > On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote: > >> Yes, but technical problems and solutions do. ECPG claims >> to be ESQL/C compatible, but at places it's only half compatible. >> > > Where does it claim to be fully compatible? > I didn't sa

[HACKERS] commented out para in docs

We have this para in the CREATE TABLE docs, commented out, as shown. It seems to have been like that for a long time (see ). Surely we should either include it or remove it. Having it commented o

Re: [HACKERS] FSM search modes

Tom Lane wrote: > "Kevin Grittner" writes: >> [pages with free space or total pages in relation?] > > It's going to be the latter --- we do not know, and are *not* going > to invest the cycles to find out, how many pages have a useful > amount of free space. Even finding out the relation physi

Re: [HACKERS] CommitFest 2009-09, two weeks on

On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote: > Yes, but technical problems and solutions do. ECPG claims > to be ESQL/C compatible, but at places it's only half compatible. Where does it claim to be fully compatible? > This comment is misleading and reflects quite a narrow

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 13:52 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > I'd rather just skip this for now. It's a minor case anyway and there's > > nothing stopping writing their own RunningXactData records with a > > function, if it is needed. I can add a function for that. > > Tha

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera wrote: - ALTER ROLE ... IN DATABASE is missing some documentation. If you want, i can work on this. Please. Here's a patch for this. I've kept it separately, so it's easier for you to merge it into your version. -- Thanks Be

Re: [HACKERS] Using results from INSERT ... RETURNING

Robert Haas wrote: Now the point here is that I eventually want to be able to write something like this: with foo as (insert into project (name) values ('Writeable CTEs') returning id) select * from foo; ...but how does this get me any closer? It seems to me that the plan for THAT statement ha

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote: > Roger Leigh writes: > >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote: > >>> Thinking about this some more, ISTM a much better way of approaching > >>> it would be to provide a flag for psql to turn off the fancy > >>> format

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > I'd rather just skip this for now. It's a minor case anyway and there's > nothing stopping writing their own RunningXactData records with a > function, if it is needed. I can add a function for that. That won't help. There's no way to have it in a right place wrt. the shutdown

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 11:26 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote: > > > >> It seems dangerous to write a WAL record after the shutdown checkpoint. > >> It will be overwritten by subsequent startup, which is a recipe

Re: [HACKERS] Using results from INSERT ... RETURNING

Robert Haas wrote: Thanks. I read through this patch some more tonight and I guess I am a bit confused about what it accomplishes. AIUI, the point here is to lay the groundwork for a future patch to allow writeable CTEs, and I guess I'm not understanding how it's going to do that. The purpose

Re: [HACKERS] Issues for named/mixed function notation patch

2009/10/2 Jeff Davis : > On Thu, 2009-10-01 at 17:56 +1000, Brendan Jurd wrote: >> I've had a look through the documentation and cleaned up a few things. > > Thanks, that is helpful. I have included that along with some other > comment updates in the attached patch. > > Paval, > > In ProcedureCreat

Re: [HACKERS] "make install" now tries to build the documentation

On Thu, 2009-10-01 at 15:17 -0400, Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > I'm not exactly sure what the goal is, however. You built the > > documentation at some point. Then it gets updated when necessary. You > > can delete the documentation by running make -C doc maintainer-cle

Re: [HACKERS] [PATCH] DefaultACLs

Robert Haas napsal(a): On Thu, Oct 1, 2009 at 1:37 PM, Tom Lane wrote: Petr Jelinek writes: because it seems like merging privileges seems to be acceptable for most (although I am not sure I like it, but I don't have better solution for managing conflicts), I changed the patch to do j

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 11:26 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote: > > > >> It seems dangerous to write a WAL record after the shutdown checkpoint. > >> It will be overwritten by subsequent startup, which is a recipe

Re: [HACKERS] Issues for named/mixed function notation patch

On Thu, 2009-10-01 at 17:56 +1000, Brendan Jurd wrote: > I've had a look through the documentation and cleaned up a few things. Thanks, that is helpful. I have included that along with some other comment updates in the attached patch. Paval, In ProcedureCreate(), you match the argument names to

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote: > >> It seems dangerous to write a WAL record after the shutdown checkpoint. >> It will be overwritten by subsequent startup, which is a recipe for trouble. > > I've said its a corner case and not worth spending tim

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote: > It seems dangerous to write a WAL record after the shutdown checkpoint. > It will be overwritten by subsequent startup, which is a recipe for trouble. I've said its a corner case and not worth spending time on. I'm putting it in at y

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 10:32 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > I will docuemnt the recommendation to set max_standby_delay = 0 if > > performing an archive recovery (and explain why). > > Hmm, not sure if that's such a good piece of advice either. It will mean > waiting for

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > On Fri, 2009-10-02 at 10:04 +0300, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg) >>> else >>> { >>> /* >>> +* Take a snapshot of running transactions and write this to WAL. >>> +* Thi

Re: [HACKERS] Hot Standby on git

On Fri, 2009-10-02 at 10:04 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg) > > else > > { > > /* > > +* Take a snapshot of running transactions and write this to WAL. > > +* This allows us to recons

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > I will docuemnt the recommendation to set max_standby_delay = 0 if > performing an archive recovery (and explain why). Hmm, not sure if that's such a good piece of advice either. It will mean waiting for queries forever, which probably isn't what you want if you're performing

Re: [HACKERS] Hot Standby on git

Simon Riggs wrote: > @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg) > else > { > /* > +* Take a snapshot of running transactions and write this to WAL. > +* This allows us to reconstruct the state of running transactions > +* during archive recovery