Re: [HACKERS] Disabled features on Hot Standby

On Sat, Jan 14, 2012 at 12:42:02AM -0500, Robert Haas wrote: > On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch wrote: > > Simon spoke to the FPI side of the question. ?For heap pages, the > > XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET > > TABLESPACE. ?For the last, we wil

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 12:18 PM, Simon Riggs wrote: > On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas wrote: >> Also, what happens if an all-visible bit gets set on the standby >> through some other mechanism - e.g. restored from an FPI or >> XLOG_HEAP_NEWPAGE?  I'm not sure whether we ever do an F

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch wrote: > Simon spoke to the FPI side of the question.  For heap pages, the > XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET > TABLESPACE.  For the last, we will have already logged any PD_ALL_VISIBLE bits > through normal channe

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 5:37 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> Well, I disagree.  The fact that all-visible info can't be trusted in >> standby mode is a problem that has existed since Hot Standby was >> committed, and I don't feel obliged to fix it just because I was >> involv

[HACKERS] Speed dblink using alternate libpq tuple storage

One patch that fell off the truck during a turn in the November CommitFest was "Allow substitute allocators for PGresult". Re-reading the whole thing again, it actually turned into a rather different submission in the middle, and I know I didn't follow that shift correctly then. I'm replying

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 12:08:05PM -0500, Robert Haas wrote: > On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs wrote: > > Many WAL records have latestRemovedXid on them. We can use the same > > idea with XLOG_HEAP2_VISIBLE records, so we add a field to send the > > latest vacrelstats->latestRemovedX

Re: [HACKERS] Command Triggers

On Friday, January 13, 2012 11:53:32 PM Dimitri Fontaine wrote: > Andres Freund writes: > > I personally think this is an error and those details should at least be > > available on the c level (e.g. some pg_command_trigger_get_plan() > > function, only available via C) to allow sensible playing a

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> However, I wonder what use-case led you to file bug #6123 to begin >> with. > [ details ] > Hopefully this answers your question. I went looking for details on > particular failures here, but didn't have luck with so far. I can > try again if mor

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Fri, Jan 13, 2012 at 16:07, Andrew Dunstan wrote: > > > On 01/12/2012 09:28 PM, Alex Hunsaker wrote: >> >> Util.c/o not depending on plperl_helpers.h was also throwing me for a loop >> so I fixed it and SPI.c... Thoughts? > > > Basically looks good, but I'm confused by this: > >   do language p

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > In this particular example, I think it would work just as well to > do the reference-count updates in AFTER triggers, and maybe the > short answer is to tell people they have to do it like that > instead of in BEFORE triggers. I think that is quite often the right answer. >

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On 01/12/2012 09:28 PM, Alex Hunsaker wrote: Util.c/o not depending on plperl_helpers.h was also throwing me for a loop so I fixed it and SPI.c... Thoughts? Basically looks good, but I'm confused by this: do language plperl $$ elog('NOTICE', ${^TAINT}); $$; Why is NOTICE quoted here?

Re: [HACKERS] Review of: explain / allow collecting row counts without timing info

On 13.1.2012 18:07, Josh Berkus wrote: > Eric's review follows: > > Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from > 2012-01-12 git checkout. > > Patch applied fine. > > 'make check' results in failures when this patch is put into place. > > > 6 o

Re: [HACKERS] Command Triggers

Andres Freund writes: > I personally think this is an error and those details should at least be > available on the c level (e.g. some pg_command_trigger_get_plan() function, > only available via C) to allow sensible playing around with that knowledge. I > don't really see making progress towar

Re: [HACKERS] Multithread Query Planner

Christopher Browne writes: > Yes, don't try to use threads. > > > > ... threads are not currently used instead of multiple processes for

Re: [HACKERS] Standalone synchronous master

"Kevin Grittner" writes: > I'm having a hard time seeing why this is considered a feature. It > seems to me what is being proposed is a mode with no higher > integrity guarantee than asynchronous replication, but latency > equivalent to synchronous replication. I can see where it's > tempting to

Re: [HACKERS] Disabled features on Hot Standby

Robert Haas writes: > Well, I disagree. The fact that all-visible info can't be trusted in > standby mode is a problem that has existed since Hot Standby was > committed, and I don't feel obliged to fix it just because I was > involved in developing a new feature that happens to rely on I'm very

Re: [HACKERS] Command Triggers

On Monday, December 19, 2011 07:37:46 PM Robert Haas wrote: > Maybe we should try to split the baby here and defer the question of > whether to expose any of the parse tree internals, and if so how much, > to a future release. I personally think this is an error and those details should at least b

Re: [HACKERS] Command Triggers

Robert Haas writes: > Maybe we should try to split the baby here and defer the question of > whether to expose any of the parse tree internals, and if so how much, > to a future release. It seems to me that we could design a fairly > useful set of functionality around AFTER-CREATE, BEFORE-DROP, a

Re: [HACKERS] 9.3 feature proposal: vacuumdb -j #

On 1/13/12 2:12 PM, Euler Taveira de Oliveira wrote: > On 13-01-2012 18:50, Josh Berkus wrote: >> It occurs to me that I would find it quite personally useful if the >> vacuumdb utility was multiprocess capable. >> > It is in the mid of my TODO list. reindexdb is in the plans too. I'm even happier

Re: [HACKERS] 9.3 feature proposal: vacuumdb -j #

On Fri, Jan 13, 2012 at 4:50 PM, Josh Berkus wrote: > It occurs to me that I would find it quite personally useful if the > vacuumdb utility was multiprocess capable. > > For example, just today I needed to manually analyze a database with > over 500 tables, on a server with 24 cores.   And I need

Re: [HACKERS] 9.3 feature proposal: vacuumdb -j #

On 13-01-2012 18:50, Josh Berkus wrote: > It occurs to me that I would find it quite personally useful if the > vacuumdb utility was multiprocess capable. > It is in the mid of my TODO list. reindexdb is in the plans too. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br

Re: [HACKERS] 9.3 feature proposal: vacuumdb -j #

On Friday, January 13, 2012 10:50:32 PM Josh Berkus wrote: > Hackers, > > It occurs to me that I would find it quite personally useful if the > vacuumdb utility was multiprocess capable. > > For example, just today I needed to manually analyze a database with > over 500 tables, on a server with 2

Re: [HACKERS] 9.3 feature proposal: vacuumdb -j #

Am 13.01.2012 22:50, schrieb Josh Berkus: It occurs to me that I would find it quite personally useful if the vacuumdb utility was multiprocess capable. For example, just today I needed to manually analyze a database with over 500 tables, on a server with 24 cores. And I needed to know when th

Re: [HACKERS] Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas wrote: > On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina wrote: >> Hmm, just to prod this thread: has any fix for this been committed? >> After Nikhil confirmed that this bug could cause pg_dump to not be >> able to operate without direct catalog surge

[HACKERS] 9.3 feature proposal: vacuumdb -j #

Hackers, It occurs to me that I would find it quite personally useful if the vacuumdb utility was multiprocess capable. For example, just today I needed to manually analyze a database with over 500 tables, on a server with 24 cores. And I needed to know when the analyze was done, because it was

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > What do you think of > > ERROR: tuple to be updated was already modified by an operation > triggered by the UPDATE command > HINT: Consider using an AFTER trigger instead of a BEFORE trigger > to propagate changes to other rows. > > (s/update/delete/ for the DELETE case of co

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > I'm also fine with generating an error for such dirty tricks, and I > agree that if that's indeed possible we should make the message > general enough to cover that case. Nothing comes to mind at the > moment, but I'll think on it. What do you think of ERROR: tuple to

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> I'm not sure what to do about this. If we throw an error there, >> there will be no way that the trigger can override the error >> because it will never get to run. Possibly we could plow ahead >> with the expectation of throwing an error later if t

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: [rearranging so results directly follow statements] > select * from test; > id | parent | data | nchildren > ++--+--- > 2 | 1 | root child A | 1 > 4 | 2 | grandchild 1 | 0 > 3 | 1 | root child B |

Re: [HACKERS] Multithread Query Planner

On Fri, Jan 13, 2012 at 3:14 PM, Frederico wrote: > Hi folks. > > Is there any restriction in create and start threads inside Postgres? > > I'm trying to develop a multithread planner, and some times is raised a > exception of access memory. > > I'm debugging the code to see if is a bug in the pl

[HACKERS] Multithread Query Planner

Hi folks. Is there any restriction in create and start threads inside Postgres? I'm trying to develop a multithread planner, and some times is raised a exception of access memory. I'm debugging the code to see if is a bug in the planner, but until now, I still not found. I tried to use the sa

Re: [HACKERS] reprise: pretty print viewdefs

On 01/13/2012 12:31 AM, Hitoshi Harada wrote: So my conclusion is it's better than nothing, but we could do better job here. From timeline perspective, it'd be ok to apply this patch and improve more later in 9.3+. I agree, let's look at the items other than the target list during 9.3.

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > I worked over this patch a bit, mostly cosmetically; updated > version attached. Thanks! > However, we're not there yet. I have a couple of remaining > concerns: > > 1. I think the error message needs more thought. I believe it's > possible to trigger this error not only

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> 3. I modified heap_lock_tuple to also return a >> HeapUpdateFailureData, principally on the grounds that its API >> should be largely parallel to heap_update, but having done that I >> can't help wondering whether its callers are okay with skipping >>

Re: [HACKERS] Standalone synchronous master

Jeff Janes wrote:\ > I don't understand why this is controversial. I'm having a hard time seeing why this is considered a feature. It seems to me what is being proposed is a mode with no higher integrity guarantee than asynchronous replication, but latency equivalent to synchronous replicatio

Re: [HACKERS] read transaction and sync rep

On Fri, Jan 13, 2012 at 3:44 AM, Simon Riggs wrote: > On Fri, Jan 13, 2012 at 11:30 AM, Fujii Masao wrote: > >> I found that even read transaction waits for sync rep when it generates >> WAL records even if XID is not assigned. For example, imagine the case >> where SELECT query does a heap clean

Re: [HACKERS] Standalone synchronous master

Jeff Janes writes: > I don't understand why this is controversial. In the current code, if > you have a master and a single sync standby, and the master disappears > and you promote the standby, now the new master is running *without a > standby*. If you configured it to use sync rep, it won't a

Re: [HACKERS] Standalone synchronous master

On Fri, Jan 13, 2012 at 2:30 AM, Alexander Björnhagen wrote: > At this point I feel that this new functionality might be a bit > overkill for postgres, maybe it's better to stay lean and mean rather > than add a controversial feature like this. I don't understand why this is controversial. In th

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > You were right. One of the isolation tests failed an assertion; > things pass with the attached change, setting the cmax > conditionally. Some comments updated. I hope this is helpful. I worked over this patch a bit, mostly cosmetically; updated version attached. Ho

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas wrote: > Also, what happens if an all-visible bit gets set on the standby > through some other mechanism - e.g. restored from an FPI or > XLOG_HEAP_NEWPAGE?  I'm not sure whether we ever do an FPI of the > visibility map page itself, but we certainly d

Re: [HACKERS] checkpoint writeback via sync_file_range

On Thu, Jan 12, 2012 at 7:26 PM, Greg Smith wrote: > On 1/11/12 9:25 AM, Andres Freund wrote: >> >> The heavy pressure putting it directly in the writeback queue >> leads to less efficient io because quite often it won't reorder sensibly >> with >> other io anymore and thelike. At least that was m

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs wrote: > I think it should be you that comes up with a fix, not for me to > respond to your concerns about how hard it is. Many things that don't > fully work are rejected for that reason. Well, I disagree. The fact that all-visible info can't be tru

[HACKERS] Review of: explain / allow collecting row counts without timing info

Eric's review follows: Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from 2012-01-12 git checkout. Patch applied fine. 'make check' results in failures when this patch is put into place. 6 of 128 tests failed. Here are the re

Re: [HACKERS] Postgres ReviewFest Patch: URI connection string support for libpq

> There's some more details about this at > http://wiki.postgresql.org/wiki/Running_a_CommitFest , which we don't > expect everyone to know because it isn't one of the popular pages to > read. I've sorted out the problem for this one already, just letting > whoever made that change know about the

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

Robert Haas writes: > So here's a 5-line patch that adds the number of heap fetches to the > EXPLAIN ANALYZE output. This might not be all the instrumentation > we'll ever want here, but I think we at least want this much. Cosmetic gripes: 1. Please initialize the counter in ExecInitIndexOnlySc

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 3:22 PM, Robert Haas wrote: > On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs wrote: >> On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote: >> >>> Since the xmin horizon on the standby may precede the xmin horizon on >>> the master >> >> When hot_standby_feedback is turned

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

On Fri, Jan 13, 2012 at 10:41 AM, Peter Geoghegan wrote: > On 13 January 2012 15:31, Robert Haas wrote: >> On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander >> wrote: >>> Would also be good to have counter sin pg_stat_* for this, since you'd >>> usually want to look at this kind of data over ti

Re: [HACKERS] TG_DEPTH patch v1

[reviving discussion of another old patch] In post: http://archives.postgresql.org/pgsql-hackers/2011-06/msg00870.php Florian Pflug wrote: > Updated patch attached. Thanks. > The trigger depth is incremented before calling the trigger > function in ExecCallTriggerFunc() and decremented

Re: [HACKERS] Text comparison suddenly can't find collation?

"Johann 'Myrkraverk' Oskarsson" writes: > Why would a string comparison work in one case and not another? In > the following example, it works to compare a and b, but not a and d. > This is in a C module which calls > DirectFunctionCall2( text_le, d1, d2 ); As of 9.1, I'd expect that coding t

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

On 13 January 2012 15:31, Robert Haas wrote: > On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander wrote: >> Would also be good to have counter sin pg_stat_* for this, since you'd >> usually want to look at this kind of data over time as well. In your >> plans? ;) > > Not really.  I don't have a cl

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 10:31 AM, Jim Nasby wrote: > Perhaps it would be possible to keep older copies of pages around when there > are older transactions running on the standby? I've thought about that... it's basically a rollback segment, which for that matter might be judged superior to what

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander wrote: > On Fri, Jan 13, 2012 at 16:21, Robert Haas wrote: >> I think that people who are using index-only scans are going to want >> some way to find out the degree to which the scans are in fact >> index-only. >> >> So here's a 5-line patch that

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

On 13 January 2012 15:21, Robert Haas wrote: > I think that people who are using index-only scans are going to want > some way to find out the degree to which the scans are in fact > index-only. > > So here's a 5-line patch that adds the number of heap fetches to the > EXPLAIN ANALYZE output.  Thi

Re: [HACKERS] Disabled features on Hot Standby

On Jan 13, 2012, at 8:03 AM, Robert Haas wrote: > Or, > we could try to lift this restriction in the special case when > hot_standby_feedback is set, though I have a feeling that's not really > robust - any time you lose the connection to the master, it'll lose > your xmin holdback and possibly mar

Re: [HACKERS] show Heap Fetches in EXPLAIN for index-only scans

On Fri, Jan 13, 2012 at 16:21, Robert Haas wrote: > I think that people who are using index-only scans are going to want > some way to find out the degree to which the scans are in fact > index-only. > > So here's a 5-line patch that adds the number of heap fetches to the > EXPLAIN ANALYZE output.

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs wrote: > On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote: > >> Since the xmin horizon on the standby may precede the xmin horizon on >> the master > > When hot_standby_feedback is turned on, the xmin of the standby is > provided to the master to en

[HACKERS] show Heap Fetches in EXPLAIN for index-only scans

I think that people who are using index-only scans are going to want some way to find out the degree to which the scans are in fact index-only. So here's a 5-line patch that adds the number of heap fetches to the EXPLAIN ANALYZE output. This might not be all the instrumentation we'll ever want he

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote: > Since the xmin horizon on the standby may precede the xmin horizon on > the master When hot_standby_feedback is turned on, the xmin of the standby is provided to the master to ensure the situation you describe never happens. Surely that mean

Re: [HACKERS] Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 8:27 AM, Simon Riggs wrote: > The open items list for 9.2 says > > "Index-only scans need to be disabled when running under Hot Standby" > > There is no explanation, so please explain here so we can change it, > if possible. > > Not sure its great policy to keep implementin

Re: [HACKERS] Patch to allow users to kill their own queries

On Fri, Jan 13, 2012 at 14:42, Greg Smith wrote: > On 01/03/2012 12:59 PM, Tom Lane wrote: >> >> Noah Misch  writes: >> >>> >>> Regarding the other message, avoid composing a translated message from >>> independently-translated parts. >>> >> >> Yes.  I haven't looked at the patch, but I wonder whe

Re: [HACKERS] Patch to allow users to kill their own queries

On 01/03/2012 12:59 PM, Tom Lane wrote: Noah Misch writes: Regarding the other message, avoid composing a translated message from independently-translated parts. Yes. I haven't looked at the patch, but I wonder whether it wouldn't be better to dodge both of these problems by having

Re: [HACKERS] Poorly thought out code in vacuum

On Fri, Jan 6, 2012 at 12:45 PM, Robert Haas wrote: > Oh, that's brilliant.  OK, I'll go try that. All right, that test does in fact reveal the broken-ness of the current code, and the patch I committed upthread does seem to fix it, so I've committed that. After further reflection, I'm thinking

Re: [HACKERS] Postgres ReviewFest Patch: URI connection string support for libpq

On 01/12/2012 11:07 PM, Nick Roosevelt wrote: Just reviewed the patch for adding URI connection string support for libpg. ...Seems like the file has changed since this patch was created. Please recreate the patch. Thanks for the review. In the CommitFest appliation, it looks like someone ma

[HACKERS] Disabled features on Hot Standby

The open items list for 9.2 says "Index-only scans need to be disabled when running under Hot Standby" There is no explanation, so please explain here so we can change it, if possible. Not sure its great policy to keep implementing things that don't work on HS, while not giving a proper chance f

Re: [HACKERS] CLONE TABLE DATA TO

This would be great, but I can't C :-( Marc > -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Freitag, 13. Januar 2012 14:12 > To: Marc Mamin > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] CLONE TABLE DATA TO > > On Fri, Jan 13, 2012 at 5:56 A

Re: [HACKERS] CLONE TABLE DATA TO

On Fri, Jan 13, 2012 at 5:56 AM, Marc Mamin wrote: > I wonder if it would be possible to have a fast table clone function (data > only) while copying the corresponding data files > > instead of using the "CREATE TABLE AS"  way. > > pg_upgrade seems to have such a mechanisms, though it requires to

Re: [HACKERS] pgbench post-connection command

There's one part of this that's still fuzzy in the spec I'd like to clarify, if nothing else than for my own memory's sake--as the person most likely to review a random pgbench patch. Simon gave an example like this: pgbench -x "SET synchronous_commit = off" All are agreed this should take

Re: [HACKERS] New replication mode: write

On Fri, Jan 13, 2012 at 12:27 PM, Fujii Masao wrote: >> In my patch, the reason I avoided doing WRITE mode (which we had >> previously referred to as RECV) was that no fsync of the WAL contents >> takes place. In that case we are applying changes using un-fsynced WAL >> data and in case of crash

Re: [HACKERS] New replication mode: write

On Fri, Jan 13, 2012 at 7:30 PM, Simon Riggs wrote: > On Fri, Jan 13, 2012 at 9:15 AM, Simon Riggs wrote: >> On Fri, Jan 13, 2012 at 7:41 AM, Fujii Masao wrote: >> >>> Thought? Comments? >> >> This is almost exactly the same as my patch series >> "syncrep_queues.v[1,2].patch" earlier this year.

Re: [HACKERS] read transaction and sync rep

On Fri, Jan 13, 2012 at 11:30 AM, Fujii Masao wrote: > I found that even read transaction waits for sync rep when it generates > WAL records even if XID is not assigned. For example, imagine the case > where SELECT query does a heap clean operation and generates > XLOG_HEAP2_CLEAN record. ISTM th

[HACKERS] read transaction and sync rep

Hi, I found that even read transaction waits for sync rep when it generates WAL records even if XID is not assigned. For example, imagine the case where SELECT query does a heap clean operation and generates XLOG_HEAP2_CLEAN record. ISTM that such a read transaction doesn't need to wait for sync r

Re: [HACKERS] replay_location indicates incorrect location

On Fri, Jan 13, 2012 at 10:04 AM, Fujii Masao wrote: > When I looked at pg_stat_replication just after starting the standby before > executing any write transactions on the master, I found that replay_location > indicated incorrect location different from sent/write/flush_location. Then, > if I r

[HACKERS] CLONE TABLE DATA TO

Hello, I wonder if it would be possible to have a fast table clone function (data only) while copying the corresponding data files instead of using the "CREATE TABLE AS" way. pg_upgrade seems to have such a mechanisms, though it requires to first stop the server... This would of course require t

Re: [HACKERS] Standalone synchronous master

At this point I feel that this new functionality might be a bit overkill for postgres, maybe it's better to stay lean and mean rather than add a controversial feature like this. I also agree that a more general replication timeout variable would be more useful to a larger audience but that would i

[HACKERS] replay_location indicates incorrect location

Hi, When I looked at pg_stat_replication just after starting the standby before executing any write transactions on the master, I found that replay_location indicated incorrect location different from sent/write/flush_location. Then, if I ran write transaction on the master, replay_location indica

Re: [HACKERS] Inlining comparators as a performance optimisation

On Wed, 21 Sep 2011 18:13:07 +0200, Tom Lane wrote: Heikki Linnakangas writes: On 21.09.2011 18:46, Tom Lane wrote: The idea that I was toying with was to allow the regular SQL-callable comparison function to somehow return a function pointer to the alternate comparison function, You coul

Re: [HACKERS] pgbench post-connection command

On Thu, Jan 12, 2012 at 8:04 PM, Tom Lane wrote: > Simon Riggs writes: >> On Thu, Jan 12, 2012 at 5:32 PM, Tom Lane wrote: >>> More like "\once ... any SQL command or meta command here ..." >>> if we want to extend the scripting language.  But I'd be perfectly happy >>> with a command-line switc

Re: [HACKERS] ERRCODE_READ_ONLY_SQL_TRANSACTION

On Fri, Jan 13, 2012 at 8:55 AM, Dimitri Fontaine wrote: > I felt that we were missing something simple here, but after review I > think we finally have all the pieces to achieve that with current 9.2 > code base in fact. Good, patch revoked. No time wasted, it was worth checking. --  Simon Ri

Re: [HACKERS] ERRCODE_READ_ONLY_SQL_TRANSACTION

Hi, Tom Lane writes: > Simon Riggs writes: >> Hot Standby returns ERRCODE_READ_ONLY_SQL_TRANSACTION in most cases >> for illegal actions on a standby. > > I don't think I like this patch: you are promoting what are and ought to > be very low-level internal sanity checks into user-facing errors (