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

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

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 > > >

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

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.

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

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

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

[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

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

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

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

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

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

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 > >

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

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

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

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

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 > wrote: On Thursday, March 17, 2016, Craig Ringer > wrote: The first patch was

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

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

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

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

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

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

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

[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

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.

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,

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 >>

[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

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

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

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

Re: [HACKERS] Most efficient way for libPQ .. PGresult serialization

On 19 August 2016 at 22:16, Joshua Bay wrote: > Oh I see. > I just read more on use cases PgBouncer, but seems like it can't be used > for my project. > The reason is that I need to have my middleware to have full control over > each transaction. > That is it must be able

Re: [HACKERS] Exporting more function in libpq

On 19 August 2016 at 14:17, Tatsuo Ishii wrote: > I would like to proppse to export these functions in libpq. > > pqPutMsgStart > pqPutMsgEnd > pqPutc > pqPuts > pqPutInt > pqPutnchar > pqFlush > pqHandleSendFailure > > I think this would be useful to create a tool/library

Re: [HACKERS] Logical decoding restart problems

On 20 August 2016 at 00:36, Konstantin Knizhnik wrote: > > Sorry, I have not saved trace with output of logical decoder. Bu t it > really decodes just one update! > That's definitely a worry. Can you turn this into a reproducible, self contained test case? >

Re: [HACKERS] Logical decoding restart problems

On 19 August 2016 at 15:34, konstantin knizhnik wrote: > Hi, > > We are using logical decoding in multimaster and we are faced with the > problem that inconsistent transactions are sent to replica. > Briefly, multimaster is using logical decoding in this way: > 1. Each