Any idea if alter table drop column and background vacuum will be
implemented by 7.3?
It's really critical for large applications that must run 24/7.
Stephen
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unreg
run as long as it doesn't disrupt other queries. See my other post on
"VACUUM degrades performance significantly. Database becomes unusable!" on
pgsql-general mailing list.
Regards,
Stephen
"Tom Lane" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
] [THROTTLE] ANALYZE [ table [ (column
[, ...] ) ] ]
This way autovacuum can still throttle VACUUM as needed in future (either in
contrib or backend) and administrators can decide to apply different delays
for different tables depending on the usage.
Regards, Stephen
"Tom Lane" <[EMAIL PROT
Dear webmaster,
I tried contacting [EMAIL PROTECTED] twice about broken links on all
the top corner square ads at http://www.postgresql.org web site, but no one
seemed fix them for a very very long time. Hopefully this post will get to
the right channel.
Regards, Stephen
I'm using IE6 and it redirects back to http://www.postgresql.org. Mozilla
1.4 works fine.
Regards, Stephen
""Marc G. Fournier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> 'K, just tried Konqueror, and I get the same behaviour ...
d for different
tables that require different VACUUM priorities (eg. For small tables that
are rarely used, I rather vacuum with zero delay. For big tables, I'd set a
reasonable delay in vacuum and let it run through the day & nite).
Regards,
Stephen
"Tom Lane" <[EMAIL PRO
I tried the Tom Lane's patch on PostgreSQL 7.4-BETA-5 and it works
fantastically! Running a few short tests show a significant improvement in
responsiveness on my RedHat 9 Linux 2.4-20-8 (IDE 120GB 7200RPM UDMA5).
I didn't feel any noticeable delay when vacuum_page_delay is set to 5ms, 10
ms. Vac
will have a smaller
quantum:
http://go.jitbot.com/linux2.6-quantum
There is also mention of user-space tweak to get a more accurate time slice
of near 1ms on Linux, but I'm not sure how this works and if it applies to
Unixes:
http://go.jitbot.com/linux-devrtc-quantum
Regards, Stephen
&quo
isfied with the
responsiveness on large DBs using vacuum_page_delay=10ms delay.
Any ideas if this patch will be included into 7.4 before final release?
Stephen
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Not surprising, I should have thought
Yes, I would like to see the vacuum delay patch go into 7.4.1 if possible.
It's really useful. I don't think there is any major risk in adding the
delay patch into a minor revision given the small amount of code change.
Stephen
""Matthew T. O'Connor"" <[E
ckground through the
whole day. The delay should be optional and defaults to zero so those who
wish to backup immediately can still do it. The way I see it, routine
backups and vacuums should be ubiquitous once properly configured.
Regards,
Stephen
"Tom Lane" <[EMAIL PROTECT
every time VACUUM runs. Please let it be in 7.5.
Thanks.
Stephen
"Tom Lane" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> ow <[EMAIL PROTECTED]> writes:
> > Is this all that's planned for 7.5? (based on current TODO list)
>
> If you think the
almost there.
Will this problem get addressed in the not so official TODO list?
Thanks and keep up the good work!
Stephen
"Jan Wieck" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Tom Lane wrote:
> > Christopher Browne <[EMAIL PROTECTED]> writ
Hi,
Recently, I ran a huge update on an Integer column affecting 100 million
rows in my database. What happened was my disk space increased in size and
my IO load was very high. It appears that MVCC wants to rewrite each row
(each row was about 5kB due to a bytea column). In addition, VACUUM needs
and replace them with 'REVOKE EXECUTE FROM public'
commands, allowing users to then control what users are allowed to
execute those functions.
Started as a new thread to hopefully gain more interest. Will be
registered in the March commitfest shortly.
Thanks!
St
o patches, the
first to formally reserve 'pg_', the second to add the new default role.
Will add to the March commitfest for review.
Thanks!
Stephen
From 4a14522ec7ec7d25c3ce9d07f6525b76f6bab598 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Mon, 29 Feb 2016 21:27:46 -0500
Subject
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Per discussion about the best approach to reduce the amount of
> > superuser-only capabilities, this patch modifies pg_dump to dump out
> > all ACLs which exist on objects in the pg_catalog schema.
>
&
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> To make this work, you'd need a way to distinguish privileges installed
> >> by initdb from those changed later.
>
> > To replicate whatever t
gt; CREATE INDEX "index_cond_test_ranking" ON "index_cond_test" USING btree
> > (final_score DESC, time_taken ASC);
>
> > Run test query (will return all 1 rows)
>
> > SELECT *
> > FROM "index_cond_test"
> >
m the commit message, this seems much more likely to be
> the cause than does the buffer locking patch Stephen fingered. Stephen,
> how'd you identify 2ed5b87f as being the problem?
Badly. :)
I didn't expect it to be something that far back and was just going
backwards through re
efault ACLs are.
I don't see any reason it couldn't be used by extensions also, though
we'd have to do a bit more work on pg_dump to make it actually dump
out any non-default ACLs for extension-owned objects.
Thoughts?
Thanks!
Stephen
signature.asc
Description: Digital signature
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote:
> > Rather than have two aclitem[] columns in every catalog, since this
> > information is only used by pg_dump and not during normal operation, we
> > could
* Joe Conway (m...@joeconway.com) wrote:
> On 03/02/2016 12:54 PM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> On 03/01/2016 08:00 AM, Tom Lane wrote:
> >>> Yes, we'd need some way to mark non-null ACLs as being "built-in
> &g
ion"...
>
> Agreed. I think our answer there was always a bit of a cop out...
Agreed on this also.
Thanks!
Stephen
signature.asc
Description: Digital signature
nce they're
> > picking up a lot of our better features, like R support.
>
> IANAL, but I wonder how they can have R support given that libR.so is
> GPL licensed, not LPGL? Have they open sourced SQL Server?
I thought they had purchased/partnered with an R implemen
ich would require hand hacking
+* the catalog, currently), throwing the below error seems entirely
+* reasonable.
+*/
+ return;
else
write_msg(NULL, "WARNING: typtype of data type \"%s\" appears to be
invalid\n",
tyinfo->dobj.name);
I can certainly look at committing that independently from the other
pg_dump changes that I'm working on.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> pg_dump: WARNING: typtype of data type "any" appears to be invalid
>
> > This is fixed in my changes to pg_dump, though I didn't expect
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I think the real question is if "-n '*'" should still exclude
> > 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
> > but aren't you going to end up
as the default for some distributions.
Thanks!
Stephen
signature.asc
Description: Digital signature
w of those, I recommend we reject this.
> > > >
> > > > +1
> > >
> > > I'm meh for this patch.
> >
> > "meh" == +1
> >
> > I thought it meant -1
>
> I would say that "meh" is +0, actually. So the the tally is a small
> positive number -- not great, but seems enough to press forward unless
> we get more -1 votes.
I'm +1 on this also, for my part.
Thanks!
Stephen
signature.asc
Description: Digital signature
> columns, one that is expected to be frozen after initdb and one for
> user-added grants.
This is along the lines of what I've done, but I've used a new catalog
instead, which is quite small and doesn't complicate or change the
regular catalogs.
* Joe Conway (m...@joeconway.com
* Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
> On 15/03/2016 03:30, Peter Geoghegan wrote:
> > On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
> >> Attached patch fixes a bug reported privately by Stephen this morning.
> >
> > Bump.
> >
>
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
>
> > XLTW_InsertIndexUnique is used when building a unique index, but this is
> > just a check, and more to the point, it's actually
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Feb 29, 2016 at 10:02 PM, Stephen Frost wrote:
> > Attached is a stripped-down version of the default roles patch which
> > includes only the 'pg_signal_backend' default role. This provides the
> > framework
ns which follow our code changes and it makes it more
difficult on them to include whitespace/indentation changes with code
changes.
Thanks!
Stephen
signature.asc
Description: Digital signature
David and I'm not trying to force anything. It'd
certainly be nice to have and to be able to tell people that we do have
a strong and recognized approach to password-based authentication in PG,
but I've long been telling everyone that they should be using GSSAPI
and/or SSL and can continue to do so for another year if necessary.
Thanks!
Stephen
signature.asc
Description: Digital signature
ship has sailed.
Ultimately, I guess I'm inclined to leave it as-committed. If you
understand enough to realize what that pair of numbers after 'tuple'
means, you've probably found this thread and followed it enough to
understand what's happening.
I don't feel terribly strongly about that position and so if others
feel the XLTW_InsertIndexUnique message really would be better, I'd be
happy to commit the change.
Thanks!
Stephen
signature.asc
Description: Digital signature
EXISTS would imply that application authors would
be expected to run a set of PREPAREs at the start of each transaction
(if you want to support transaction pooling mode in, say, pgbouncer),
for each prepared statement they want to use in that transaction. That
doesn't seem completely unreasonable, but it'd need to be fast.
Thanks!
Stephen
signature.asc
Description: Digital signature
driver, I don't see why you wouldn't also make that a requirement
of the feature..? Or have the JDBC driver calculate a unique ID for
each statement using a good hash, perhaps?
Note: I don't pretend to have any clue as to the internals of the JDBC
driver, but it hardly seems far-fetched to have this be supported in a
way that works.
Thanks!
Stephen
signature.asc
Description: Digital signature
ll like the general idea of INE support for
PREPARE, but perhaps there's a better option.
Thanks!
Stephen
signature.asc
Description: Digital signature
bility we've had over the
years and is pretty far from the largest (string escaping, anyone? or
removing implicit casts?) and I'd argue we're better off for it.
Thanks!
Stephen
signature.asc
Description: Digital signature
er to commit the attached or not.
>
> +1 for commit - I'll trust Tom on the quality of the patch :)
I'm not going to object to it. All-in-all, I suppose '+0' from me.
Thanks!
Stephen
signature.asc
Description: Digital signature
are regular users but which no longer have a username, for folks who end
up in this situation that they managed to drop a role which still had
connections to the system.
Thanks!
Stephen
signature.asc
Description: Digital signature
s the versioning problem though, which is a problem
for all currently released versions of PG and is just going to continue
to be an issue.
Thanks!
Stephen
signature.asc
Description: Digital signature
n't
be terribly difficult to add.
Would you agree that it'd be helpful to have for making the st_union()
work better in parallel?
Though I do wonder if you would end up wanting to have a different
final() function in that case..
Thanks!
Stephen
signature.asc
Description: Digital signature
* Peter Geoghegan (p...@heroku.com) wrote:
> On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote:
> > If we're going to talk about minimum requirements, I'd like to argue
> > that we require whatever system we're using to have versioning (which
> > glibc
gt; > inside \set commands, but we might want it anyway for backward
> > compatibility.
> >
> > Anybody have an opinion on that?
>
> +1 for nuking it. That's not worth the trouble maintaining it.
If we don't nuke it, it'll never die.
See also: pg_shadow
Thanks!
Stephen
signature.asc
Description: Digital signature
the patch author on this e-mail
> I guess this should speed up reactions / make communication a
> bit more fluid.
This is almost a requirement, imv, as subsequent comments on the review
are frequent and it's a crime if the author misses all of that.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > As Stephen mentioned, yes, I am very interested in at least some aspects
> > of this patch. The ability to apply RLS to system tables could be useful
> > to solve a number of problems we don't have a good
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> However, by "not that much trouble" I only mean getting an implementation
> >> that works and doesn't create more security problems than it fix
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost writes:
> >>> I don't follow how this would destroy the ability to run pg_dump.
> >>> Ideally, we'd have a result wh
a bit off-the-cuff comments, but hopefully make sense and
provide the right direction to be looking in. The other thing to
consider is how this information is reflected in the CSV log and/or
log_line_prefix..
Thanks!
Stephen
signature.asc
Description: Digital signature
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > What I think we really want here is logging of the general 'system
> > user' for all auth methods instead of only for the 'peer' method.
>
> Well, we don't really know that
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those process
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > > pgbackrest:
> > > >
> > > > To run pgbackrest as a non-superuser and not the 'po
oing to make
sense is to add additional functions in some cases. In particular, we
will need alternate versions of pg_terminate_backend and
pg_cancel_backend. One thought I had was to make that
'pg_signal_backend', but that sounds like we'd allow any signal sent by
a user with that ri
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote:
> > Right, we also check in the backend on startup for certain permissions.
> > I don't recall offhand if that's forced to 700 or if we allow 750.
> >
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 06:58:25PM -0500, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other is
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote:
> > > While the group owner of the directory is a distributions question, the
> > > permissions are usually a backup-method-specific requirement. I can see
> > &g
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote:
> > > > Group ownership and permissions aren't a backup-method-specific
> > > > requirement either, in my view. I'm happy to chat with Marco (who has
&g
m and starting out w/ no rights granted to that function also
works).
Thanks!
Stephen
signature.asc
Description: Digital signature
0, an hour later than the
> stated move time. Did you mean the move will be Tue 19 Jan?
Yes. It'll be tomorrow.
Thanks!
Stephen
signature.asc
Description: Digital signature
José,
* José Arthur Benetasso Villanova (jose.art...@gmail.com) wrote:
> I wrote 2 possible patches, both issuing a detail message only if
> log_connections is enabled.
>
> The first one using the Stephen Frost suggestion, inside the Port struct (I
> guess that this is the one,
commits that are done by you is quite high.
>
> Yes, we are either all in or we may as well forgo this.
I don't have a particular issue with it, but would like whatever
template is decided upon to be included in our git repo and then we
should be able to make it the template that's opened up when people go
to commit pretty easily.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other issue tha
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote:
> > * Joshua D. Drake (j...@commandprompt.com) wrote:
> > > On 01/28/2016 06:57 AM, Robert Haas wrote:
> > >
> > > >>I'm on board with Bruce&
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost wrote:
> >> So, this seems like a case where a built-in role would be
> >> well-justified. I don't really believe in built-in roles as a way of
> >> bundling relate
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> wrote:
> >> > Personally, I don't
ult in a poorer solution, from a
technical perspective, than what this project is known for and capable
of. To make true progress towards that, however, we need to get past
the thinking that auditing doesn't need to be in-core or that it should
be a second-class citizen feature or that we don't need it in PG.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Joe Conway (m...@joeconway.com) wrote:
> On 02/05/2016 10:16 AM, Stephen Frost wrote:
> > An in-core auditing solution would provide us with proper grammar
> > support, ability to directly mark objects for auditing in the catalog,
> > allow us to much more easily maintai
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm of the opinion that this is a stop-ship bug for 9.5.1. Barring
> somebody producing a fix over the weekend, I will deal with it by
> reverting the aforementioned commit.
Agreed.
Thanks!
Stephen
signature.asc
Description: Digital signature
7;s a thread from a few years back about something similar:
http://www.postgresql.org/message-id/flat/20110112142345.ga4...@tamriel.snowman.net
Included in that thread is a patch, which likely requires some dusting
off, to add exactly that ability.
Thanks!
Stephen
signature.asc
Description: Digital signature
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> > On 02/09/2016 11:47 AM, Robert Haas wrote:
> >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
> >>>> Whereupon you'd have no cer
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> pg_dump -U $non-super_user
>
> Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Thanks!
Stephen
signature.asc
D
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> > To the extent that untrusted code execution is an issue (and my
> > experience with environments which would deploy RLS tells me that it
> > isn't a practical co
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake (j...@commandprompt.com) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed
te system_row_security
> setting that controls RLS on the system catalogs, and that it should
> be on by default in pg_dump.
Right, that's what I had been thinking also.
Thanks (and congrats, btw!),
Stephen
signature.asc
Description: Digital signature
ended in ways that make pg_dump unsafe to
> use.
I'm not against coming up with an approach which restricts cases where
user A can write code that will be run under another user's rights,
provided it doesn't make the system overly painful to use. I don't see
RLS as
le for schemas, perhaps it'd make sense to have another field
in pg_namespace instead? Not sure, just brainstorming here.
Thanks!
Stephen
signature.asc
Description: Digital signature
or such. Makes it less clear what to do with the
> lsn admittedly.
If we make the 'client disconnect means abort' optional then we'd also
need to modify the API of stop backup to specify which backup to stop,
I'd think.
Thanks!
Stephen
signature.asc
Description: Digital signature
it's worth all that work and complexity.
Hrmmm. If that's the case then perhaps you're right. I liked the
general idea of not having to maintain a TCP connection during the
entire backup (TCP connections can be annoyingly finicky in certain
environments...), but I'm not sure it's worth a lot of additional
complexity.
Thanks!
Stephen
signature.asc
Description: Digital signature
* David Steele (da...@pgmasters.net) wrote:
> On 2/10/16 9:44 AM, Stephen Frost wrote:
> > Hrmmm. If that's the case then perhaps you're right. I liked the
> > general idea of not having to maintain a TCP connection during the
> > entire backup (TCP connectio
Greetings,
The way permissions on catalog objects are handled isn't discussed at
all in the documentation. Barring objections, I'll commit and
back-patch the attached to improve that situation in the next day or so.
Thanks!
Stephen
From ad8e663893ea906238a9c0346bf8791eafe3d333 Mon Se
it being an idea to use this for the
pg_dump case. I do know that's a case which has been brought up a
couple of times before.
> To do this it'd have to be possible to add an existing session/xact to a
> lock group (or make it the leader of a new lock group then join tha
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Feb 13, 2016 at 3:05 AM, David Steele wrote:
> > On 11/16/15 8:53 AM, Michael Paquier wrote:
> >> On Sat, Sep 5, 2015 at 9:31 AM, Bruce Momjian wrote:
> >>> On Fri, Sep 4, 2015 at 04:51:3
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Feb 15, 2016 at 9:17 AM, Stephen Frost wrote:
> > That said, per various discussions, we'd really want a more-or-less
> > fully formed patch to land prior to the last CF, for this to have any
> > c
simply nuke them
and expect applications to use the new catalogs. Perhaps there is a
useful view or two which we can provide over the new catalogs, but I'd
rather consider how to create brand new, useful, views over the new
catalogs than consider any kind of way to provides backwards
compati
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Why do we need pg_shadow or pg_user or related views at all..?
>
> A lot of code looks at those just to get usernames. I am not in favor of
> breaking such stuff without need.
Alright.
> How about we just
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Feb 15, 2016 at 10:23 AM, Stephen Frost wrote:
> > I would start by pointing out that pg_user currently uses pg_shadow..
> > Why do we need pg_shadow or pg_user or related views at all..?
>
> pg_user/pg_shadow
ich mentions it would be fine, of course.
Thanks!
Stephen
signature.asc
Description: Digital signature
n (and I'm not
convinced that they're actually useful at all), then we need to provide
a way for users and distributions to control the specifics of the checks
as they chose. Maybe that's a command-line switch instead of a GUC, or
it's something else, but there clearly isn'
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Further, the notion that *this* is the footgun is completely off the
> > reservation- if the files have been changed to allow untrusted users to
> > have access to them, there isn't diddly
d for taking this approach, or
that OpenSSL is flawed for not having such a check.
Thanks!
Stephen
signature.asc
Description: Digital signature
x27;s possible this was
identified as an issue in pg_config.c, but, as Tom notes, it may not be
an actual bug and might have been marked as a non-bug in Coverity.
Thanks!
Stephen
signature.asc
Description: Digital signature
t
shouldn't be a precedent or limit us from supporting more permissive
permissions in other areas (or even here) if there are sensible
use-cases for more permissive permissions.
Thanks!
Stephen
signature.asc
Description: Digital signature
factor compared to all the
> other costs of setting up and tearing down parallel workers.)
This is only when a parallel worker is finished, no? Isn't there
already some indication of when a parallel worker is done that the
master handles, where it could also check the shared lock table and see
if any locks were transferred to it on worker exit?
Only following this thread from afar, so take my suggestions with a
grain of salt.
Thanks!
Stephen
signature.asc
Description: Digital signature
erent this is from simply bringing
PG up as a warm standby instead, with the warning added to indicate if
the recovery point wasn't reached.
Thanks!
Stephen
signature.asc
Description: Digital signature
nd then doing an update
of it using rsync. or something along those lines, as you can't really
trust rsync's time/size based comparison as it only has a 1 second level
granularity.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost wrote:
> > * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensu
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 8/17/16 9:46 PM, Stephen Frost wrote:
> >* Jim Nasby (jim.na...@bluetreble.com) wrote:
> >>> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> >>> not specify -c for any of the rsync commands. Tha
1 - 100 of 4541 matches
Mail list logo
