Re: [HACKERS] operator dependency of commutator and negator, redux

On 20 December 2012 11:51, Tom Lane wrote: > > While reconsidering the various not-too-satisfactory fixes we thought of > back then, I had a sudden thought. Instead of having a COMMUTATOR or > NEGATOR forward reference create a "shell" operator and link to it, > why not simply *ignore* such refer

Re: [HACKERS] FDW: ForeignPlan and parameterized paths

> I intentionally did the nestloop_params substitution after calling > GetForeignPlan not before. It's not apparent to me why it would be > useful to do it before, because the FDW is going to have no idea what > those params represent. (Note that they represent values coming from > some other, pr

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

I'm initialize data dir with use ru_RU.UTF8, but this databse use CP1251, ie one byte per character. 19.12.2012, 21:47, "Tom Lane" : > "Kevin Grittner" writes: > >>  Groshev Andrey wrote: >>    Mismatch of relation names: database "database", old rel >> public.lob.ВерсияВнешнегоДокумента$Докум

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

No, people can confuse writing, but it makes a computer. Unfortunately, I have not found developer this database, but I understand the logic was: plob - primary key (lob ~ BLOB) rlob - reference key (lob ~ BLOB) Maybe if I describe the task, this part of the database, the problem is clear. We need

Re: [HACKERS] Set visibility map bit after HOT prune

On Thursday, December 20, 2012 6:14 AM Robert Haas wrote: > On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs > wrote: > > The benefit of saying that only UPDATEs clean the block is that this > > penalises only the workload making the mess, rather than everybody > > cleaning up repeatedly over one mes

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

No, old database not use table plob.. only primary key -- -- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema: public; Owner: postgres; Tablespace: -- -- For binary upgrade, must preserve pg_class oids SELECT binary_upgrade.set_next_index_pg_class_oid('786665369'::pg_c

Re: [HACKERS] Feature Request: pg_replication_master()

On Thursday, December 20, 2012 3:50 AM Joshua Berkus wrote: > > > It stalled because the patch author decided not to implement the > > request to detect recovery.conf in data directory, which allows > > backwards compatibility. > > Well, I don't think we had agreement on how important backwards >

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

On Wed, Dec 19, 2012 at 10:35:11PM -0500, Bruce Momjian wrote: > > There is another table "ВерсияВнешнегоДокумента$Документ" (without ^lob.) > > It is referenced by a foreign key > > ("rlob.ВерсияВнешнегоДокумента$Документ-@Файл") > > But as I understand it, the problem with the primary key. > >

Re: [HACKERS] Set visibility map bit after HOT prune

On Thu, Dec 20, 2012 at 6:12 AM, Robert Haas wrote: > On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee > wrote: >> This can be handled by breaking 1-to-1 mapping on VM bit and >> PD_ALL_VISIBLE bit. So seq scans will only look at PD_ALL_VISIBLE. It >> was proposed by Andres up thread, but shot do

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

On Wed, Dec 19, 2012 at 01:51:08PM +0400, Groshev Andrey wrote: > > > > Can you post the full definition of the table on this public email list? > > Also, why did the error think this was in the public schema?  Any idea? > > > > --

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

On Wed, Dec 19, 2012 at 12:56:05PM -0500, Kevin Grittner wrote: > Groshev Andrey wrote: > > > >   Mismatch of relation names: database "database", old rel > > > public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel > > > public.plob.ВерсияВнешнегоДокумента$Документ > > There is

Re: [HACKERS] Parser Cruft in gram.y

Greg Stark writes: > But I'm not entirely convinced any of this is actually useful. Just > becuase the transition table is large doesn't mean it's inefficient. That's a fair point. However, I've often noticed base_yyparse() showing up rather high on profiles --- higher than seemed plausible at t

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

On Wed, Dec 19, 2012 at 01:51:08PM +0400, Groshev Andrey wrote: > > > > Can you post the full definition of the table on this public email list? > > Also, why did the error think this was in the public schema?  Any idea? > > > > --

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 10:44 PM, Robert Haas wrote: > Yeah, that's why I don't know how to make it work. It feels like this > is partly artifact of the tool, though. I mean, suppose we haven't > read anything yet. Then, the next token can't be an IDENT, so if we > see an unreserved keyword, we

Re: [HACKERS] strange OOM errors with EXECUTE in PL/pgSQL

On 20.12.2012 02:29, Tom Lane wrote: > Tomas Vondra writes: >> What it does: > >> 1) creates a simple table called "test" with one text column. > >> 2) creates a plpgsql function with one parameter, and all that function >>does is passing the parameter to EXECUTE > >> 3) calls the function

[HACKERS] discarding duplicate indexes

I recently came across a scenario like this (tested on git head): CREATE TABLE test (id int); CREATE INDEX test_idx1 ON test (id); CREATE INDEX test_idx2 ON test (id); CREATE TABLE test_copycat (LIKE test INCLUDING ALL); \d test_copycat Why do we end up with only one index on test_copy

Re: [HACKERS] PATCH: optimized DROP of multiple tables within a transaction

On 19.12.2012 02:18, Andres Freund wrote: > On 2012-12-17 00:31:00 +0100, Tomas Vondra wrote: > > I think except of the temp buffer issue mentioned below its ready. > >> -DropRelFileNodeAllBuffers(RelFileNodeBackend rnode) >> +DropRelFileNodeAllBuffers(RelFileNodeBackend * rnodes, int nnodes) >>

Re: [HACKERS] strange OOM errors with EXECUTE in PL/pgSQL

Tomas Vondra writes: > What it does: > 1) creates a simple table called "test" with one text column. > 2) creates a plpgsql function with one parameter, and all that function >does is passing the parameter to EXECUTE > 3) calls the function with a string containing many INSERTs into the >

[HACKERS] operator dependency of commutator and negator, redux

Bug #7758 seems to be a rediscovery of the behavior that Itagaki-san complained of a couple years ago: http://archives.postgresql.org/pgsql-hackers/2010-09/msg02035.php While reconsidering the various not-too-satisfactory fixes we thought of back then, I had a sudden thought. Instead of having a

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs wrote: > The benefit of saying that only UPDATEs clean the block is that this > penalises only the workload making the mess, rather than everybody > cleaning up repeatedly over one messy guy. Right, but there are plenty of situations where having ever

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee wrote: > This can be handled by breaking 1-to-1 mapping on VM bit and > PD_ALL_VISIBLE bit. So seq scans will only look at PD_ALL_VISIBLE. It > was proposed by Andres up thread, but shot down by Tom and Simon. But > I still feel that was over reacti

Re: [HACKERS] Feature Request: pg_replication_master()

On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs wrote: > As ever, we spent much energy on debating backwards compatibility > rather than just solving the problem it posed, which is fairly easy to > solve. I'm still of the opinion (as were a lot of people on the previous thread, IIRC) that just makin

Re: [HACKERS] Review of Row Level Security

On Wed, Dec 19, 2012 at 1:58 PM, Simon Riggs wrote: > If we don't enforce rules on INSERT the user has to specifically add a > trigger, which makes things noticeably slower. There is more > maintenance work for the average user, less performance and more > mistakes to make. Well, again, only if t

Re: [HACKERS] Review of Row Level Security

On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs wrote: > I can see a use case for not having security apply for users who have > *only* INSERT privilege. This would allow people to run bulk loads of > data into a table with row security. We should add that. That is not > the common case, so with pro

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

On Tue, Dec 18, 2012 at 7:03 PM, Josh Berkus wrote: > 2. should we warn the user, or refuse to start up? One nice property of allowing cyclicity is that it's easier to syndicate application of WAL to a series of standbys before promotion of exactly one to act as a primary (basically, to perform c

Re: [HACKERS] system administration functions with hardcoded superuser checks

Tomas Vondra writes: > On 19.12.2012 07:34, Magnus Hagander wrote: >> Granting executability on pg_read_xyz is pretty darn close to granting >> superuser, without explicitly asking for it. Well, you get "read only >> superuser". If we want to make that step as easy as just GRANT, we >> really need

Re: [HACKERS] Set visibility map bit after HOT prune

On Thu, Dec 20, 2012 at 5:05 AM, Simon Riggs wrote: > > > And those last things are being debated hotly. We definitely need to > ask whether the way things are now can be tweaked to be better. The > major mechanics need not be reviewed, but the tradeoffs and balances? > Definitely. > I have zero

Re: [HACKERS] Set visibility map bit after HOT prune

On Thu, Dec 20, 2012 at 12:22 AM, Tom Lane wrote: > Pavan Deolasee writes: > > >> What if we wrap that into the WAL generated by HOT prune itself ? > > What WAL? The case we're worried about here is that there's nothing > else for HOT prune to do. > Does such a case exist ? Or at least, is it t

Re: [HACKERS] Set visibility map bit after HOT prune

On 19 December 2012 17:26, Pavan Deolasee wrote: > We definitely > made great progress by having HOT Yes, definitely. Great work. That is not for debate. > But I think generally HOT made great difference to the > system as a whole, may be at a cost of slowdown for some read-only, > select queri

Re: [HACKERS] Enabling Checksums

On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote: > > 4. We need some general performance testing to show whether this is > > insane or not. I ran a few tests. Test 1 - find worst-case overhead for the checksum calculation on write: fsync = off bgwriter_lru_maxpages = 0 shared_buffer

Re: [HACKERS] Feature Request: pg_replication_master()

On 19 December 2012 22:19, Joshua Berkus wrote: > >> It stalled because the patch author decided not to implement the >> request to detect recovery.conf in data directory, which allows >> backwards compatibility. > > Well, I don't think we had agreement on how important backwards compatibility >

Re: [HACKERS] Feature Request: pg_replication_master()

> This sounds like my previous suggestion of returning the primary > conninfo value, but with just ip. That one came with a pretty bad > patch, and was later postponed until we folded recovery.conf into > the main configuration file parsing. I'm not really sure what > happened to that project? (th

Re: [HACKERS] Feature Request: pg_replication_master()

> It stalled because the patch author decided not to implement the > request to detect recovery.conf in data directory, which allows > backwards compatibility. Well, I don't think we had agreement on how important backwards compatibility for recovery.conf was, particularly not on the whole reco

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

Simon, > My logic is that if you make a 1 minute test you will notice your > mistake, which is glaringly obvious. That is sufficient to prevent > that mistake, IMHO. What would such a test look like? It's not obvious to me that there's any rapid way for a user to detect this situation, without

[HACKERS] strange OOM errors with EXECUTE in PL/pgSQL

Hi, one of our local users reported he's getting OOM errors on 9.2, although on 9.1 the code worked fine. Attached is a simple test-case that should give you an OOM error almost immediately. What it does: 1) creates a simple table called "test" with one text column. 2) creates a plpgsql functio

Re: [HACKERS] Review of Row Level Security

On 2012-12-19 18:25, Robert Haas wrote: On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote: postgres=> INSERT INTO t1 VALUES (4,'ddd'); INSERT 0 1 postgres=> INSERT INTO t1 VALUES (5,'eee'); ERROR: new row for relation "t1" violates row-secirity DETAIL: Failing row contains (5, eee). I've a

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > Kevin Grittner wrote: > >> I hope we can leave the syntax for this feature open to such >> specification, even if the initial implementation only supports >> limiting reads. > > Well, I hope the opposite: that we can support simple full security by > default, while leaving s

Re: [HACKERS] system administration functions with hardcoded superuser checks

On 19.12.2012 07:34, Magnus Hagander wrote: > On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra wrote: >> On 18.12.2012 18:38, Pavel Stehule wrote: >>> 2012/12/18 Peter Eisentraut : There are some system administration functions that have hardcoded superuser checks, specifically: p

Re: [HACKERS] too much pgbench init output

On 19.12.2012 06:30, Jeevan Chalke wrote: > > > > On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra > wrote: > > Hi, > > attached is a new version of the patch that > > (a) converts the 'log_step_seconds' variable to a constant (and does > not allow chan

Re: [HACKERS] Review of Row Level Security

On 19 December 2012 20:37, Kevin Grittner wrote: > Andres Freund wrote: > >> I don't think it is that simple. Allowing inserts without regard for row >> level restrictions makes it far easier to probe for data. E.g. by >> inserting rows and checking for unique violations. > > Unless you want to go

Re: [HACKERS] Review of Row Level Security

> > The more secure behavior is to allow entry of data which will not be > > visible by the person doing the entry. > > I don't think it is that simple. Allowing inserts without regard for row level > restrictions makes it far easier to probe for data. E.g. by inserting rows and > checking for uni

Re: [HACKERS] Review of Row Level Security

On 19 December 2012 20:23, Kevin Grittner wrote: > I hope we can leave the syntax for this feature open to such > specification, even if the initial implementation only supports > limiting reads. Well, I hope the opposite: that we can support simple full security by default, while leaving syntax

Re: [HACKERS] Review of Row Level Security

Andres Freund wrote: > I don't think it is that simple. Allowing inserts without regard for row > level restrictions makes it far easier to probe for data. E.g. by > inserting rows and checking for unique violations. Unless you want to go to a military-style security level system where people at

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > I've argued that row security should apply to ALL commands by default. > Which is exactly the same default as Oracle, as well as being the > obvious common sense understanding of "row security", which does not > cause a POLA violation. > > I have no objection to an option to

Re: [HACKERS] Review of Row Level Security

On 2012-12-19 14:46:18 -0500, Kevin Grittner wrote: > Simon Riggs wrote: > > > This is security, not spec compliance. By default, we need full > > security. > > But you are arguing that users should not be able to make something > secure if they, and everyone with the same permissions, could not >

Re: [HACKERS] Review of Row Level Security

On 19 December 2012 19:46, Kevin Grittner wrote: > But you are arguing that users should not be able to make something > secure if they, and everyone with the same permissions, could not > later access it. Not exactly, no. I've argued that row security should apply to ALL commands by default. W

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > This is security, not spec compliance. By default, we need full > security. But you are arguing that users should not be able to make something secure if they, and everyone with the same permissions, could not later access it. I thought about situations where I've seen a need

Re: [HACKERS] FDW: ForeignPlan and parameterized paths

Ronan Dunklau writes: > I've noticed that, when implementing a FDW, it is difficult to use a plan > which > best path is a parameterized path. This comes from the fact that the > parameterized clause is not easily available at plan time. > This is what I understood from how it works: > - The

Re: [HACKERS] Review of Row Level Security

On 19 December 2012 18:40, Tom Lane wrote: > Robert Haas writes: >> On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote: >>> postgres=> INSERT INTO t1 VALUES (4,'ddd'); >>> INSERT 0 1 >>> postgres=> INSERT INTO t1 VALUES (5,'eee'); >>> ERROR: new row for relation "t1" violates row-secirity >>>

Re: [HACKERS] Set visibility map bit after HOT prune

Pavan Deolasee writes: > On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane wrote: >> If we start generating a lot of useless WAL activity and I/O as >> a result of thrashing the all-visible bit, it won't be so tolerable >> anymore. > What if we wrap that into the WAL generated by HOT prune itself ? Wha

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

"Kevin Grittner" writes: > Groshev Andrey wrote: >   Mismatch of relation names: database "database", old rel > public.lob.ВерсияВнешнегоДокумента$Документ_pkey, > new rel > public.plob.ВерсияВнешнегоДокумента$Документ > There is a

Re: [HACKERS] Review of Row Level Security

Robert Haas writes: > On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote: >> postgres=> INSERT INTO t1 VALUES (4,'ddd'); >> INSERT 0 1 >> postgres=> INSERT INTO t1 VALUES (5,'eee'); >> ERROR: new row for relation "t1" violates row-secirity >> DETAIL: Failing row contains (5, eee). > I've argu

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

Groshev Andrey wrote: > >   Mismatch of relation names: database "database", old rel > > public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel > > public.plob.ВерсияВнешнегоДокумента$Документ There is a limit on identifiers of 63 *bytes* (not characters) after which the name is

Re: [HACKERS] Review of Row Level Security

On 19 December 2012 17:25, Robert Haas wrote: > On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote: >> postgres=> INSERT INTO t1 VALUES (4,'ddd'); >> INSERT 0 1 >> postgres=> INSERT INTO t1 VALUES (5,'eee'); >> ERROR: new row for relation "t1" violates row-secirity >> DETAIL: Failing row conta

Re: [HACKERS] Switching timeline over streaming replication

Heikki, The next time I get the issue, and I'm not paying for 5 cloud servers by the hour, I'll give you a login. --Josh - Original Message - > On 19.12.2012 17:27, Heikki Linnakangas wrote: > > On 19.12.2012 15:55, Heikki Linnakangas wrote: > >> On 19.12.2012 04:57, Josh Berkus wrote:

Re: [HACKERS] Set visibility map bit after HOT prune

On 19 December 2012 16:21, Tom Lane wrote: > Robert Haas writes: >> On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane wrote: >>> Maybe it's time to look at what it'd take for the low-level scan >>> operations to know whether they're scanning the target relation of >>> an UPDATE query, so that we could s

Re: [HACKERS] Switching timeline over streaming replication

Heikki, > The problem goes away after some time, after the 1st standby has > streamed the contents of 00020003 and written it to > disk, and the cascaded standby reconnects. But it would be nice to > avoid > that situation. I'm not sure how to do that yet, we might need to > track

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 10:40 PM, Robert Haas wrote: > On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee > wrote: >> Also, if extra WAL-logging is really worrisome, may be we should again >> seriously reconsider my idea of *not* clearing the bit at HOT update. >> My apologies for repeating myself.

Re: [HACKERS] Review of Row Level Security

On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai wrote: > postgres=> INSERT INTO t1 VALUES (4,'ddd'); > INSERT 0 1 > postgres=> INSERT INTO t1 VALUES (5,'eee'); > ERROR: new row for relation "t1" violates row-secirity > DETAIL: Failing row contains (5, eee). I've argued against this before - and m

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

Andrew Dunstan writes: > what is even worse is that this procedure doesn't take any care at all > of the ordering rule for even numbered enum oids. Good point. You really should use ALTER TYPE ADD VALUE, on versions where that's available. regards, tom lane -- Sent v

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee wrote: > Also, if extra WAL-logging is really worrisome, may be we should again > seriously reconsider my idea of *not* clearing the bit at HOT update. > My apologies for repeating myself. But that seems very important in a > steady system when almo

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

On 12/19/2012 12:34 AM, Simon Riggs wrote: My logic is that if you make a 1 minute test you will notice your mistake, which is glaringly obvious. That is sufficient to prevent that mistake, IMHO. If you don't test your config and don't monitor either, good luck with HA. I am not arguing whet

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

On 12/19/2012 11:31 AM, Tom Lane wrote: enum_add is all right as long as you are careful to commit its transaction before inserting the new value anywhere. It's not really all right for post-9.0 versions. For example, this is wrong: --postgres 9.2 or higher

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane wrote: > If we start generating a lot of useless WAL activity and I/O as > a result of thrashing the all-visible bit, it won't be so tolerable > anymore. What if we wrap that into the WAL generated by HOT prune itself ? Would that address your concerns f

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

Andres Freund writes: > On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote: >> Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more >> or less changed enum_add and enum_del (Which are appended at the end) to be >> able to change enums within transactions. > That explains

Re: [HACKERS] Set visibility map bit after HOT prune

Robert Haas writes: > On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane wrote: >> Maybe it's time to look at what it'd take for the low-level scan >> operations to know whether they're scanning the target relation of >> an UPDATE query, so that we could skip pruning altogether except >> when a HOT update

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

On 12/19/2012 10:56 AM, Andres Freund wrote: On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote: Hello again, well, still everything is working. What information do you need to get into this issue? Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more or less changed

[HACKERS] ThisTimeLineID in checkpointer and bgwriter processes

In both checkpointer.c and bgwriter.c, we do this before entering the main loop: /* * Use the recovery target timeline ID during recovery */ if (RecoveryInProgress()) ThisTimeLineID = GetRecoveryTargetTLI(); That seems reasonable. However, since

Re: [HACKERS] Set visibility map bit after HOT prune

On Wed, Dec 19, 2012 at 8:32 PM, Robert Haas wrote: > On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane wrote: >> On the other hand, the HOT prune operation itself is worthless when >> we're running a SELECT. The only reason we do it that way is that we >> have to prune before the query starts to use th

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote: > Hello again, > > well, still everything is working. > > What information do you need to get into this issue? > > Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more > or less changed enum_add and enum_del (Which are app

Re: [HACKERS] [ADMIN] Problems with enums after pg_upgrade

Hello again, well, still everything is working. What information do you need to get into this issue? Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more or less changed enum_add and enum_del (Which are appended at the end) to be able to change enums within transactions.

Re: [HACKERS] Switching timeline over streaming replication

On 19.12.2012 17:27, Heikki Linnakangas wrote: On 19.12.2012 15:55, Heikki Linnakangas wrote: On 19.12.2012 04:57, Josh Berkus wrote: Heikki, I ran into an unexpected issue while testing. I just wanted to fire up a chain of 5 replicas to see if I could connect them in a loop. However, I ran in

Re: [HACKERS] Switching timeline over streaming replication

On 19.12.2012 15:55, Heikki Linnakangas wrote: On 19.12.2012 04:57, Josh Berkus wrote: Heikki, I ran into an unexpected issue while testing. I just wanted to fire up a chain of 5 replicas to see if I could connect them in a loop. However, I ran into a weird issue when starting up "r3": it refus

[HACKERS] Documentation bug for LDAP authentication

While playing with LDAP authentication, I discovered two documentation bugs. First, user and password for the first step in the two-step authentication mode are "ldapbinddn" and "ldapbindpasswd", not "ldapbinduser" and "ldapbinddn". This bug has been there since 8.4. The second one is new in 9.3

Re: [HACKERS] Set visibility map bit after HOT prune

On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane wrote: > On the other hand, the HOT prune operation itself is worthless when > we're running a SELECT. The only reason we do it that way is that we > have to prune before the query starts to use the page, else pruning > might invalidate pointers-to-tuples

[HACKERS] FDW: ForeignPlan and parameterized paths

Hello. I've noticed that, when implementing a FDW, it is difficult to use a plan which best path is a parameterized path. This comes from the fact that the parameterized clause is not easily available at plan time. This is what I understood from how it works: - The clauses coming from the be

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

On Tue, Dec 18, 2012 at 5:05 PM, Jeff Janes wrote: Sorry for the malformed and duplicate post. I was not trying to be emphatic; I was testing out gmail offline. Clearly the test didn't go too well. Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote: > Robert Haas writes: > > And on the other hand, if you could get a clean split between the two > > grammars, then regardless of exactly what the split was, it might seem > > a win. But it seemed to me when I looked at this that yo

Re: [HACKERS] Switching timeline over streaming replication

On 19.12.2012 04:57, Josh Berkus wrote: Heikki, I ran into an unexpected issue while testing. I just wanted to fire up a chain of 5 replicas to see if I could connect them in a loop. However, I ran into a weird issue when starting up "r3": it refused to come out of "the database is starting up"

Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore

On Wed, Dec 19, 2012 at 12:22 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane wrote: >>> This is definitely not per make's contract, either. I think maybe the >>> "Don't rebuild the list if only the OBJS have changed" hack in common.mk >>> is a brick or tw

Re: [HACKERS] [WIP] pg_ping utility

On Wed, Dec 12, 2012 at 12:06 AM, Bruce Momjian wrote: > On Sat, Dec 8, 2012 at 08:59:00AM -0500, Phil Sorber wrote: > > On Sat, Dec 8, 2012 at 7:50 AM, Michael Paquier > > wrote: > > > > > > Bruce mentionned that pg_isready could be used directly by pg_ctl -w. > > > Default as being non-verbos

Re: [HACKERS] configure.in and setproctitle/optreset problem

Re: Tom Lane 2012-12-18 <8705.1355845...@sss.pgh.pa.us> > > The correct fix, IMO/IIRC, is to add LDFLAGS=-Wl,--as-needed before > > running most of the configure checks, instead of after. > > Meh. It's not clear to me at all that that fixes the issue here, > or at least that it does so in any way

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

> > Can you post the full definition of the table on this public email list? > Also, why did the error think this was in the public schema?  Any idea? > > --- > >>  18.12.2012, 19:38, "Bruce Momjian" : >>>  On Mon, Dec 17, 2012

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

On 19 December 2012 08:11, Joshua D. Drake wrote: > > On 12/18/2012 11:57 PM, Simon Riggs wrote: >> >> >> On 19 December 2012 03:03, Josh Berkus wrote: >> >>> So, my question is: >>> >>> 1. should we detect for replication cycles? *Can* we? >>> 2. should we warn the user, or refuse to start up?

Re: [HACKERS] Cascading replication: should we detect/prevent cycles?

On 12/18/2012 11:57 PM, Simon Riggs wrote: On 19 December 2012 03:03, Josh Berkus wrote: So, my question is: 1. should we detect for replication cycles? *Can* we? 2. should we warn the user, or refuse to start up? Why not just monitor the config you just created? Anybody that actually te

Re: [HACKERS] system administration functions with hardcoded superuser checks

On 19 December 2012 06:34, Magnus Hagander wrote: > Granting executability on pg_read_xyz is pretty darn close to granting > superuser, without explicitly asking for it. Well, you get "read only > superuser". If we want to make that step as easy as just GRANT, we > really need to write some *very

Re: [HACKERS] proposal - assign result of query to psql variable

2012/12/19 Shigeru Hanada : > On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule > wrote: >> Attached updated patch > > Seems fine. I'll mark this as "ready for committer". > > Nice work! thank you very much Regards Pavel > > -- > Shigeru HANADA -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Feature Request: pg_replication_master()

On 19 December 2012 06:10, Magnus Hagander wrote: > This sounds like my previous suggestion of returning the primary conninfo > value, but with just ip. That one came with a pretty bad patch, and was > later postponed until we folded recovery.conf into the main configuration > file parsing. I'm n