Re: [HACKERS] parallel restore

Okay, another question --- there are two places in pg_backup_custom.c where the patch #ifdef's out hasSeek tests on WIN32. Why is that? If checkSeek() is wrong on Windows, wouldn't it be better to fix it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Bruce Momjian wrote: KaiGai Kohei wrote: Today, I'll debug the modified code... Wow, that was fast. Where are you storing the security information for tables and columns? Did you add a special column to pg_class, etc? Security information is stored within padding field of HeapTupleHeader as

Re: [HACKERS] reloptions with a "namespace"

Euler Taveira de Oliveira escreveu: [Forgot the first patch...] > Alvaro Herrera escreveu: >> New patch attached, with pg_dump support (thanks to Tom for the SQL >> heads-up). >> > Great! We're close. Just two minor gripes: > > + char *validnsps[] = { "toast" }; > > Surely, you forgot

Re: [HACKERS] reloptions with a "namespace"

Alvaro Herrera escreveu: > New patch attached, with pg_dump support (thanks to Tom for the SQL > heads-up). > Great! We're close. Just two minor gripes: + char *validnsps[] = { "toast" }; Surely, you forgot to add a NULL at the end. Patch is attached. IIRC, my last patch includes a

Re: [HACKERS] 8.4 release planning

On Thursday 29 January 2009 12:03:45 Robert Haas wrote: > I > don't believe that you can speed a project up much by adjusting the > length of the release cycle, but it is *sometimes* possible to speed > up a project by dividing up the work over more people. > This is interesting. We had a problem

Re: [HACKERS] How to get SE-PostgreSQL acceptable

KaiGai Kohei wrote: > >> Today, I'll debug the modified code... > > > > Wow, that was fast. Where are you storing the security information for > > tables and columns? Did you add a special column to pg_class, etc? > > Security information is stored within padding field of HeapTupleHeader > as w

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Bruce Momjian wrote: KaiGai Kohei wrote: Hasn't a plan for this already been posted? See http://archives.postgresql.org/pgsql-hackers/2009-01/msg02407.php FYI: * previous full-functional SE-PostgreSQL/Row-ACLs [kai...@fedora10 security]$ wc -l *.c */*.c 729 pgaceCommon.c 1547 pgaceHook

Re: [HACKERS] How to get SE-PostgreSQL acceptable

KaiGai Kohei wrote: > > Hasn't a plan for this already been posted? See > > http://archives.postgresql.org/pgsql-hackers/2009-01/msg02407.php > > FYI: > > * previous full-functional SE-PostgreSQL/Row-ACLs > > [kai...@fedora10 security]$ wc -l *.c */*.c > 729 pgaceCommon.c >1547 pgaceHoo

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Andrew Dunstan wrote: Josh Berkus wrote: Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? I think we're just not going to work out the headache-inducing issues

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Josh Berkus wrote: Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? Yes, obviously. I think the granularity of access controls is an aspect of security. I think

Re: [HACKERS] mingw check hung

Hiroshi Inoue wrote: Eventually does the crash come from the call SetEnvironemntVariable (.., NULL) on mingw-XP(or older?)? I'm also interested in this issue and want to know the cause. The debugger shows that we actually fail on a popen() call in intdb. However, if we replace the calls t

Re: [HACKERS] mingw check hung

Andrew Dunstan wrote: Andrew Dunstan wrote: Magnus Hagander wrote: Andrew Dunstan wrote: Magnus Hagander wrote: Are we *sure*, btw, that this is actually a mingw issue, and not something else in the environment? Could you try a MSVC compiled binary on the same machine? My

Re: [HACKERS] How to get SE-PostgreSQL acceptable

* Andrew Dunstan (and...@dunslane.net) wrote: > Josh Berkus wrote: >> So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all >> features *except* row-level security, would it still be useful to the >> SELinux community? >> >> I think we're just not going to work out the headache

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Josh Berkus wrote: Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? I think we're just not going to work out the headache-inducing issues around row-level secu

Re: [HACKERS] How to get SE-PostgreSQL acceptable

On Fri, Jan 30, 2009 at 5:37 PM, Josh Berkus wrote: > Bruce, >> Are you trying to make some kind of point? >> > > Yeah, that we're certainly not doing any of this for 8.4. > > If we're going for radical new approaches for row-level, why not also look > at the VIEWS approach? If we worked out the

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? I think we're just not going to work out the headache-inducing issues around row-level security in time for 8.4,

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Josh Berkus wrote: > Bruce, > > > Are you trying to make some kind of point? > > > > Yeah, that we're certainly not doing any of this for 8.4. > > If we're going for radical new approaches for row-level, why not also > look at the VIEWS approach? If we worked out the same problems we need >

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Bruce, Are you trying to make some kind of point? Yeah, that we're certainly not doing any of this for 8.4. If we're going for radical new approaches for row-level, why not also look at the VIEWS approach? If we worked out the same problems we need to fix for Bernd's patch, using automate

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Bruce Momjian wrote: > Josh Berkus wrote: >> Bruce Momjian wrote: >>> Josh Berkus wrote: > Yea, it would take some work but it is an idea. It's *an* idea,yes. But it introduces as many (or more) problems than it solves. >>> Ah, but my problems might be easier solved than the row-lev

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Josh Berkus wrote: > Bruce Momjian wrote: > > Josh Berkus wrote: > >>> Yea, it would take some work but it is an idea. > >> It's *an* idea,yes. But it introduces as many (or more) problems than > >> it solves. > > > > Ah, but my problems might be easier solved than the row-level permission > > p

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Bruce Momjian wrote: Josh Berkus wrote: Yea, it would take some work but it is an idea. It's *an* idea,yes. But it introduces as many (or more) problems than it solves. Ah, but my problems might be easier solved than the row-level permission problems. ;-) Or might not. Multi-partition i

Re: [HACKERS] PQinitSSL broken in some use casesf

Andrew Chernow wrote: > I am using a library that links with and initializes libcrypto (ie. > CRYPTO_set_locking_callback) but not SSL. This causes problems even > when using PQinitSSL(FALSE) because things like SSL_library_init(); are > not called (unless I manually call them, copy and paste c

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Merlin Moncure wrote: > likewise, with aliases > select foo f from foo; -- this is how it works now > update foo f set f=somefoo; -- again, this is how it should work thinko: select f from foo f; -- this is how it really works now merlin -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Sam Mason wrote: > But why not just leave INSERT as it is, it works and is unambiguous! Because *there is no way to insert a composite type!!!* (you can expand the type via INSERT ... SELECT, but not for UPDATE). SELECT foo FROM foo; pulls the foo composite from the table, not the fi

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Josh Berkus wrote: > > > Yea, it would take some work but it is an idea. > > It's *an* idea,yes. But it introduces as many (or more) problems than > it solves. Ah, but my problems might be easier solved than the row-level permission problems. ;-) -- Bruce Momjian http://momjian.u

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Yea, it would take some work but it is an idea. It's *an* idea,yes. But it introduces as many (or more) problems than it solves. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-ha

Re: [HACKERS] How to get SE-PostgreSQL acceptable

Joshua Brindle wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >> Gregory Stark writes: > >>> I don't think partitioning is really the same thing as row-level > >>> security. > >> Of course not, but it seems to me that it can be used to accomplish most > >> of the same practical use-cases. Th

Re: [HACKERS] using composite types in insert/update

On Fri, Jan 30, 2009 at 03:45:54PM -0500, Merlin Moncure wrote: > On 1/30/09, Sam Mason wrote: > > I was talking about your example code: > > > > INSERT INTO foo VALUES '(something)'::foo; > > > > This isn't currently valid, but it sounds as though it needs to be. > > hm. i don't think so...at

Re: [HACKERS] array_map not SQL accessible?

Alvaro Herrera writes: > It seems there's something wrong here. Ah, it's a bug in array_unnest: if its argument is toasted, it detoasts it into function-local memory, and then tries to keep a pointer to that across calls. Boo. Will fix. regards, tom lane -- Sent via p

Re: [HACKERS] parallel restore

Tom Lane wrote: Andrew Dunstan writes: Tom Lane wrote: One thing that is bothering me is that if the connection parameters are such as to cause prompts for passwords, it's going to be broken beyond usability (multiple threads all trying to read the terminal at once). Is there anythi

Re: [HACKERS] using composite types in insert/update

On Fri, Jan 30, 2009 at 03:29:29PM -0500, Andrew Chernow wrote: > Sam Mason wrote: > >On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote: > >>On 1/30/09, Tom Lane wrote: > >>>Merlin Moncure writes: > >>> > You are missing the point, using the composite type allows you to > >>> > build

Re: [HACKERS] parallel restore

Andrew Dunstan writes: > Tom Lane wrote: >> One thing that is bothering me is that >> if the connection parameters are such as to cause prompts for passwords, >> it's going to be broken beyond usability (multiple threads all trying >> to read the terminal at once). Is there anything we can do abo

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Sam Mason wrote: > On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote: > > On 1/30/09, Sam Mason wrote: > > > quite often (i.e. a VALUES command with many singletons). This seems > > > a bit annoying and appears to be what you were suggesting you wanted > > > befor

Re: [HACKERS] using composite types in insert/update

On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote: > On 1/30/09, Sam Mason wrote: > > quite often (i.e. a VALUES command with many singletons). This seems > > a bit annoying and appears to be what you were suggesting you wanted > > before (although you killed the relevant bit of c

Re: [HACKERS] using composite types in insert/update

Sam Mason wrote: On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote: On 1/30/09, Tom Lane wrote: Merlin Moncure writes: > You are missing the point, using the composite type allows you to > build the insert without knowing the specific layout of the > table... Surely at *some*

Re: [HACKERS] parallel restore

Tom Lane wrote: Andrew Dunstan writes: Latest patch is attached. Starting to look at this now. Excellent! One thing that is bothering me is that if the connection parameters are such as to cause prompts for passwords, it's going to be broken beyond usability (multiple threads

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Sam Mason wrote: > quite often (i.e. a VALUES command with many singletons). This seems > a bit annoying and appears to be what you were suggesting you wanted > before (although you killed the relevant bit of context, making me think > we may be talking about different things). w

Re: [HACKERS] using composite types in insert/update

On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote: > On 1/30/09, Tom Lane wrote: > > Merlin Moncure writes: > > > You are missing the point, using the composite type allows you to > > > build the insert without knowing the specific layout of the > > > table... > > > > Surely at *s

Re: [HACKERS] reloptions with a "namespace"

New patch attached, with pg_dump support (thanks to Tom for the SQL heads-up). Euler Taveira de Oliveira wrote: > I don't like the spreading validnsps' approach. Isn't there a way to > centralize those variables in one place, i.e., reloption.h ? Maybe one option is to create a #define with the

Re: [HACKERS] ecpg grammar in CVS is annoying

Tom Lane wrote: > Alvaro Herrera writes: > > Is it only me, or having the generated ecpg grammar is a bit obnoxious? > > I am getting troubled because whenever I touch gram.y it gets updated > > when I run make, and then it shows in "cvs diff". > > Huh? preproc.y was "cvs remove"d two months ago

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Tom Lane wrote: > Merlin Moncure writes: > > You are missing the point, using the composite type allows you to > > build the insert without knowing the specific layout of the > > table... > > Surely at *some* level you have to know that. You don't (if I understand your meaning) ..

Re: [HACKERS] ecpg grammar in CVS is annoying

Alvaro Herrera writes: > Is it only me, or having the generated ecpg grammar is a bit obnoxious? > I am getting troubled because whenever I touch gram.y it gets updated > when I run make, and then it shows in "cvs diff". Huh? preproc.y was "cvs remove"d two months ago. r

Re: [HACKERS] parallel restore

Andrew Dunstan writes: > Latest patch is attached. Starting to look at this now. One thing that is bothering me is that if the connection parameters are such as to cause prompts for passwords, it's going to be broken beyond usability (multiple threads all trying to read the terminal at once). I

Re: [HACKERS] ecpg grammar in CVS is annoying

Alvaro Herrera wrote: > Oh, another thing -- ecpg has a dependency on libpq, but it is not > declared in Makefiles, so if you build ecpg without first building > libpq, it errors out. This seems to fix the problem, but I'd prefer a rule that declared the dependency without recursing ... is there

Re: [HACKERS] ecpg grammar in CVS is annoying

Alvaro Herrera wrote: > Hi, > > Is it only me, or having the generated ecpg grammar is a bit obnoxious? > I am getting troubled because whenever I touch gram.y it gets updated > when I run make, and then it shows in "cvs diff". Hmm, and then weird things happen anyway; I just built it and it erro

[HACKERS] ecpg grammar in CVS is annoying

Hi, Is it only me, or having the generated ecpg grammar is a bit obnoxious? I am getting troubled because whenever I touch gram.y it gets updated when I run make, and then it shows in "cvs diff". I'm not sure what's the solution -- maybe something is missing in a .cvsignore file somewhere? Oh, a

Re: [HACKERS] array_map not SQL accessible?

Alvaro Herrera wrote: > Tom Lane wrote: > > > As it happens, I need to use it in the pg_dump support for TOAST > > > reloptions. > > > > Maybe something involving > > ARRAY(SELECT foo(x) FROM UNNEST(arrayvariable) x) > > Hmm, I'll have a look at this. It seems there's something wrong here.

Re: [HACKERS] array_map not SQL accessible?

Tom Lane wrote: > Alvaro Herrera writes: > > I'm wondering why don't we expose the array_map() function to the SQL > > level. > > It requires some notion of "reference to function", which doesn't really > exist in SQL. (Please don't say you're going to pass it a function > OID.) regproc maybe?

Re: [HACKERS] array_map not SQL accessible?

Alvaro Herrera writes: > I'm wondering why don't we expose the array_map() function to the SQL > level. It requires some notion of "reference to function", which doesn't really exist in SQL. (Please don't say you're going to pass it a function OID.) > As it happens, I need to use it in the pg_d

Re: [HACKERS] Should IS DISTINCT FROM work with ANY()?

On Jan 29, 2009, at 5:50 PM, Tom Lane wrote: I don't think we want it to come true. If we treat IS DISTINCT FROM as a weirdly-named operator then we have to provide an implementation for every datatype (oh, and another one for IS NOT DISTINCT FROM). The PITA factor is enormous. Much better to

Re: [HACKERS] How to learn all information on the user of a database?

I think you might want to ask this question on pgsql-novice or pgsql-general. You might also want to take a look at the pg_user and pg_stat_activity views. ...Robert On Fri, Jan 30, 2009 at 7:16 AM, wrote: > How to learn all information on the user of a database? (user name, > host name, sleep

[HACKERS] array_map not SQL accessible?

Hi, I'm wondering why don't we expose the array_map() function to the SQL level. As it happens, I need to use it in the pg_dump support for TOAST reloptions. Why? Well, TOAST reloptions are stored in the pg_class tuple of the TOAST table, so when I extract them directly, it looks like a simple

[HACKERS] [PATCH] Psql List Languages

Hi,, My job, I maintainer some postgres server for clients. We have many PL/(Java, Perl, Ruby, Python, R) and to more easy administration, I worked new little psql attribute to list languages com shorcurt/function \dL. postg...@darkside:/media/disk/devel/pg$ bin/psql -U postgres test psql (

Re: [HACKERS] using composite types in insert/update

On Fri, Jan 30, 2009 at 11:01:53AM -0500, Merlin Moncure wrote: > On 1/30/09, Sam Mason wrote: > > The VALUES command is just a convenient way of getting lots of tuples > > into PG isn't it? If the above was valid, PG would have to support > > similar syntax elsewhere, which seems independent o

Re: [HACKERS] [PATCH] Space reservation v02

Gregory Stark writes: > Well having a column in pg_class does have some advantages. Like, you could > look at the value from an sql session more easily. And if there are operations > which we know are unsafe -- such as adding columns -- we could clear it from > the server side easily. Why would t

Re: [HACKERS] [PATCH] Space reservation v02

Heikki Linnakangas wrote: > Bruce Momjian wrote: > > Heikki Linnakangas wrote: > >>> For example CREATE/ALTER TABLE can cause problems. > >> Yeah, if the pre-upgrade script determines the amount of reserved space > >> for each table, and sets it in pg_class or reloptions or whatever, it's > >> no

Re: [HACKERS] [PATCH] Space reservation v02

Bruce Momjian wrote: Heikki Linnakangas wrote: For example CREATE/ALTER TABLE can cause problems. Yeah, if the pre-upgrade script determines the amount of reserved space for each table, and sets it in pg_class or reloptions or whatever, it's not clear how mwhat to do with tables created after

Re: [HACKERS] [PATCH] Space reservation v02

Heikki Linnakangas wrote: > > For example CREATE/ALTER TABLE can cause problems. > > Yeah, if the pre-upgrade script determines the amount of reserved space > for each table, and sets it in pg_class or reloptions or whatever, it's > not clear how mwhat to do with tables created after the script

Re: [HACKERS] [PATCH] Space reservation v02

Heikki Linnakangas writes: > Zdenek Kotala wrote: >> Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500: >>> Well, I was thinking the new pg_class column would allow the upgrade to >>> verify the pre-upgrade script was run properly, but a flat file works >>> just as well if we assume we are going

Re: [HACKERS] mingw check hung

Andrew Dunstan wrote: > > Anyway, yes, I think that would be OK. How do we then test to see if > > the original problem is still fixed? > > > > > > Further proof that this is a Windows version issue: I took the problem > build from my XP and put it on my Vista box: the same build that causes >

Re: [HACKERS] [PATCH] Space reservation v02

Zdenek Kotala wrote: Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500: Well, I was thinking the new pg_class column would allow the upgrade to verify the pre-upgrade script was run properly, but a flat file works just as well if we assume we are going to pre-upgrade in one pass. Flat file or

Re: [HACKERS] using composite types in insert/update

Merlin Moncure writes: > You are missing the point, using the composite type allows you to > build the insert without knowing the specific layout of the > table... Surely at *some* level you have to know that. regards, tom lane -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] mingw check hung

Andrew Dunstan wrote: Magnus Hagander wrote: Andrew Dunstan wrote: Magnus Hagander wrote: Are we *sure*, btw, that this is actually a mingw issue, and not something else in the environment? Could you try a MSVC compiled binary on the same machine? My MSVC buildfarm animal

Re: [HACKERS] using composite types in insert/update

On 1/30/09, Sam Mason wrote: > On Wed, Jan 28, 2009 at 12:03:56PM -0500, Merlin Moncure wrote: > > IMO, composite types on insert/update should work as they do on select: > > The VALUES command is just a convenient way of getting lots of tuples > into PG isn't it? If the above was valid, PG wou

Re: [HACKERS] reloptions with a "namespace"

Euler Taveira de Oliveira wrote: > Alvaro Herrera escreveu: > > Okay, so I've changed things so that the transformRelOptions' caller is > > now in charge of passing an array of valid option namespaces. This is > > working A-OK. I'm now going to figure out appropriate pg_dump support > > and comm

Re: [HACKERS] [PATCH] Space reservation v02

Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500: > Heikki Linnakangas wrote: > > Bruce Momjian wrote: > > > The patch has two space reservations, one per page, another per tuple. > > > Now, thinking back, what types of changes have we made that increase > > > storage size. The one that I can

Re: [HACKERS] [PATCH] Space reservation v02

Heikki Linnakangas wrote: > Bruce Momjian wrote: > > The patch has two space reservations, one per page, another per tuple. > > Now, thinking back, what types of changes have we made that increase > > storage size. The one that I can think of first is where we made a data > > type require larger

Re: [HACKERS] mingw check hung

Magnus Hagander wrote: Andrew Dunstan wrote: Magnus Hagander wrote: Are we *sure*, btw, that this is actually a mingw issue, and not something else in the environment? Could you try a MSVC compiled binary on the same machine? My MSVC buildfarm animal runs on the same machin

Re: [HACKERS] fflush

Jean-Michel Riet wrote: Hello, I'm coding some functions in C language on Windows for Postgres server (calling from PG). After dll generation and put it to the correct postgres directory the problem is as follow : Postgres stop running when i call /fflush() / function on a file stream

Re: [HACKERS] mingw check hung

Andrew Dunstan wrote: > > > Magnus Hagander wrote: >> >> Are we *sure*, btw, that this is actually a mingw issue, and not >> something else in the environment? Could you try a MSVC compiled binary >> on the same machine? >> > > My MSVC buildfarm animal runs on the same machine, and does not s

[HACKERS] fflush

Hello, I'm coding some functions in C language on Windows for Postgres server (calling from PG). After dll generation and put it to the correct postgres directory the problem is as follow : Postgres stop running when i call  fflush()  function on a file stream and no data are in my file. Th

[HACKERS] How to learn all information on the user of a database?

How to learn all information on the user of a database? (user name, host name, sleep or running,connect or disconnect) Thanks Regards, Mr. St -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-

Re: [HACKERS] mingw check hung

Magnus Hagander wrote: Are we *sure*, btw, that this is actually a mingw issue, and not something else in the environment? Could you try a MSVC compiled binary on the same machine? My MSVC buildfarm animal runs on the same machine, and does not suffer the same problem. cheers andrew

Re: [HACKERS] using composite types in insert/update

On Wed, Jan 28, 2009 at 12:03:56PM -0500, Merlin Moncure wrote: > IMO, composite types on insert/update should work as they do on select: > INSERT INTO foo VALUES '(something)'::foo -- fails, The VALUES command is just a convenient way of getting lots of tuples into PG isn't it? If the above was

Re: [HACKERS] Synch Replication - Synch rep 0114

Hi, On Fri, Jan 30, 2009 at 8:05 PM, Patil, Smita (NSN - IN/Bangalore) wrote: > Hi, > I have been testing in recent, the Synch Replication(Synch rep 0114 (Jan 14, > 2009) ) on PostgreSQL version 8.4 ( > postgresql-8.4devel_20081229.tar.bz2) Thanks for your testing and report! I'm afraid that th

[HACKERS] Synch Replication - Synch rep 0114

Hi, I have been testing in recent, the Synch Replication(Synch rep 0114 (Jan 14, 2009) ) on PostgreSQL version 8.4 ( postgresql-8.4devel_20081229.tar.bz2 )

[HACKERS] Synch Replication - Synch rep 0114

Hi, I have been testing in recent, the Synch Replication(Synch rep 0114 (Jan 14, 2009) ) on PostgreSQL version 8.4 (postgresql-8.4devel_20081229.tar.bz2) I followed the steps in Readme as well used the test script provided in patch for the setup. As per wiki, I am able to bring up the walsender an

[HACKERS] Synch Replication - Synch rep 0114

Hi, I have been testing in recent, the Synch Replication(Synch rep 0114 (Jan 14, 2009) ) on PostgreSQL version 8.4 (postgresql-8.4devel_20081229.tar.bz2) I followed the steps in Readme as well used the test script provided in patch for the setup. As per wiki, I am able to bring up the walsender an

Re: [HACKERS] Hot standby, recovery infra

Simon Riggs wrote: On Thu, 2009-01-29 at 19:20 +0200, Heikki Linnakangas wrote: Hmm, seems like we haven't thought through how shutdown during consistent recovery is supposed to behave in general. Right now, smart shutdown doesn't do anything during consistent recovery, because the startup pro

Re: [HACKERS] Hot standby, recovery infra

Simon Riggs wrote: I'm thinking to add a new function that will allow crash testing easier. pg_crash_standby() will issue a new xlog record, XLOG_CRASH_STANDBY, which when replayed will just throw a FATAL error and crash Startup process. We won't be adding that to the user docs... This will all

Re: [HACKERS] Hot standby, recovery infra

On Thu, 2009-01-29 at 14:21 +0200, Heikki Linnakangas wrote: > It looks like if you issue a fast shutdown during recovery, postmaster > doesn't kill bgwriter. Thanks for the report. I'm thinking to add a new function that will allow crash testing easier. pg_crash_standby() will issue a new xlo

Re: [HACKERS] Hot standby, recovery infra

On Fri, 2009-01-30 at 11:33 +0200, Heikki Linnakangas wrote: > I just realized that the new minSafeStartPoint is actually exactly the > same concept as the existing minRecoveryPoint. As the recovery > progresses, we could advance minRecoveryPoint just as well as the new > minSafeStartPoint. >

Re: [HACKERS] Hot standby, recovery infra

On Thu, 2009-01-29 at 19:20 +0200, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: > > It looks like if you issue a fast shutdown during recovery, postmaster > > doesn't kill bgwriter. > > Hmm, seems like we haven't thought through how shutdown during > consistent recovery is supposed to

Re: [HACKERS] Hot standby, recovery infra

On Thu, 2009-01-29 at 20:35 +0200, Heikki Linnakangas wrote: > Hmm, another point of consideration is how this interacts with the > pause/continue. In particular, it was suggested earlier that you > could > put an option into recovery.conf to start in paused mode. If you > pause > recovery, and

Re: [HACKERS] Hot standby, recovery infra

I just realized that the new minSafeStartPoint is actually exactly the same concept as the existing minRecoveryPoint. As the recovery progresses, we could advance minRecoveryPoint just as well as the new minSafeStartPoint. Perhaps it's a good idea to keep them separate anyway though, the orig

Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)

Stefan Kaltenbrunner píše v čt 29. 01. 2009 v 18:29 +0100: > Peter Eisentraut wrote: > > On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote: > >> well from a quick glance there is the bugzilla demo install as well as > >> pieces of reviewboard and patchwork on the trackerdemo jail. >

Re: [HACKERS] using composite types in insert/update

Merlin Moncure wrote: > however no such workaround exists for update. ideally, > UPDATE foo SET foo = foo; +1. "UPDATE foo SET (*) = (foo.*)" would be another candidate of syntax. I want to use this kind of queries to apply a changeset log to another table. It is just like log application in S

Re: [HACKERS] mingw check hung

Andrew Dunstan wrote: > > > Magnus Hagander wrote: >> Andrew Dunstan wrote: >> >>> Magnus Hagander wrote: >>> > Specifically, it's the SetEnvironmentVariable() call from > pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled > things work just fine. >