Re: [HACKERS] [BUG?] tuples from file_fdw has strange xids.

Hello, sorry, it's my bad. > Kyotaro HORIGUCHI writes: > > Hello, I found that tuples come from file_fdw has strange xmin and xmax. > > file_fdw isn't documented to return anything useful for xmin/xmax/etc, > so I don't find this surprising. > > > The patch attached fixes the header of material

Re: [HACKERS] gaussian distribution pgbench -- part 1/2

pgbench with gaussian & exponential, part 1 of 2. This patch is a subset of the previous patch which only adds the two new \setrandom gaussian and exponantial variants, but not the adapted pgbench test cases, as suggested by Fujii Masao. There is no new code nor code changes. The corresponding

Re: [HACKERS] Question about src/timezone/zic.c

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> One thing that *would* be worth doing is merging upstream's recent >> updates; for all I know they've already dealt with this. According >> to the README, we last synced with the 2010c tzcode release, so we're >> short a few years

Re: [HACKERS] RLS Design

Adam, * Brightwell, Adam (adam.brightw...@crunchydatasolutions.com) wrote: > > Yeah, now that we're trying to bake this into ALTER TABLE we need to be > > a bit more cautious. I'd think: > > > > ALTER TABLE tab POLICY ADD ... > > > > Would work though? (note: haven't looked/tested myself) > > Y

Re: [HACKERS] RLS Design

Stephen, Yeah, now that we're trying to bake this into ALTER TABLE we need to be > a bit more cautious. I'd think: > > ALTER TABLE tab POLICY ADD ... > > Would work though? (note: haven't looked/tested myself) > Yes, I just tested it and the following would work from a grammar perspective: ALT

Re: [HACKERS] RLS Design

Tom, Thanks for the feedback. 20MB messages to the list aren't that friendly. Please don't do that > again, unless asked to. > Apologies, I didn't realize it was so large until after it was sent. At any rate, it won't happen again. > FWIW, the above syntax is a nonstarter, at least unless we

Re: [HACKERS] Question about src/timezone/zic.c

* Tom Lane (t...@sss.pgh.pa.us) wrote: > One thing that *would* be worth doing is merging upstream's recent > updates; for all I know they've already dealt with this. According > to the README, we last synced with the 2010c tzcode release, so we're > short a few years worth of upstream bug fixes t

Re: [HACKERS] RLS Design

Adam, * Tom Lane (t...@sss.pgh.pa.us) wrote: > "Brightwell, Adam" writes: > >> ALTER TABLE table_name ADD POLICY policy_name (quals); > >> ALTER TABLE table_name POLICY FOR role_name IS policy_name; > >> ALTER TABLE table_name DROP POLICY policy_name; [...] > This actually isn't just bison being

Re: [HACKERS] RLS Design

"Brightwell, Adam" writes: >> You could do: >> >> ALTER TABLE table_name ADD POLICY policy_name (quals); >> ALTER TABLE table_name POLICY FOR role_name IS policy_name; >> ALTER TABLE table_name DROP POLICY policy_name; > I am attempting to modify the grammar to support the above syntax. > Unfor

Re: [HACKERS] Allow GRANT TRIGGER privilege to DROP TRIGGER (Re: Bug ##7716)

Keith Fiske writes: > I found RemoveTriggerById() in backend/commands/trigger.c which seems to > be the code that actually drops the trigger. And I see in CreateTrigger() > above it how to use pg_class_aclcheck() to check for valid permissions, so > I was going to see about adding that code to th

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund wrote: > > On 2014-07-16 20:53:06 +0200, Andres Freund wrote: > > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > > Hi, > > > > > > I quickly looked at this patch and I think there's major missing pieces > > > around buffer management and wal l

Re: [HACKERS] Question about src/timezone/zic.c

John Cochran writes: > [ useless code in zic.c ] I agree with you that that function looks pretty pointless, but here's the thing: that's not our code. Most of the code in src/timezone is taken directly from the IANA tzcode distribution (see src/timezone/README), and we're not very interested in

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On 2014-07-16 20:53:06 +0200, Andres Freund wrote: > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > Hi, > > > > I quickly looked at this patch and I think there's major missing pieces > > around buffer management and wal logging. > > > > a) Currently buffers that are in memory marked as >

[HACKERS] Question about src/timezone/zic.c

I've recently found some time on my hands and have decided to see about contributing to the PostgreSQL project, so I've started browsing the code to get somewhat familiar with it. The file src/timezone/zic.c caused me to raise my eyebrows a bit and I have a question to ask because of this. I firs

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On Wed, Jul 16, 2014 at 3:53 PM, Andres Freund wrote: > > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > Hi, > > > > I quickly looked at this patch and I think there's major missing pieces > > around buffer management and wal logging. > > > > a) Currently buffers that are in memory marked

[HACKERS] Allow GRANT TRIGGER privilege to DROP TRIGGER (Re: Bug ##7716)

I'd reported a few years ago what seemed an inconsistency with the TRIGGER permission on tables where it allows a role to create a trigger but not to drop it. I don't have the original email to reply directly to the thread anymore, but I've moved on to actually trying to fix it myself, hence sendin

Re: [HACKERS] Built-in binning functions

2014-07-16 10:04 GMT+02:00 Petr Jelinek : > On 08/07/14 02:14, Tom Lane wrote: > >> Petr Jelinek writes: >> >>> here is a patch implementing varwidth_bucket (naming is up for >>> discussion) function which does binning with variable bucket width. >>> >> >> I didn't see any discussion of the namin

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > Hi, > > I quickly looked at this patch and I think there's major missing pieces > around buffer management and wal logging. > > a) Currently buffers that are in memory marked as >permanent/non-permanent aren't forced out to disk/pruned from

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

Hi, I quickly looked at this patch and I think there's major missing pieces around buffer management and wal logging. a) Currently buffers that are in memory marked as permanent/non-permanent aren't forced out to disk/pruned from cache, not even when they're dirty. b) When converting from a

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Wed, Jul 16, 2014 at 10:19 AM, Bruce Momjian wrote: > On Mon, Jul 14, 2014 at 09:40:33PM +0200, Andres Freund wrote: >> On 2014-07-11 09:55:34 -0400, Bruce Momjian wrote: >> > On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote: >> > > > Uh, why does this need to be in ALTER TABLE? C

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Christoph Berg writes: > Re: Viswanatham kirankumar 2014-07-16 > >> Attached patch is implementing following TODO item >> Process pg_hba.conf keywords as case-insensitive > Hmm. I see a case for accepting "ALL" (as in hosts.allow(5)), so +1 on > that, but I don't think the other keywords like "

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Viswanatham kirankumar 2014-07-16 > Attached patch is implementing following TODO item > Process pg_hba.conf keywords as case-insensitive > > * More robust pg_hba.conf parsing/error > logging Hmm. I see a case for accep

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

Re: Fabrízio de Royes Mello 2014-07-15 > > What about the wqueue mechanism, though? Isn't that made exactly for > > the kind of catalog updates you are doing? > > > > Works, but this mechanism create a new entry in pg_class for toast, so it's > a little different than use the cluster_rel that ge

Re: [HACKERS] [BUG?] tuples from file_fdw has strange xids.

Kyotaro HORIGUCHI writes: > Hello, I found that tuples come from file_fdw has strange xmin and xmax. file_fdw isn't documented to return anything useful for xmin/xmax/etc, so I don't find this surprising. > The patch attached fixes the header of materialized tuple to be > sane (2, 0) if the sour

Re: [HACKERS] Allowing join removals for more join types

David Rowley writes: > On Wed, Jul 16, 2014 at 1:17 PM, Tom Lane wrote: >> Notably, I felt that pathnode.c was a pretty questionable place to be >> exporting distinctness-proof logic from, and after some reflection decided >> to move those functions to analyzejoins.c; that's certainly a better pl

Re: [HACKERS] Unwanted LOG during recovery of DROP TABLESPACE REDO

Rajeev rastogi writes: > I found and fixed a bug that causes recovery (crash recovery , PITR) to throw > unwanted LOG message if the tablespace symlink is not found during the > processing of DROP TABLESPACE redo. > LOG: could not remove symbolic link > "pg_tbls

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On 2014-07-16 10:19:05 -0400, Bruce Momjian wrote: > > > What would be nice is if I could mark just the tables that will need > > > toast tables created in that later phase (those tables that didn't have > > > a toast table in the old cluster, but need one in the new cluster). > > > However, I can

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Mon, Jul 14, 2014 at 09:40:33PM +0200, Andres Freund wrote: > On 2014-07-11 09:55:34 -0400, Bruce Momjian wrote: > > On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote: > > > > Uh, why does this need to be in ALTER TABLE? Can't this be part of > > > > table creation done by pg_dump?

[HACKERS] Improvement of versioning on Windows, take two

Hi all, Please find attached a patch finishing the work begun during CF1. This adds versioning support for all the remaining dll and exe files on both MinGW and MSVC: - regress.dll (MSVC only) - isolationtester.exe - pg_isolation_regress.exe - pg_regress.exe - pg_regress_ecpg.exe - zic.exe I will

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 16 July 2014 12:13 Magnus Hagander Wrote, >>Yeah, those are exactly my points. I think it would be significantly simpler >>to do it that way, rather than forking and threading. And also easier to make >>portable... >>(and as a optimization on Alvaros suggestion, you can of course reuse the

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

From: "Amit Kapila" So as a conclusion, the left over items to be handled for patch are: 1. Remove the new usage related to use of same event source name for registration from pgevent. 2. Document the information to prevent loss of messages in some scenarios as explained above. I noticed the c

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

On Wed, Jul 16, 2014 at 6:23 PM, Viswanatham kirankumar wrote: > Attached patch is implementing following TODO item > > Process pg_hba.conf keywords as case-insensitive > > More robust pg_hba.conf parsing/error logging You should consider adding this patch to the next commit fest: https://commitfe

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

From: "Magnus Hagander" There's also the change to throw an error if the source is already registered, which is potentially a bigger problem. Since the default will be the same everywhere, do we really want to throw an error when you install a second version, now that this is the normal state?

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jul 16, 2014 at 4:06 PM, Magnus Hagander wrote: > > On Wed, Jul 16, 2014 at 12:31 PM, Amit Kapila wrote: > > On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander > > wrote: > >> On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila > >> wrote: > >> > >> There's also the change to throw an error if t

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jul 16, 2014 at 12:31 PM, Amit Kapila wrote: > On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander > wrote: >> On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila >> wrote: >> >> There's also the change to throw an error if the source is already >> registered, which is potentially a bigger problem

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander wrote: > On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila wrote: > > There's also the change to throw an error if the source is already > registered, which is potentially a bigger problem. I think generally if the s/w is installed/registered and we tr

Re: [HACKERS] SSL information view

On Mon, Jul 14, 2014 at 7:54 PM, Stefan Kaltenbrunner wrote: > On 07/13/2014 10:35 PM, Magnus Hagander wrote: >> On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner >> wrote: >>> On 07/12/2014 03:08 PM, Magnus Hagander wrote: As an administrator, I find that you fairly often want to know

Re: [HACKERS] better atomics - v0.5

On Mon, Jul 14, 2014 at 12:47 AM, Andres Freund wrote: > On 2014-07-08 11:51:14 +0530, Amit Kapila wrote: > > On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila > > wrote: > > Further review of patch: > > 1. > > /* > > * pg_atomic_test_and_set_flag - TAS() > > * > > * Acquire/read barrier semantics

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On Wed, Jul 16, 2014 at 9:11 AM, Tom Lane wrote: > Simon Riggs writes: > > On 15 July 2014 12:58, David Rowley wrote: > >> I found that the call to is_NOTANY_compatible_with_antijoin adds about > 0.2% > >> and 2.3% to total planning time. Though the 2.3% was quite an extreme > case, > >> and th

[HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Attached patch is implementing following TODO item Process pg_hba.conf keywords as case-insensitive * More robust pg_hba.conf parsing/error logging Thanks & Regards, Viswanatham Kiran Kumar pg_hba.conf_keywords_as_case-inse

Re: [HACKERS] Allowing join removals for more join types

On Wed, Jul 16, 2014 at 1:17 PM, Tom Lane wrote: > David Rowley writes: > > I've attached an updated patch which puts in some fast path code for > > subquery type joins. I'm really not too sure on a good name for this > > function. I've ended up with query_supports_distinctness() which I'm not >

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila wrote: > On Tue, Jul 15, 2014 at 8:57 PM, MauMau wrote: >> >> From: "Magnus Hagander" >> >>> Well, it does in a couple of places. I'm nto sure it's that important >>> (as nobody has AFAIK ever requested that change from for example EDB), >>> but it's

[HACKERS] BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().

Hello, As far as I see gin seems using GIN_EXCLUSIVE instead of BUFFER_LOCK_EXCLUSIVE for LockBuffer, but the raw BUFFER_LOCK_EXCLUSIVE appears in ginbuildempty(). Does it has a meaning to fix them to GIN_EXCLUSIVE? regards, -- Kyotaro Horiguchi NTT Open Source Software Center diff --git a/src

[HACKERS] [BUG?] tuples from file_fdw has strange xids.

Hello, I found that tuples come from file_fdw has strange xmin and xmax. > postgres=# select tableoid, xmin, xmax, * from passwd1; > tableoid | xmin |xmax| uname | pass | uid | gid | .. >16396 | 244 | 4294967295 | root | x| 0 | 0 | root... >16396

Re: [HACKERS] Built-in binning functions

On 08/07/14 02:14, Tom Lane wrote: Petr Jelinek writes: here is a patch implementing varwidth_bucket (naming is up for discussion) function which does binning with variable bucket width. I didn't see any discussion of the naming question in this thread. I'd like to propose that it should be j

Re: [HACKERS] Deadlocks in HS (on 9.0 :( )

On 2014-07-15 16:54:05 +0100, Greg Stark wrote: > We've observed a 9.0 database have undetected deadlocks repeatedly in > hot standby mode. > > I think what's happening is that autovacuum is kicking off a VACUUM of > some system catalogs -- it seems to usually be pg_statistics' toast > table actua