[HACKERS] Identify user requested queries

Hi All, When the user attempts to make a connection with the database , the code will look into various pg_catalog tables internally. However the user also can query the pg_catalog tables. Is there a way to identify the user requested (or typed query) vs the system requested (internal) queries?

Re: [HACKERS] SPI and transactions

On 18 November 2015 at 18:18, Konstantin Knizhnik wrote: > But now SPI is used not only inside UDFs. It is also used in background > workers. For example in receiver_raw, written by Michael Paquier (I lot of > thanks Michael, understand logical replication without

Re: [HACKERS] custom function for converting human readable sizes to bytes

> > What about pg_size_unpretty()? > I was going to suggest pg_size_ugly(), but unpretty does emphasize the inverse (rather than opposite) nature of the function.

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 08/26/2015 07:46 AM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote: [...] So I think the way to move this forward is to investigate how to hold the SSL config

Re: [HACKERS] Using quicksort for every external sort run

On Fri, Nov 20, 2015 at 2:58 PM, Peter Geoghegan wrote: > The numbers speak for themselves here. I just want to be clear about > the disadvantages of what I propose, even if it's well worth it > overall in most (all?) cases. There is a paper called "Critical Evaluation of

Re: [HACKERS] custom function for converting human readable sizes to bytes

Le 22 nov. 2015 21:29, "Pavel Stehule" a écrit : > > > > 2015-11-22 21:19 GMT+01:00 Jim Nasby : >> >> On 11/22/15 2:11 PM, Pavel Stehule wrote: >>> >>> What about pg_size(text), pg_size(value bigint, unit text) ? >> >> >> I like, though I'd make

Re: [HACKERS] custom function for converting human readable sizes to bytes

2015-11-22 23:54 GMT+01:00 Corey Huinker : > What about pg_size_unpretty()? >> > I was going to suggest pg_size_ugly(), but unpretty does emphasize the > inverse (rather than opposite) nature of the function. > "unpretty", "ugly" aren't good names maybe pg_size_bytes or

Re: [HACKERS] [Pgbuildfarm-members] latest buildfarm client release

On 11/22/2015 12:47 AM, Tom Lane wrote: Andrew Dunstan writes: I have just released version 4.16 of the PostgreSQL Buildfarm client I updated my critters to 4.16, and since nothing much was happening in git, decided to test by doing "run_build.pl --nosend --verbose

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 12 November 2015 at 13:44, Peter Geoghegan wrote: > On Wed, Nov 4, 2015 at 6:30 PM, David Rowley > wrote: > >> Have you thought about *just* having an int64 pg_ltostr()? Are you > >> aware of an appreciable overhead from having int32 callers

Re: [HACKERS] count_nulls(VARIADIC "any")

On 2015-11-22 21:17, Jim Nasby wrote: On 11/22/15 11:34 AM, Marko Tiikkaja wrote: On 2015-11-22 18:29, Jim Nasby wrote: Only if you know how many columns there already are. Or does this not work if you hand it a row? It "works" in the sense that it tells you whether the row is NULL or not.

Re: [HACKERS] custom function for converting human readable sizes to bytes

2015-11-22 18:30 GMT+01:00 Jim Nasby : > On 11/21/15 12:49 AM, Pavel Stehule wrote: > >> >> I propose inversion function to pg_size_pretty function - like >> pg_human_size. >> >> Usage: >> >> SELECT * FROM pg_class >>WHERE pg_table_size(oid) > pg_human_size('2GB');

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2015-11-22 18:30, Jim Nasby wrote: On 11/21/15 12:49 AM, Pavel Stehule wrote: I propose inversion function to pg_size_pretty function - like pg_human_size. Usage: SELECT * FROM pg_class WHERE pg_table_size(oid) > pg_human_size('2GB'); I'm not a big fan of the name, but +1 on the

Re: [HACKERS] count_nulls(VARIADIC "any")

On 11/22/15 11:34 AM, Marko Tiikkaja wrote: On 2015-11-22 18:29, Jim Nasby wrote: Only if you know how many columns there already are. Or does this not work if you hand it a row? It "works" in the sense that it tells you whether the row is NULL or not. I.e. the answer will always be 0 or 1.

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 11/22/15 2:11 PM, Pavel Stehule wrote: What about pg_size(text), pg_size(value bigint, unit text) ? I like, though I'd make it numeric or float. pg_size(3.5, 'GB') certainly seems like a reasonable use case... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in

Re: [HACKERS] custom function for converting human readable sizes to bytes

2015-11-22 21:19 GMT+01:00 Jim Nasby : > On 11/22/15 2:11 PM, Pavel Stehule wrote: > >> What about pg_size(text), pg_size(value bigint, unit text) ? >> > > I like, though I'd make it numeric or float. pg_size(3.5, 'GB') certainly > seems like a reasonable use case...

Re: [HACKERS] count_nulls(VARIADIC "any")

On 11/20/15 11:55 PM, Marko Tiikkaja wrote: On 2015-11-21 06:52, Jim Nasby wrote: On 11/20/15 11:12 PM, Marko Tiikkaja wrote: On 2015-11-21 06:02, I wrote: Here's a patch implementing this under the name num_nulls(). For January's CF, of course. I forgot to update the some references in

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 11/21/15 12:49 AM, Pavel Stehule wrote: I propose inversion function to pg_size_pretty function - like pg_human_size. Usage: SELECT * FROM pg_class WHERE pg_table_size(oid) > pg_human_size('2GB'); I'm not a big fan of the name, but +1 on the general idea. Maybe pg_size_pretty(text)?

Re: [HACKERS] count_nulls(VARIADIC "any")

On 2015-11-22 18:29, Jim Nasby wrote: Only if you know how many columns there already are. Or does this not work if you hand it a row? It "works" in the sense that it tells you whether the row is NULL or not. I.e. the answer will always be 0 or 1. .m -- Sent via pgsql-hackers mailing

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Nov 21, 2015 at 6:50 AM, Jeff Janes wrote: > On Thu, Nov 19, 2015 at 6:44 AM, Masahiko Sawada > wrote: >> On Thu, Nov 19, 2015 at 5:54 AM, Jeff Janes wrote: >>> On Wed, Nov 18, 2015 at 11:18 AM, Jeff Janes

Re: [HACKERS] Freeze avoidance of very large table.

On Sun, Nov 22, 2015 at 8:16 AM, Masahiko Sawada wrote: > Thank you for taking the time to review this patch! > The updated version patch is attached. I am skeptical about just copying the old page header to be two new page headers. I don't know what the implications for

Re: [HACKERS] more RLS oversights

On Tue, Jul 28, 2015 at 04:04:29PM -0700, Joe Conway wrote: > On 07/27/2015 05:34 PM, Joe Conway wrote: > > On 07/27/2015 01:13 PM, Alvaro Herrera wrote: > >> Hmm, these are not ACL objects, so conceptually it seems cleaner > >> to use a different symbol for this. I think the catalog state > >>