Re: [HACKERS] dsm_unpin_segment

On Sat, Aug 20, 2016 at 6:13 PM, Robert Haas wrote: > On Sat, Aug 20, 2016 at 7:37 AM, Amit Kapila wrote: >> 2. >> + if (dsm_control->item[seg->control_slot].pinned) >> + elog(ERROR, "cannot pin a segment that is already pinned"); >> >> Shouldn't this be a user facing error (which means we should

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Sat, Aug 20, 2016 at 9:58 PM, Claudio Freire wrote: > On Sat, Aug 20, 2016 at 4:27 AM, Amit Kapila wrote: >> >> That makes sense, but this means there is a chance that the searches >> could lead to different buffers in case of uniqueness checks (the >> search with key-ctid could lead to a diff

Re: [HACKERS] replication slots replicated to standbys?

On 21 Aug 2016 12:36 AM, "Bruce Momjian" wrote: > > On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote: > > On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian wrote: > > > Someone reported that a replication slot that existed at the time a base > > > backup was done on the master was cop

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

> > I looked into this and soon found that fe_utils/string_utils.o has > dependencies on libpq that are much wider than just pqexpbuffer :-(. > It might be a project to think about sorting that out sometime, but it > looks like it would be an awful lot of work just to avoid having initdb > depend o

Re: [HACKERS] SP-GiST support for inet datatypes

Emre Hasegeli writes: > Attached patches add SP-GiST support to the inet datatypes. I started to look at this patch. The reported speedup is pretty nice, but ... > The operator > class comes with a small change on the SP-GiST framework to allow fixed > number of child nodes. ... this part of t

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Jeff Janes writes: > On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: >> It does know it, what it doesn't know is how many duplicates there are. > Does it know whether the count comes from a parsed query-string list/array, > rather than being an estimate from something else? If it came from a j

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > Jeff Janes writes: > > So even though it knows that 6952 values have been shoved in the bottom, > it > > thinks only 200 are going to come out of the aggregation. This seems > like > > a really lousy estimate. In more complex queries than the

Re: [HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

Noah Misch writes: > On Fri, Aug 19, 2016 at 07:22:02PM -0400, Tom Lane wrote: >> So maybe we ought to work towards taking those out? > Maybe. It's a policy question boiling down to our willingness to spend cycles > zeroing memory in order to limit trust in the confidentiality of storage > backi

[HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

On Fri, Aug 19, 2016 at 07:22:02PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-19 17:55:25 -0400, Tom Lane wrote: > >> It'd be useful also to figure out why our existing valgrind testing has > >> not caught this already. The example you give looks like it surely > >> ought to be

Re: [HACKERS] Should we cacheline align PGXACT?

Robert Haas writes: > Wow, nice results. My intuition on why PGXACT helped in the first place was > that it minimized the number of cache lines that had to be touched to take a > snapshot. Padding obviously would somewhat increase that again, so I can't > quite understand why it seems to be he

Re: [HACKERS] Should we cacheline align PGXACT?

On Aug 19, 2016, at 2:12 AM, Alexander Korotkov wrote: > Hackers, > > originally this idea was proposed by Andres Freund while experimenting with > lockfree Pin/UnpinBuffer [1]. > The patch is attached as well as results of pgbench -S on 72-cores machine. > As before it shows huge benefit in

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

I wrote: > A bigger issue here is that it seems fundamentally wrong for initdb to be > including libpq, because it surely is never meant to be communicating > with a running postmaster. Not sure what to do about that. We could > consider moving pqexpbuffer out of libpq into fe_utils, but I wonder

Re: [HACKERS] Making pg_hba.conf case-insensitive

On Thu, Aug 18, 2016 at 04:49:04PM -0400, Bruce Momjian wrote: > On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote: > > On 8/18/16 1:59 PM, Bruce Momjian wrote: > > > o compares words in columns that can only support keywords as > > > case-insensitive, double-quoted or not > > > >

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Michael Paquier writes: > Regarding your patch, with a bit of clean up it gives the attached. This fails to build for me, with gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -

Re: [HACKERS] standalone backend PANICs during recovery

I wrote: > In short, I don't think control should have been here at all. My proposal > for a fix is to force EnableHotStandby to remain false in a standalone > backend. I tried to reproduce Bernd's problem by starting a standalone backend in a data directory that was configured as a hot standby s

Re: [HACKERS] replication slots replicated to standbys?

On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote: > On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian wrote: > > Someone reported that a replication slot that existed at the time a base > > backup was done on the master was copied to the standby. Because they > > didn't realize it, th

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Sat, Aug 20, 2016 at 8:26 AM, Michael Paquier wrote: > On Sat, Aug 20, 2016 at 4:39 AM, Ryan Murphy > wrote: > > Here is another version of my initdb shell quoting patch. I have removed > > the unnecessary {} block. I also ran pgindent on the code prior to > creating > > the patch. > > Coul

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Sat, Aug 20, 2016 at 4:27 AM, Amit Kapila wrote: >> All uniqueness checks will find the same "nbuf" (read-locked), which >> is the first one that matches the key. >> >> They could have different "buf" buffers (the write-locked) one. But >> since read locks cannot be held while a write-lock is h

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

Haribabu Kommi writes: > This is a new statistics view that is used to provide the number of > SQL operations that are > happened on a particular interval of time. This view is useful for the > system to find out the > pattern of the operations that are happening in the instance during > particula

Re: [HACKERS] LSN as a recovery target

On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote: > On 20/08/16 02:13, Michael Paquier wrote: >> On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat >> wrote: >> Using a PG_TRY/CATCH block the way you do to show to user a different >> error message while the original one is actually correct does

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 20/08/16 16:01, Craig Ringer wrote: On 5 June 2016 at 09:54, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Thursday, March 17, 2016, Craig Ringer mailto:cr...@2ndquadrant.com>> wrote: The first patch was incorrectly created on top of failover slots not H

Re: [HACKERS] CREATE POLICY bug ?

On 20 August 2016 at 03:15, Andrea Adami wrote: > when i run the query: "select * from public.policy_view" > the ouput is the same (all rows) for all users > i'm doing some mistakes or this is a bug ? > No, it looks correct to me. When going through a view, the policies and permission checks tha

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 5 June 2016 at 09:54, David G. Johnston wrote: > On Thursday, March 17, 2016, Craig Ringer wrote: > >> The first patch was incorrectly created on top of failover slots not >> HEAD. Attached patch applies on HEAD. >> > > Lots of logical decoding work ongoing but this one shows as active in the

Re: [HACKERS] LSN as a recovery target

On 20/08/2016 15:41, Michael Paquier wrote: > On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote: >> If we want to specifically name the recovery_target_lsn in the message, we >> could probably do it using context. > > So that would be basically assigning error_context_stack for each item > par

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 19 August 2016 at 21:10, Peter Eisentraut wrote: > On 8/18/16 9:20 PM, Craig Ringer wrote: > > On 19 August 2016 at 02:35, Jim Nasby > > wrote: > > I think we need to either add real types for handling XID/epoch/TXID > > or finally create uint types. I

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 20 August 2016 at 21:24, Craig Ringer wrote: > Hi all > > Following on from > > bigint txids vs 'xid' type, new txid_recent(bigint) => xid > > Ahem. Forgot to squash in a fixup commit. Updated patch of txid_status(bigint) attachd. A related patch follows, adding a new txid_current_ifassigned(

Re: [HACKERS] LSN as a recovery target

On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote: > If we want to specifically name the recovery_target_lsn in the message, we > could probably do it using context. So that would be basically assigning error_context_stack for each item parsed for recovery.conf? That seems a bit narrow as usua

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Sat, Aug 20, 2016 at 4:39 AM, Ryan Murphy wrote: > Here is another version of my initdb shell quoting patch. I have removed > the unnecessary {} block. I also ran pgindent on the code prior to creating > the patch. Could you please *not* top-post? This breaks the logic of the thread, this is

[HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

Hi all Following on from bigint txids vs 'xid' type, new txid_recent(bigint) => xid https://www.postgresql.org/message-id/camsr+yfdzmn_iz7krroe+j0kvlqvfvgvzxbcvxr-mljgtoz...@mail.gmail.com here's a patch that implements a txid_status(bigint) function to report the commit status of a function.

Re: [HACKERS] Logical decoding restart problems

On 20 August 2016 at 14:56, konstantin knizhnik wrote: > Thank you for answers. > > No, you don't need to recreate them. Just advance your replication > identifier downstream and request a replay position in the future. Let the > existing slot skip over unwanted data and resume where you want to

Re: [HACKERS] dsm_unpin_segment

On Sat, Aug 20, 2016 at 7:37 AM, Amit Kapila wrote: > 2. > + if (dsm_control->item[seg->control_slot].pinned) > + elog(ERROR, "cannot pin a segment that is already pinned"); > > Shouldn't this be a user facing error (which means we should use ereport)? Uh, certainly not. This can't happen becaus

Re: [HACKERS] Improving planner's checks for parallel-unsafety

On Thu, Aug 18, 2016 at 5:07 PM, Tom Lane wrote: > Robert Haas writes: >> I have reviewed this and it looks good to me. My only comment is that >> this comment is slightly confusing: > >> ! * Returns the first of PROPARALLEL_UNSAFE, PROPARALLEL_RESTRICTED, or >> ! * PROPARALLEL_SAFE that can b

Re: [HACKERS] Any need of GRANT/REVOKE CREATE TABLE | POLICY | ETC

On Tue, Aug 2, 2016 at 3:25 AM, Robert Haas wrote: > On Tue, Jul 19, 2016 at 2:59 AM, Haribabu Kommi > wrote: >> During the discussion of supporting multi tenancy with the help of >> row level security, because of some problems of executing any >> policy that was created by an unprivileged user [

[HACKERS] New SQL counter statistics view (pg_stat_sql)

This is a new statistics view that is used to provide the number of SQL operations that are happened on a particular interval of time. This view is useful for the system to find out the pattern of the operations that are happening in the instance during particular interval of time. Following is th

Re: [HACKERS] dsm_unpin_segment

On Tue, Aug 9, 2016 at 10:07 AM, Thomas Munro wrote: > On Tue, Aug 9, 2016 at 12:53 PM, Tom Lane wrote: >> The larger picture here is that Robert is exhibiting a touching but >> unfounded faith that extensions using this feature will contain zero bugs. >> IMO there needs to be some positive defen

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Sat, Aug 20, 2016 at 10:23 AM, Claudio Freire wrote: > On Sat, Aug 20, 2016 at 1:05 AM, Amit Kapila wrote: >> On Thu, Aug 18, 2016 at 8:24 AM, Claudio Freire >> wrote: >>> >>> A couple of points make me uneasy about this patch, yet I can think of >>> no better alternative, so I seek feedback

Re: [HACKERS] Logical decoding restart problems

Thank you for answers. > No, you don't need to recreate them. Just advance your replication identifier > downstream and request a replay position in the future. Let the existing slot > skip over unwanted data and resume where you want to start replay. > > You can advance the replication origins