Re: [HACKERS] alter user/role CURRENT_USER

gt; new feature and independent of making role-vs-user cases more > consistent. Yeah, let's not mix those in the same patch. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

ions about the possible solutions more productive. :-) -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

sin Courts. I understand the need. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Trailing comma support in SELECT statements

a more comprehensive patch, I could look at it and develop an opinion on whether the cost/benefit ratio looked like it was worth it. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

rmission to the pg_log directory and the files contained therein, assuming they do *not* have an OS login to the database server? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

That is not the sort of use case that I feel is the primary target of this. > ISTM that that type of use-case would be satisfied well enough > --- not ideally, perhaps, but well enough --- by being able to > grant full filesystem read and/or write to non-superuser accounts. IMV, if we

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

$ begin perform sum('1.01'::money) from generate_series(1,1000); end; $$; DO Time: 3572.709 ms A sum of numeric: test=# do $$ begin perform sum('1.01'::numeric) from generate_series(1,1000); end; $$; DO Time: 4805.559 ms -- Kevin Grittner EDB: http://www.enterpri

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

0x slower than money in important applications, combined with the fact that it performs far worse than a similar type in another product, suggest that numeric could stand a serious optimization pass. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] Time to remove dummy autocommit GUC?

Tom Lane wrote: > ISTM that by now we could just flat-out remove it. +1 -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.

Re: [HACKERS] tracking commit timestamps

for a serializable transaction to read. If there's a way to implement commit order recording such that a two-state flag could be associated with each commit, I think it could be made to work for serializable transactions. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterp

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

saction" as soon as BEGIN is executed; it does not wait for the snapshot to be acquired. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

Re: [HACKERS] Amazon Redshift

t's not like all of them would be committed in the same patch anyway. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

ld provide the option of freezing without the nasty > hack of having to do a "SELECT 1" prior to your real queries, and > everything will of course be well documented. What is the use case where you are having a problem? This seems like an odd solution, so it would be helpful to

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

Greg Sabino Mullane wrote: > Kevin Grittner wrote: > (wording change suggestion) >>> | sees a snapshot as of the start of the first query within the >>> | transaction, not as of the start of the current query within the >>> | transaction. >> >> Would

Re: [HACKERS] Tweaking Foreign Keys for larger tables

te have completed which actually allows writes. Or that could be done with a "char" column with three states. So on transition to read only you would flag it as non-writable, and after all transactions which might have seen it in a writable state complete you flag it as allowing re

Re: [HACKERS] TODO request: log_long_transaction

class, those could be included in the log message for a long-running transaction. That would make the messages useful -- at least for occurrences when either or both were set. The question is whether people would be willing to set these GUCs to make the logging useful -- Kevin Grittner EDB: htt

Re: [HACKERS] row_to_json bug with index only scans: empty keys!

d just stick to the more-backwards-compatible behavior until someone > does complain. Thoughts? I think consistent use of the aliases would be less surprising and should be what we do on master. I agree that we should avoid breaking anything that might be working as intended on stable b

Re: [HACKERS] Compiler warning in master branch

[-Werror=unused-but-set-variable] >> BlockNumber mapBlk; >> ^ > It would appear just to need the attached. Confirmed and pushed. Thanks to both of you! -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mail

Re: [HACKERS] WIP: multivariate statistics / proof of concept

sv, header); alter table zipcode add primary key (recordnumber); create unique index zipcode_city on zipcode (zipcode, city); I bet there are all sorts of correlation possibilities with, for example, latitude and longitude and other variables. With 81831 rows and so many correlations among the columns, it might be a useful data set to test with. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] SQL function to report log message

eone passing a NULL parameter for hint to a function like this doesn't mean "there is likely to be a valid value for hint, but I don't know what it is" -- they mean there is no available hint, so please don't show one. Any other behavior seems rather silly. -- Kevi

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

anything resembling ACID guarantees; but if you want to give up all claim to that, you might be able to provide something useful with a more lax set of assurances. (After all, there are some popular products out there which are pretty "relaxed" about such things.) In that case maybe the X

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On Tuesday, November 17, 2015 12:43 AM, konstantin knizhnik wrote: > On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: >> If you are saying that DTM tries to roll back a transaction after >> any participating server has entered the RecordTransactionCommit() >> critical se

[HACKERS] New email address

o sends to the addresses to the current address. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] New email address

ng the subject or body of the email) be necessary? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

quot; is not a valid size value" would be better. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] snapshot too old, configured by time

7;s worth. > There has been a review but no replies for more than 1 month. Returned > with feedback? I do intend to post another version of the patch to tweak the calculations again, after I can get a patch in to expand the testing capabilities to allow an acceptable way to test the patch -- so I put it into the next CF instead. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] atomic reads & writes (with no barriers)

11) compilers, but I'm not aware of what options there are. Is the c.h change above on anything resembling the right track for a patch for this? If not, what would such a patch look like? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql

Re: [HACKERS] atomic reads & writes (with no barriers)

On Fri, Dec 4, 2015 at 6:35 AM, Greg Stark wrote: > On Thu, Dec 3, 2015 at 10:10 PM, Kevin Grittner wrote: >> Is the c.h change above on anything resembling the right track for >> a patch for this? If not, what would such a patch look like? > > It would be nicer if we

Re: [HACKERS] Double linking MemoryContext children

On Sun, Dec 6, 2015 at 7:30 PM, Jim Nasby wrote: > On 9/14/15 7:24 AM, Jan Wieck wrote: >> On 09/12/2015 11:35 AM, Kevin Grittner wrote: >> >>> On the other hand, a grep indicates that there are two places that >>> MemoryContextData.nextchild is set (and we theref

Re: [HACKERS] Speedup twophase transactions

been *Patched master with 2PC"? Please add this to the January CommitFest. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Another XML build issue

x27;<' not found --- 271,276 == Any ideas on what to do about this one? I could certainly push yet another version of the expected file, but I'm not sure that's the thing to do. I don't see it in the buildfarm yet, but that&#x

Re: [HACKERS] Another XML build issue

00:30 -0500 I don't know how that compares to other distros... -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] Another XML build issue

eems rather different to what I see in the Red Hat discussion. In particular, I see no changes to error.c. I haven't really figured the cause of the discrepancy yet, but figured I would pass along the diff link. http://launchpadlibrarian.net/229976362/libxml2_2.9.1%2Bdfsg1-3ubuntu4.5_2.9.

Re: [HACKERS] Another XML build issue

hat, > and its output doesn't depend on whether libxml2 continues parsing > after the first error. That's fine with me. I can do that, if there are no objections. (It is easy enough to find the affected lines in all 3 "expected" files.) -- Kevin Grittner EDB: http:/

Re: [HACKERS] Another XML build issue

On Mon, Dec 14, 2015 at 10:56 AM, Kevin Grittner wrote: > On Mon, Dec 14, 2015 at 10:43 AM, Tom Lane wrote: > >> As I said, my inclination is to remove the SELECT xmlparse(document '') >> test case altogether. The following test SELECT xmlparse(document ' &#x

Re: [HACKERS] Materialized views WIP patch

Greg Smith wrote: > On 11/14/12 6:28 PM, Kevin Grittner wrote: >> - Documentation is incomplete. >> ... >> - There are no regression tests yet. > > Do you have any simple test cases you've been using you could attach? > With epic new features like this,

Re: [HACKERS] Materialized views WIP patch

Jeff Davis wrote: > On Wed, 2012-11-14 at 21:28 -0500, Kevin Grittner wrote: > > Attached is a patch that is still WIP but that I think is getting > > pretty close to completion. It is not intended to be the be-all and > > end-all for materialized views, but the minim

Re: [HACKERS] Materialized views WIP patch

Alvaro Herrera wrote: > It's not clear to me that it's right to do this by doing regular heap > updates here instead of heap_inplace_update. Also, I think this might > end up causing a lot of pg_class tuple churn (at least for matviews that > delete rows at xact end), which would be nice to avoid.

Re: [HACKERS] Materialized views WIP patch

Josh Berkus wrote: >> 1. CREATE MATERIALIZED VIEW syntax is stolen directly from CREATE >> TABLE AS, with all the same clauses supported. That includes >> declaring a materialized view to be temporary or unlogged. > > What use would a temporary matview be? It would be essentially like a temporar

Re: [HACKERS] Materialized views WIP patch

Thom Brown wrote: > postgres=# create view v_test as select 1; > CREATE VIEW > postgres=# create materialized view mv_test as select * from v_test; > ERROR: could not open file "base/12064/16425": No such file or directory Thanks for the report; will investigate. -Kevin -- Sent via pgsql-hack

Re: [HACKERS] Materialized views WIP patch

Robert Haas wrote: > Josh Berkus wrote: >> Being empty (in an inaccurate way) is just one kind of stale data. > > This is my feeling also. If you had an MV summarizing Wisconsin courts cumulative case counts by case type, "empty" would not have been a valid "stale" state for over 150 years. That

Re: [HACKERS] Materialized views WIP patch

Simon Riggs wrote: > This seems very similar to the REPLACE command we discussed > earlier, except this is restricted to Mat Views. I don't remember that discussion -- do you have a reference? > If we're going to have this, I would prefer a whole command. > > e.g. REPLACE matviewname REFRESH >

Re: [HACKERS] Materialized views WIP patch

Albe Laurenz wrote: > Kevin Grittner wrote: > >> My take was more that MVs would often be refreshed by crontab, and >> that you would want to keep subsequent steps from running and >> generating potentially plausible but completely inaccurate results >> if the L

Re: [HACKERS] Materialized views WIP patch

Tom Lane wrote: > "Kevin Grittner" writes: >> Josh Berkus wrote: >>> What use would a temporary matview be? > >> It would be essentially like a temporary table, with all the same >> persistence options. I'm not really sure how often it will be more

Re: [HACKERS] Invalid optimization of VOLATILE function in WHERE clause?

Merlin Moncure wrote: > Kevin Grittner wrote: >> Merlin Moncure wrote: >> >>> Hm, I bet it's possible (although probably not easy) to deduce >>> volatility from the function body...maybe through the validator. >>> If you could do that (perhaps

Re: [HACKERS] autovacuum truncate exclusive lock round two

Alvaro Herrera wrote: > Are you posting an updated patch? Well, there wasn't exactly a consensus on what should change, so I'll throw some initial review comments out even though I still need to check some things in the code and do more testing. The patch applied cleanly, compiled without warnin

Re: [HACKERS] Materialized views WIP patch

Marko Tiikkaja wrote: > On 15/11/2012 03:28, Kevin Grittner wrote: > I have been testing the patch a bit Thanks! > and I'm slightly disappointed by the fact that it still doesn't > solve this problem (and I apologize if I have missed discussion > about this in t

Re: [HACKERS] Materialized views WIP patch

David Fetter wrote: > On Mon, Nov 26, 2012 at 09:46:33AM -0500, Peter Eisentraut wrote: >> So, the way I understand it, in Oracle terms, this feature is a >> "snapshot", not a materialized view. Maybe that's what it should >> be called then. > > "Snapshot" is one of the options for refreshing an

Re: [HACKERS] Materialized views WIP patch

Pavel Stehule wrote: > 2012/11/27 Dimitri Fontaine : >> I would like that we have a way to refresh a Materialized View >> by calling a stored procedure, but I don't think it should be >> the main UI. I agree. I saw that Oracle uses a function for that without any statement-level support, and that

Re: [HACKERS] Materialized views WIP patch

Dimitri Fontaine wrote: > "Kevin Grittner" writes: >> An ALTER MATERIALIZED VIEW option was my first thought on syntax >> to do what LOAD does in the current patch. But it bothered me >> that I couldn't think of any other cases where ALTER >> only chang

Re: [HACKERS] Materialized views WIP patch

Robert Haas wrote: > I don't particularly like syntaxes involving DO or LOAD because > those words already have strong associations with completely > unrelated features. Now, if we don't want to do that and we don't > want to use ALTER for a data-modifying command either, another > option would be

Re: [HACKERS] autovacuum truncate exclusive lock round two

Kevin Grittner wrote: > I still need to review the timing calls, since I'm not familiar > with them so it wasn't immediately obvious to me whether they > were being used correctly. I have no reason to believe that they > aren't, but feel I should check. It seems odd t

Re: [HACKERS] foreign key locks

Alvaro Herrera wrote: > Here's version 24. This no longer applies after the rmgr rm_desc patch. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hot Standby Feedback should default to on in 9.3+

Claudio Freire wrote: > Without hot standby feedback, reporting queries are impossible. > I've experienced it. Cancellations make it impossible to finish > any decently complex reporting query. With what setting of max_standby_streaming_delay? I would rather default that to -1 than default hot_st

Re: [HACKERS] Hot Standby Feedback should default to on in 9.3+

Claudio Freire wrote: >> With what setting of max_standby_streaming_delay? I would rather >> default that to -1 than default hot_standby_feedback on. That >> way what you do on the standby only affects the standby. > > 1d Was there actually a transaction hanging open for an entire day on the sta

Re: [HACKERS] Materialized views WIP patch

Marko Tiikkaja wrote: > Kevin Grittner wrote: >> Marko Tiikkaja wrote: >>> >> >> As far as I know you are the first to notice this behavior. >> Thanks for pointing it out. >> >> I will take a look at the issue; I don't know whether it's

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > Attached is a new patch that addresses most of the points raised > in discussion before. > > 1) Most of the configuration variables are derived from > deadlock_timeout now. The "check for conflicting lock request" > interval is deadlock_timeout/10, clamped to 10ms. The "try to

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > Thinking about it, I'm not really happy with removing the > autovacuum_truncate_lock_check GUC at all. > > Fact is that the deadlock detection code and the configuration > parameter for it should IMHO have nothing to do with all this in > the first place. A properly implemente

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > [arguments for GUCs] This is getting confusing. I thought I had already conceded the case for autovacuum_truncate_lock_try, and you appeared to spend most of your post arguing for it anyway. I think. It's a little hard to tell. Perhaps the best thing is to present the issue to

Re: [HACKERS] autovacuum truncate exclusive lock round two

Robert Haas wrote: > Since people *already* raise deadlock_timeout to obscenely high > values (a minute? an hour???) and then complain that things blow > up in their face, I think there's a decent argument to be made > that piggybacking anything else on that setting is unwise. If people are reall

Re: [HACKERS] strange isolation test buildfarm failure on guaibasaurus

Stefan Kaltenbrunner wrote: > Subject: [HACKERS] strange isolation test buildfarm failure on guaibasaurus > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2012-12-05%2016%3A17%3A01 > seems like a rather odd failure in the isolation test (client) Lines which might get the atte

Re: [HACKERS] Functional dependency in GROUP BY through JOINs

David Rowley wrote: > If we wanted to see the sales per product we could write > something like this: > SELECT p.product_code,SUM(s.quantity) > FROM products p > INNER JOIN bigsalestable s ON p.productid = s.productid > GROUP BY p.product_code; > Though this plan might not be quite as optimal as

Re: [HACKERS] Enabling Checksums

Robert Haas wrote: > Jeff Davis wrote: >> Or, I could write up a test framework in ruby or python, using >> the appropriate pg driver, and some not-so-portable shell >> commands to start and stop the server. Then, I can publish that >> on this list, and that would at least make it easier to test >

Re: [HACKERS] Serious problem: media recovery fails after system or PostgreSQL crash

MauMau wrote: > [Problem] > I'm using PostgreSQL 9.1.6 on Linux. I encountered a serious > problem that media recovery failed showing the following message: > > FATAL: archive file "000100800028" has wrong size: > 7340032 instead of 16777216 > > I'm using normal cp command to archive

Re: [HACKERS] Functional dependency in GROUP BY through JOINs

Tom Lane wrote: > In the case being presented here, it's not apparent to me that > there's any advantage to be had at all. The OP reported a different plan which was twice as fast, although showing EXPLAIN ANALYZE results for both would be nice confirmation of that. > You still need to aggregate

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > Based on the discussion and what I feel is a consensus I have > created an updated patch that has no GUC at all. The hard coded > parameters in include/postmaster/autovacuum.h are > >  AUTOVACUUM_TRUNCATE_LOCK_CHECK_INTERVAL 20 /* ms */ >  AUTOVACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > Cleaned up all of those. Applied with trivial editing, mostly from a pgindent run against modified files. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parser Cruft in gram.y

Tom Lane wrote: > the parser tables are basically number-of-tokens wide by > number-of-states high. (In HEAD there are 433 tokens known to the > grammar, all but 30 of which are keywords, and 4367 states.) > > Splitting the grammar into multiple grammars is unlikely to do > much to improve this -

Re: [HACKERS] Enabling Checksums

Greg Smith wrote: > In general, what I hope people will be able to do is switch over to > their standby server, and then investigate further. I think it's > unlikely that people willing to pay for block checksums will only have > one server. Having some way to nail down if the same block is bad

Re: [HACKERS] [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

Groshev Andrey wrote: > >   Mismatch of relation names: database "database", old rel > > public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel > > public.plob.ВерсияВнешнегоДокумента$Документ There is a limit on identifiers of 63 *bytes* (not characters) after which the name is

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > This is security, not spec compliance. By default, we need full > security. But you are arguing that users should not be able to make something secure if they, and everyone with the same permissions, could not later access it. I thought about situations where I've seen a need

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > I've argued that row security should apply to ALL commands by default. > Which is exactly the same default as Oracle, as well as being the > obvious common sense understanding of "row security", which does not > cause a POLA violation. > > I have no objection to an option to

Re: [HACKERS] Review of Row Level Security

Andres Freund wrote: > I don't think it is that simple. Allowing inserts without regard for row > level restrictions makes it far easier to probe for data. E.g. by > inserting rows and checking for unique violations. Unless you want to go to a military-style security level system where people at

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > Kevin Grittner wrote: > >> I hope we can leave the syntax for this feature open to such >> specification, even if the initial implementation only supports >> limiting reads. > > Well, I hope the opposite: that we can support simple full securi

Re: [HACKERS] Review of Row Level Security

Kohei KaiGai wrote: > If system ensures writer's permission is always equivalent or > more restrictive than reader's permission, it also eliminates the > problem around asymmetric row-security policy between commands. I'm not sure we're understanding each other; so far people who favor asymmetric

Re: [HACKERS] Review of Row Level Security

Kohei KaiGai wrote: >> I don't think I like ALTER TABLE as a syntax for row level >> security. How about using existing GRANT syntax but allowing a >> WHERE clause? That seems more natural to me, and it would make >> it easy to apply the same conditions to multiple types of >> operations when desi

Re: [HACKERS] Review of Row Level Security

Simon Riggs wrote: > Each table has a single security clause. The clause doesn't enforce > that it must contain something that depends on role, but that is the > most easily understood usage of it. We do that to ensure that you can > embed the intelligence into a function, say hasRowLevelAccess(),

Re: [HACKERS] Review of Row Level Security

Kohei KaiGai wrote: > RLS entry of wiki has not been updated for long time, I'll try to > update the entry for high-level design in a couple of days. Thanks, I think that is essential for a productive discussion of the issue. For me, it would help tremendously if you could provide a very short s

Re: [HACKERS] Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

Simon Riggs wrote: > Not really sure about the 100s of columns use case. > > But showing gain in useful places in these more common cases wins > my vote. > > Thanks for testing. Barring objections, will commit. Do we have any results on just a plain, old stock pgbench run, with the default tabl

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Robert Haas wrote: > Christopher Browne wrote: >> these timestamps Should Not be captured or carried forward by >> pg_dump. >> If we put a creation time into pg_database or pg_class, then >> streaming replication will, as a "physical" replication >> mechanism, carry the timestamp forward into re

Re: [HACKERS] Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Andrew Dunstan wrote: > I don't especially have a horse in the race, but ISTM that if you want > the information you want it to be able to persist across dump/restore, > at least optionally. If you can happily lose it when you're forced to > recover using a logical dump then it's not that impor

Re: [HACKERS] proposal: Set effective_cache_size to greater of .conf value, shared_buffers

Josh Berkus wrote: > The, shared_buffers, wal_buffers, and effective_cache_size (and possible > other future settings) can be set to -1. If they are set to -1, then we > use the figure: > > shared_buffers = available_ram * 0.25 > (with a ceiling of 8GB) > wal_buffers = available_ram * 0.05 > (wit

Re: [HACKERS] 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL

Amit Kapila wrote: > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote: >> Surely VACUUM FULL should rebuild the visibility map, and make >> tuples in the new relation all-visible, no? Certainly it seems odd to me that VACUUM FULL leaves the the table in a less-well maintained state in term

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

Andrew Dunstan wrote: > Part of the trouble with detecting rogue postmasters it might have left > lying around is that various things like to decide what port to run on, > so it's not always easy for the buildfarm to know what it should be > looking for. For Linux, perhaps some form of lsof wi

Re: [HACKERS] Wide area replication postgres 9.1.6 slon 2.1.2 large table failure.

Tory M Blue wrote: > Postgres 9.1.4 slon 2.1.1 > -and- > Postgres 9.1.6 slon 2.1.2 If it is possible, it never hurts to rule out bugs for which fixes are already available in production releases: http://www.postgresql.org/support/versioning/ > Symptoms, slon immediately dies after transferring

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

Andrew Dunstan wrote: >> For Linux, perhaps some form of lsof with the +D option? > This actually won't help. In most cases the relevant data directory has > long disappeared out from under the rogue postmaster as part of > buildfarm cleanup. Also, lsof is not universally available. We try to

Re: [HACKERS] Materialized views WIP patch

Tom Lane wrote: > "Kevin Grittner" writes: >> I've been struggling with two areas: >> - pg_dump sorting for MVs which depend on other MVs > > Surely that should fall out automatically given that the > dependency is properly expressed in pg_depend? > >

Re: [HACKERS] Materialized views WIP patch

Thom Brown wrote: > Some weirdness: > > postgres=# CREATE VIEW v_test2 AS SELECT 1 moo; > CREATE VIEW > postgres=# CREATE MATERIALIZED VIEW mv_test2 AS SELECT moo, 2*moo FROM > v_test2 UNION ALL SELECT moo, 3*moo FROM v_test2; > SELECT 2 > postgres=# \d+ mv_test2 >  Materialized view "public.mv_t

Re: [HACKERS] Query to help in debugging

Bruce Momjian wrote: > I am wondering if we should make this query more widely used, perhaps by > putting it in our docs about reporting bugs, or on our website. http://wiki.postgresql.org/wiki/Server_Configuration http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_you_need_to_me

Re: [HACKERS] Query to help in debugging

Tom Lane wrote: > I find the manual exclusion list to be poor style, and not at all > future-proof. Maybe we could use > > select name, setting, source from pg_settings > where source not in ('default', 'override'); > > This would print a few not-all-that-interesting settings made by initdb, > b

Re: [HACKERS] Query to help in debugging

Bruce Momjian wrote: >> Why are you insisting on cramming version() into this? It could >> just as easily be a different query. > > I am fine with that: Done. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

Re: [HACKERS] Passing connection string to pg_basebackup

Robert Haas wrote: > I heartily agree. I can say from firsthand experience that when minor > releases break things for customers (and they do), the customers get > *really* cranky. Based on recent experience, I think we should be > tightening our standards for what gets back-patched, not loosening

Re: [HACKERS] autovacuum truncate exclusive lock round two

Kevin Grittner wrote: > Applied with trivial editing, mostly from a pgindent run against > modified files. Applied back as far as 9.0. Before that code didn't match well enough for it to seem safe to apply without many hours of additional testing. I have confirmed occurences of this

Re: [HACKERS] Materialized views WIP patch

Thanks for looking at this! Noah Misch wrote: > For the benefit of the archives, I note that we almost need not truncate an > unlogged materialized view during crash recovery. MVs are refreshed in a > VACUUM FULL-like manner: fill a new relfilenode, fsync it, and point the MV's > pg_class to that

Re: [HACKERS] Materialized views WIP patch

Noah Misch wrote: > On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote: >> Noah Misch wrote: >>> For the benefit of the archives, I note that we almost need not truncate an >>> unlogged materialized view during crash recovery. MVs are refreshed in a >>

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

Robert Haas wrote: > Andres Freund wrote: >> More people seem to have voted for the single file approach but I still >> haven't understood why... > > Me neither.  Having an include directory seems good, but I can't think > why we'd want to clutter it up with a bajillion automatically > generated

[HACKERS] SSI using rw-conflict lists

Well, it's been a productive holiday weekend. I've completed the switch of the SSI implementation from one conflict pointer in and one conflict pointer out per transaction to a list of conflicts between transactions. This eliminated all false positives in my dtester suite. The only test which ha

Re: [HACKERS] large page query

"Hamza Bin Sohail" wrote: > I was wondering if I could get to know whether Postgres > administrators configure the Postgres DBMS with large page support > for shared memory regions You might be interested in a recent thread in the -hackers archives which starts with this post: http://archive

Re: [HACKERS] SSI using rw-conflict lists

Heikki Linnakangas wrote: > Maybe invent a short name for PredLockTranList and/or the fields? Done: http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=44c8f221100b87fc7c23425f53f2fd38d735b7d2 > I'd suggest a union field. Done: http://git.postgresql.org/gitweb?

Re: [HACKERS] [PATCH] V3: Idle in transaction cancellation

Andres Freund wrote: > Ok, I implemented that capability I applied all three patches with minor offsets, and it builds, but several regression tests fail. I backed out the patches in reverse order and confirmed that while the regression tests pass without any of these patches, they fail with

<    3   4   5   6   7   8   9   10   11   12   >