Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-27 11:46:39 +0530, a...@2ndquadrant.com wrote: > > I'm trying a couple of approaches to that (e.g. using readdir directly > instead of ReadDir), but other suggestions are welcome. Here's what that looks like, but not yet fully tested. -- Abhijit diff --git a/src/backend/access/transam/

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-26 22:44:03 +0200, and...@anarazel.de wrote: > > So what I propose is: > 1) Remove the automatic symlink following > 2) Follow pg_tbspc/*, pg_xlog if it's a symlink, fix the latter in >initdb -S > 3) Add a elevel argument to walkdir(), return if AllocateDir() fails, >continue for

Re: [HACKERS] why does txid_current() assign new transaction-id?

On Tue, May 26, 2015 at 4:12 PM, Naoya Anzai wrote: > I have a question about txid_current(). > it is "Why does txid_current() assign new transaction-id?". > > When we executes txid_current() outside of transaction block, it assigns new > transaction-id. > I guess it doesn't need to assign a new

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Sat, May 23, 2015 at 8:14 PM, Noah Misch wrote: > On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote: >> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs wrote: >> > As long as the cookie is randomly generated for each use, then I don't see >> > a >> > practical problem with that approac

Re: [HACKERS] psql po translation update

> On Tue, May 26, 2015 at 8:59 PM, Tatsuo Ishii wrote: >> Here is a translation fule for src/bin/psql/ja.po of 9.4.2 from >> Kosizumi-san. According to him, there are some missing translations in >> the po file and he fixed it. Shall I commit into REL9_4_STABLE tree or >> would you like to do it y

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Fri, May 22, 2015 at 2:11 PM, Jim Nasby wrote: >> Uh, I don't have a clue what you mean when you say "the middle ground >> of not doing de-auth right now". > > Don't allow a backend to move back into a de-authenticated state. > > Basically, allow a special connection mode that does nothing but

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

"Davin M. Potts" writes: > On Mon, May 25, 2015 at 04:37:11PM -0400, Tom Lane wrote: >> I'm fairly sure that the errors were blatantly obvious, ie failure to >> build or failure to pass even basic regression tests. If you can tell >> us that that configure check is inappropriate on modern openbsd

Re: [HACKERS] psql po translation update

On Tue, May 26, 2015 at 8:59 PM, Tatsuo Ishii wrote: > Here is a translation fule for src/bin/psql/ja.po of 9.4.2 from > Kosizumi-san. According to him, there are some missing translations in > the po file and he fixed it. Shall I commit into REL9_4_STABLE tree or > would you like to do it yoursel

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On Tue, May 26, 2015 at 8:10 PM, Stephen Frost wrote: > I certainly welcome review from others and if there is not another > committer-level formal review before we get close on 9.5 (say, end of > August), then I'll revert it. There is certainly no concern that doing > so would be difficult to do

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > What do we need RowSecurityPolicy->policy_id for? It seems to me that > > > it is only used to determine whether the policy is the "default deny" > > > on

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-26 22:44:03 +0200, and...@anarazel.de wrote: > > So, this was discussed in the following thread, starting at: > http://archives.postgresql.org/message-id/20150403163232.GA28444%40eldon.alvh.no-ip.org Sorry, I didn't see this before replying. > There are no other places we it's "allowed

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-26 19:07:20 +0200, and...@anarazel.de wrote: > > Abhijit, do you recall why the code was changed to follow all symlinks > in contrast to explicitly going through the tablespaces as initdb -S > does? I'm pretty sure early versions of the patch pretty much had a > verbatim copy of the init

Re: [HACKERS] Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)

On Mon, May 25, 2015 at 5:08 AM, Kouhei Kaigai wrote: > I updated the patch to fix up this problem towards the latest master > branch. [ ... ] > Instead of this approach, Tom suggested to add a list of child Paths > on CustomPath node, then createplan.c calls create_plan_recurse() for > each entry

Re: [HACKERS] Run pgindent now?

On Tue, May 26, 2015 at 3:07 PM, Tom Lane wrote: > Robert Haas writes: >> Realistically, with merge.conflictstyle = diff3 (why is this not the >> default?), resolving whitespace conflicts that occur when you try to >> cherry-pick is typically not very difficult. > > Really? The problems I have g

[HACKERS] psql po translation update

Peter, Here is a translation fule for src/bin/psql/ja.po of 9.4.2 from Kosizumi-san. According to him, there are some missing translations in the po file and he fixed it. Shall I commit into REL9_4_STABLE tree or would you like to do it yourself? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan

Re: [HACKERS] Run pgindent now?

On 5/25/15 5:51 PM, Alvaro Herrera wrote: > Tom Lane wrote: > >> A longer-term fix would be to make pgindent less stupid about this sort >> of usage, but nobody's yet volunteered to dig into the guts of that code. > > We've discussed in the past that we could use something other than BSD's > inde

Re: [HACKERS] Run pgindent now?

On 2015-05-26 20:25:24 -0400, Peter Eisentraut wrote: > On 5/25/15 7:15 PM, Andres Freund wrote: > > On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote: > >>> A longer-term fix would be to make pgindent less stupid about this sort > >>> of usage, but nobody's yet volunteered to dig into the guts of

Re: [HACKERS] Run pgindent now?

On 5/25/15 7:15 PM, Andres Freund wrote: > On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote: >>> A longer-term fix would be to make pgindent less stupid about this sort >>> of usage, but nobody's yet volunteered to dig into the guts of that code. >> >> I assume a typedefs list is going to be a req

Re: [HACKERS] optimizing vacuum truncation scans

On Tue, May 26, 2015 at 12:37 PM, Jeff Janes wrote: > On Mon, Apr 20, 2015 at 10:18 AM, Jim Nasby > wrote: > >> On 4/20/15 1:50 AM, Jeff Janes wrote: >> >>> >>> For that matter, why do we scan backwards anyway? The comments don't >>> explain it, and we have nonempty_pages as a starting

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Noah, * Noah Misch (n...@leadboat.com) wrote: > On Thu, May 14, 2015 at 01:38:49PM -0400, Tom Lane wrote: > > * The comments in the code betray utter ignorance of how logging actually > > works, in particular this: > > > > * Administrators can choose which log level the audit log is to be logged

Re: [HACKERS] a few thoughts on the schedule

On Tue, May 19, 2015 at 10:25:49AM -0400, Robert Haas wrote: > Unfortunately, I don't have a lot of good ideas here. I know that I > spend as much time reviewing other people's patches as I can manage to > find in my schedule, and I know a lot of people would probably like to > see me do more of t

[HACKERS] Run a test instance from the source directory

Hi, I'd like to edit, compile, run, profile and debug in a loop. To do that I put pg_sleep(3600) in the regression test suite. That way I can easily change a file, 'make check', and then run some SQL from another terminal. Is there a 'better' way to run postgres after building? In a way that doe

Re: [HACKERS] about lob(idea)

El 25/05/15 a las 06:13, alex2010 escribió: > Maybe it makes sense to add ability to store large objects in the same table > space as the table. > Or an opportunity - to specify table space for a large object. > Do you have anything in todolists about it? This is something which has popped up

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

Paul Smith wrote: > In the backup, for the row which will become broken, I get: > > ctid| xmin | xmax > +--+-- > (18722,29) | 23862661 | 23862661 Okay. > Assuming it hadn't changed in the broken version (from application > knowledge, it's unlikely to c

Re: [HACKERS] Redesigning checkpoint_segments

On Thu, May 21, 2015 at 8:40 AM, Fujii Masao wrote: > On Thu, May 21, 2015 at 3:53 PM, Jeff Janes wrote: > > On Mon, Mar 16, 2015 at 11:05 PM, Jeff Janes > wrote: > >> > >> On Mon, Feb 23, 2015 at 8:56 AM, Heikki Linnakangas > >> wrote: > >>> > >>> > >>> Everyone seems to be happy with the nam

Re: [HACKERS] hstore_plpython regression test does not work on Python 3

22.05.2015, 09:44, Christian Ullrich kirjoitti: > * Peter Eisentraut wrote: >> On 5/16/15 12:06 PM, Tom Lane wrote: >>> As exhibited for instance here: >>> >>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2015-05-16%2011%3A00%3A07 >>> >>> >>> I've been able to replicate this

Re: [HACKERS] Run pgindent now?

On 2015-05-26 16:32:42 -0300, Alvaro Herrera wrote: > I've wondered a few times whether there's a way to make pgindent commits > "transparent" to git blame, i.e. blame their modified lines to whatever > commits modified them immediately before. You can make blame ignore whitespace changes with -w

Re: [HACKERS] Run pgindent now?

On Tue, May 26, 2015 at 3:07 PM, Tom Lane wrote: > Robert Haas writes: > > Realistically, with merge.conflictstyle = diff3 (why is this not the > > default?), resolving whitespace conflicts that occur when you try to > > cherry-pick is typically not very difficult. > > Really? The problems I ha

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

On 26/05/2015 19:47, Alvaro Herrera wrote: Paul Smith wrote: No, nothing like that. It was just running fine, and then suddenly (at 2am on 23 May) it started throwing up loads of these errors. The DB server wasn't even restarted at that point. It was just working fine, then suddenly wasn't. (Th

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-26 19:07:20 +0200, Andres Freund wrote: > It is somewhat interesting that similar code has been used in > pg_upgrade, via initdb -S, for a while now, without, to my knowledge, it > causing reported problem. I think the relevant difference is that that > code doesn't follow symlinks. It'

[HACKERS] why does txid_current() assign new transaction-id?

Hi,hackers! I have a question about txid_current(). it is "Why does txid_current() assign new transaction-id?". When we executes txid_current() outside of transaction block, it assigns new transaction-id. I guess it doesn't need to assign a new txid because txid_current() is just a read-only fu

Re: [HACKERS] Run pgindent now?

On 05/25/2015 05:34 PM, Tom Lane wrote: Bruce Momjian writes: On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: Something is wrong. See aclchk.c changes. Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0 and 9.1, and the use of that as a typedef in 9.4 i

Re: [HACKERS] optimizing vacuum truncation scans

On Mon, Apr 20, 2015 at 10:18 AM, Jim Nasby wrote: > On 4/20/15 1:50 AM, Jeff Janes wrote: > >> >> For that matter, why do we scan backwards anyway? The comments don't >> explain it, and we have nonempty_pages as a starting point, so why >> don't we just scan forward? I suspect that

[HACKERS] jsonb_set

Here is the latest version of the refinement of jsonb_replace into jsonb_set. All known bugs have been fixed, and the only issue is the default value of the fourth parameter. Currently it's set to false, but I gather from the previous responses that the consensus is to make it true. cheers an

Re: [HACKERS] Run pgindent now?

Robert Haas wrote: > But every time we pgindent, especially with slightly different > settings, we cause tools like 'git blame' to return less useful > answers. And that sucks. I've wondered a few times whether there's a way to make pgindent commits "transparent" to git blame, i.e. blame their m

Re: [HACKERS] Run pgindent now?

Robert Haas writes: > Realistically, with merge.conflictstyle = diff3 (why is this not the > default?), resolving whitespace conflicts that occur when you try to > cherry-pick is typically not very difficult. Really? The problems I have generally come from places where pgindent has changed the l

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

On 05/26/2015 11:47 AM, Alvaro Herrera wrote: > Paul Smith wrote: > >> No, nothing like that. It was just running fine, and then suddenly (at 2am >> on 23 May) it started throwing up loads of these errors. The DB server >> wasn't even restarted at that point. It was just working fine, then suddenl

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 5:34 PM, Tom Lane wrote: > Bruce Momjian writes: >> On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: >>> Something is wrong. See aclchk.c changes. > >> Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0 >> and 9.1, and the use of that

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

Paul Smith wrote: > No, nothing like that. It was just running fine, and then suddenly (at 2am > on 23 May) it started throwing up loads of these errors. The DB server > wasn't even restarted at that point. It was just working fine, then suddenly > wasn't. (The first error was at 02:00:32 BST, the

Re: [HACKERS] fsync bug faq for publication?

On 05/26/2015 10:57 AM, Tom Lane wrote: > Josh Berkus writes: >> Where did we get the idea that this issue only affects symlinked files? > > Nobody said any such thing. My point was that permissions and ownership > both have to be looked at. The Debian situation is that there are symlinks > in

Re: [HACKERS] fsync bug faq for publication?

Josh Berkus writes: > Where did we get the idea that this issue only affects symlinked files? Nobody said any such thing. My point was that permissions and ownership both have to be looked at. The Debian situation is that there are symlinks in $PGDATA pointing at root-owned files, and those fil

Re: [HACKERS] fsync bug faq for publication?

On 05/25/2015 11:09 PM, Magnus Hagander wrote: > > On May 26, 2015 07:31, "Tom Lane" > wrote: >> >> Josh Berkus mailto:j...@agliodbs.com>> writes: >> > We need to get a notice out to our users who might update their servers >> > and get stuck behind the fsync bug. As s

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Christoph Berg writes: > I think the OP's point was (or should have been), to make txid_current > not draw a new xid when run outside a transaction block, though it's > questionable if that wouldn't just add a POLA-violating layer. Well, the patch as proposed failed to do that, but in any case I

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Re: Tom Lane 2015-05-26 <18863.1432661...@sss.pgh.pa.us> > Christoph Berg writes: > > Still, exposing GetStableLatestTransactionId() on the SQL level would > > make sense for monitoring transaction throughput. > > Perhaps, though I wonder why we should expose that and not just report the > result

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Christoph Berg writes: > Still, exposing GetStableLatestTransactionId() on the SQL level would > make sense for monitoring transaction throughput. Perhaps, though I wonder why we should expose that and not just report the result of ReadNewTransactionId() --- or in txid.c's case, the result of Get

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Re: Tom Lane 2015-05-26 <14207.1432650...@sss.pgh.pa.us> > Naoya Anzai writes: > > I have a question about txid_current(). > > it is "Why does txid_current() assign new transaction-id?". > > Consider > > begin; > select txid_current(); > insert into my_table ...; > commit

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-26 19:07:20 +0200, Andres Freund wrote: > Abhijit, do you recall why the code was changed to follow all symlinks > in contrast to explicitly going through the tablespaces as initdb -S > does? I'm pretty sure early versions of the patch pretty much had a > verbatim copy of the initdb logi

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-26 10:41:12 -0400, Tom Lane wrote: > Yeah. Perhaps I missed it, but was the original patch motivated by > actual failures that had been seen in the field, or was it just a > hypothetical concern? I'd mentioned that it might be a good idea to do this while investingating a bug with unlo

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Andrew Dunstan writes: > On 05/26/2015 11:58 AM, Tom Lane wrote: >> One thing perhaps we *should* be selective about, though, is which >> symlinks we try to follow. I think that a good case could be made >> for ignoring symlinks everywhere except in the pg_tablespace directory. >> If we did, that

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Tue, May 26, 2015 at 6:16 PM, Andrew Dunstan wrote: > > On 05/26/2015 11:58 AM, Tom Lane wrote: > >> Andrew Dunstan writes: >> >>> OK, I'm late to the party. But why exactly are we syncing absolutely >>> everything? That seems over-broad. >>> >> If we try to be selective, we risk errors of om

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 05/26/2015 11:58 AM, Tom Lane wrote: Andrew Dunstan writes: OK, I'm late to the party. But why exactly are we syncing absolutely everything? That seems over-broad. If we try to be selective, we risk errors of omission, which no one would ever notice until someone's data got eaten in a low-

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Andrew Dunstan writes: > OK, I'm late to the party. But why exactly are we syncing absolutely > everything? That seems over-broad. If we try to be selective, we risk errors of omission, which no one would ever notice until someone's data got eaten in a low-probability crash scenario. It seems m

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

On 26/05/2015 16:01, Alvaro Herrera wrote: Paul Smith wrote: With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error: ERROR: MultiXactId 1934308693 has not been created yet -- apparent wraparound on doing various queries on our database. I don't think it is a wraparound - I think the t

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 05/26/2015 08:05 AM, Robert Haas wrote: On Mon, May 25, 2015 at 9:54 PM, Stephen Frost wrote: I certainly see your point, but Tom also pointed out that it's not great to ignore failures during this phase: * Tom Lane (t...@sss.pgh.pa.us) wrote: Greg Stark writes: What exactly is failing?

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

Paul Smith wrote: > With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error: > > ERROR: MultiXactId 1934308693 has not been created yet -- apparent > wraparound > > on doing various queries on our database. I don't think it is a wraparound - > I think the tuple has mistakenly decided it has

Re: [HACKERS] "unaddressable bytes" in BRIN

Alvaro Herrera wrote: > Andres Freund just forwarded me a valgrind error report that Peter > Geoghegan noticed: > > ==29892== Unaddressable byte(s) found during client check request > ==29892==at 0x7D1317: PageAddItem (bufpage.c:314) Fixed by Tom, http://git.postgresql.org/pg/commitdiff/79f2b

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > What do we need RowSecurityPolicy->policy_id for? It seems to me that > > it is only used to determine whether the policy is the "default deny" > > one, so that it can later be removed if a hook adds a diffe

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Robert Haas writes: > Anything we do short of making all errors in this area non-fatal is > going to leave behind startup-failure cases that exist today, and we > have no evidence at this time that such startup failures would be > justified by any actual data loss risk. Yeah. Perhaps I missed it

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Naoya Anzai writes: > I have a question about txid_current(). > it is "Why does txid_current() assign new transaction-id?". Consider begin; select txid_current(); insert into my_table ...; commit; If we changed the code as you propose, the result of the SELECT wo

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Peter Geoghegan writes: > > I meant to get around to looking into it, but FWIW I see BRIN-related > > Valgrind issues. e.g.: > > Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact > so it does not explain whatever is happening on chipmunk. Ah, thanks for diag

Re: [HACKERS] Order of columns in query is important?!

CK Tan writes: > For Vitesse X, we mark all columns that were required in the query during > JIT compile, and deform it in one shot. PG should be able to do the same. See ExecProject(). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > What do we need RowSecurityPolicy->policy_id for? It seems to me that > it is only used to determine whether the policy is the "default deny" > one, so that it can later be removed if a hook adds a different one. > This seems contrived

Re: [HACKERS] PostgreSQL 8.3 index page count clarification

On 05/26/2015 08:45 AM, Srinivas Karthik V wrote: Hi, For the user created indexes in PostgreSQL 8.3.6, I would like to know which file or function populates the index data structure. Specifically, where in the code is index->tuples and index->pages values are fetched and updated.

[HACKERS] PostgreSQL 8.3 index page count clarification

Hi, For the user created indexes in PostgreSQL 8.3.6, I would like to know which file or function populates the index data structure. Specifically, where in the code is index->tuples and index->pages values are fetched and updated. Regards and Thanks in Advance, Srinivas Karthik

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Mon, May 25, 2015 at 9:54 PM, Andres Freund wrote: > On 2015-05-25 21:33:03 -0400, Robert Haas wrote: >> On Mon, May 25, 2015 at 2:20 PM, Tom Lane wrote: >> > Perhaps, but if we didn't have permission to write the file, it's hard to >> > argue that it's our responsibility to fsync it. So this

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Mon, May 25, 2015 at 9:54 PM, Stephen Frost wrote: > I certainly see your point, but Tom also pointed out that it's not great > to ignore failures during this phase: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Greg Stark writes: >> > What exactly is failing? >> > Is it that fsync is returnin

[HACKERS] Selectivity estimation for intarray with @@

Hello. Attached patch based on: http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com and adds selectivity estimation functions to @@ (port from tsquery). Now we support &&, @>, <@ and @@. In addition it was written migration to version 1.1 intar

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2015-05-26 03:54:51 +0200, and...@anarazel.de wrote: > > Another thing is whether we should handle a recursive symlink in > > pgdata? I personally think not, but... > > I think not too. Yikes.. That's definitely the kind of thing that's why

Re: [HACKERS] Order of columns in query is important?!

On 25 May 2015 at 11:48, Amit Langote wrote: > On 2015-05-25 PM 06:26, Colin 't Hart wrote: > > That means the specified order of columns in a query does matter which > would > have to match the defined order in order to avoid extra processing (that is > only when specified columns *exactly* ma

Re: [HACKERS] Order of columns in query is important?!

You're right. I misread the problem description. On Tue, May 26, 2015 at 3:13 AM, Petr Jelinek wrote: > On 26/05/15 11:59, CK Tan wrote: > >> It has to do with the implementation of slot_getattr, which tries to do >> the deform on-demand lazily. >> >> if you do select a,b,c, the execution would

Re: [HACKERS] Order of columns in query is important?!

On 26/05/15 11:59, CK Tan wrote: It has to do with the implementation of slot_getattr, which tries to do the deform on-demand lazily. if you do select a,b,c, the execution would do slot_getattr(1) and deform a, and then slot_getattr(2) which reparse the tuple to deform b, and finally slot_getatt

Re: [HACKERS] Order of columns in query is important?!

It has to do with the implementation of slot_getattr, which tries to do the deform on-demand lazily. if you do select a,b,c, the execution would do slot_getattr(1) and deform a, and then slot_getattr(2) which reparse the tuple to deform b, and finally slot_getattr(3), which parse the tuple yet aga

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

On 26/05/2015 10:23, Tatsuo Ishii wrote: It was fixed in 9.3.7. OK. Do you know what the bug number was or what it was called (I've tried searching for it before posting, but found nothing which seemed to be the same problem as ours). Do you know whether, if we upgrade to 9.3.7/8, it wil

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

It was fixed in 9.3.7. Unfortunately 9.3.7 has new bug which is irrelevant to this. http://www.postgresql.org/message-id/20150525142657.4686.35...@wrigleys.postgresql.org I'm not sure if Ubuntu 12.04 is affected by the bug or not though. As far as I know developers plan to release 9.3.8 etc. soo

[HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error: ERROR: MultiXactId 1934308693 has not been created yet -- apparent wraparound on doing various queries on our database. I don't think it is a wraparound - I think the tuple has mistakenly decided it has a MultiXactId related to i

Re: [HACKERS] 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

Peter Geoghegan wrote: > In any case, third party foreign data wrappers that target other > database system will totally ignore ON CONFLICT DO NOTHING when built > against the master branch (unless they consider these questions). They > should perhaps make a point of rejecting DO NOTHING outright w

Re: [HACKERS] problems on Solaris

On Mon, May 25, 2015 at 1:07 AM, Andres Freund wrote: > On 2015-05-24 19:44:37 -0400, Andrew Dunstan wrote: >> >> Buildfarm members casteroides and protosciurus have been having some >> problems that seem puzzling. These animals both run on the same machine, but >> with different compilers. >> >>

[HACKERS] Why does txid_current() assign new transaction-id?

Hi,hackers! I have a question about txid_current(). it is "Why does txid_current() assign new transaction-id?". When we executes txid_current() outside of transaction block, it assigns new transaction-id. I guess it doesn't need to assign a new txid because txid_current() is just a read-only fu