On 10/17/2014 02:49 AM, Robert Haas wrote:
> I think you could probably make the DELETE policy control what can get
> deleted, but then have the SELECT policy further filter what gets
> returned.
That seems like the worst of both worlds to me.
Suddenly DELETE ... RETURNING might delete more rows
Hello,
Please find the updated patch attached.
>1) I don't think it's a good idea to put the full page write compression
into struct XLogRecord.
1. The compressed blocks is of varlena type. Hence, VARATT_IS_COMPRESSED
can be used to detect if the datum is compressed. But, it can give false
po
>
>
>
>
>> We might as well allow a final trailing (or initial leading) comma on a
>> values list at the same time:
>>
>> VALUES
>> (...),
>> (...),
>> (...),
>>
>
>
> do you know, so this feature is a proprietary and it is not based on
> ANSI/SQL? Any user, that use this feature and will to
Tom Lane-2 wrote
> Jim Nasby <
> Jim.Nasby@
> > writes:
>> Something else mentioned was that once you start a smart shutdown you
>> have no good way (other than limited ps output) to see what the shutdown
>> is waiting on. I'd like to have some way to get back into the database
>> to see what's g
2014-10-17 6:34 GMT+02:00 David G Johnston :
> Jim Nasby-5 wrote
> > On 10/3/14, 4:02 PM, David G Johnston wrote:
> >> Should we also allow:
> >>
> >> SELECT
> >> , col1
> >> , col2
> >> , col3
> >> FROM ...
> >>
> >> ?
> > I would say yes, if we're going to do this. I don't see it being any
> wor
Jim Nasby-5 wrote
> On 10/3/14, 4:02 PM, David G Johnston wrote:
>> Should we also allow:
>>
>> SELECT
>> , col1
>> , col2
>> , col3
>> FROM ...
>>
>> ?
> I would say yes, if we're going to do this. I don't see it being any worse
> than trailing commas.
>
> If we are going to do this, we need to d
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> But TBH I suspect 95% of the problems here would vanish if smart
> shutdown weren't the default ...
+1000 ...
Thanks!
Stephen
signature.asc
Description: Digital signature
On Fri, Oct 17, 2014 at 12:19 AM, Robert Haas wrote:
> On Wed, Oct 15, 2014 at 1:06 AM, Andres Freund
> wrote:
> > I personally think we should just disregard the race here and add a
> > snapshot parameter. The race is already there and not exactly
> > small. Let's not kid ourselves that hiding
Jim Nasby writes:
> Something else mentioned was that once you start a smart shutdown you
> have no good way (other than limited ps output) to see what the shutdown
> is waiting on. I'd like to have some way to get back into the database
> to see what's going on. Perhaps we could allow superusers
On 09/18/2014 05:58 PM, Andres Freund wrote:
> I don't think we need to make any discinction between psql -f mydb.dump,
> psql < mydb.dump, and whatever | psql. Just check, when noninteractively
> reading the first line in mainloop.c:MainLoop(), whether it starts with
> the magic header. That'd als
On Thu, Oct 16, 2014 at 11:16 AM, Rushabh Lathia
wrote:
>
> PFA patch patch for the master branch.
I think you should upload this patch to CF to avoid getting it
lost.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On 08/10/2014 07:48 PM, Craig Ringer wrote:
> Hi all
>
> I just had an idea I wanted to run by you all before turning it into a
> patch.
>
> People seem to get confused when they get auth errors because they
> changed pg_hba.conf but didn't reload.
>
> Should we emit a HINT alongside the main au
On 10/17/2014 03:59 AM, Jim Nasby wrote:
> Over in the "Log notice that checkpoint is to be written on shutdown"
> thread...
>
> On 10/16/14, 2:31 PM, Michael Banck wrote:
>> There were some comments that this might not actually be the case and/or
>> that the postmaster was simply waiting for clie
On Thu, Oct 16, 2014 at 6:53 PM, Andres Freund wrote:
> When using shared_buffers = 96GB there's a performance benefit, but not
> huge:
> master (f630b0dd5ea2de52972d456f5978a012436115e): 153621.8
> master + LW_SHARED + lockless StrategyGetBuffer(): 477118.4
> master + L
Hi,
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
> A few years ago I started working on a concurrent hash table for
> PostgreSQL. The hash table part of it worked, but I never did
> anything with it, really. Amit mentioned to me earlier this week that
> he was seeing contention inside the dy
Thanks for the review.
On 16 October 2014 23:23, MauMau wrote:
> (3)
> SELECT against a view generated two audit log lines, one for the view
> itself, and the other for the underlying table. Is this intended? I'm not
> saying that's wrong but just asking.
Intended
> (4)
> I'm afraid audit-lo
Hello,
I had a quick look through the code and did some testing. Let me give you
some comments. I will proceed with checking if pgaudit can meet PCI DSS
requirements.
By the way, I'd like to use pgaudit with 9.2. Is it possible with a slight
modification of the code? If it is, what featu
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost wrote:
>
> > > My feeling is basically this- either we make a clean break to the new
> > > syntax and catalog representation, or we just use the same approach the
> > > exist
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 16 October 2014 20:37, Stephen Frost wrote:
>
> >> How about
> >>
> >> GRANT EXECUTE [PRIVILEGES] ON CAPABILITY foo TO bar;
> >>
> >> That is similar to granting execution privs on a function. And I think
> >> gets round the keyword issue?
> >
> >
Robert Haas wrote:
> On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost wrote:
> > My feeling is basically this- either we make a clean break to the new
> > syntax and catalog representation, or we just use the same approach the
> > existing attriubtes use. Long term, I think your proposed syntax an
On 16 October 2014 20:37, Stephen Frost wrote:
>> How about
>>
>> GRANT EXECUTE [PRIVILEGES] ON CAPABILITY foo TO bar;
>>
>> That is similar to granting execution privs on a function. And I think
>> gets round the keyword issue?
>
> No, it doesn't.. EXECUTE isn't reserved at all.
Yet GRANT EXEC
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost wrote:
> > My feeling is basically this- either we make a clean break to the new
> > syntax and catalog representation, or we just use the same approach the
> > existing attriubtes use. Long term, I thin
On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Oct 16, 2014 at 3:09 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER
>> >> ROLE .
On Wed, Oct 15, 2014 at 2:03 AM, Andres Freund wrote:
> Yes, I can see that now. I do wonder if that's not going to prove quite
> expensive... I think I can see some ways around needing that. But I
> think that needs some benchmarking first - no need to build a even more
> complex solution if not
Hello
I checked this patch.
1. There is a consensus we want this feature.
2. This patch implement just this mentioned feature. There is no objection
against design.
3. It is possible to apply this patch and compile without warnings.
4. I tested null stripping on large json, jsonb values withou
On 16 October 2014 15:09, Amit Kapila wrote:
>> Just send a message to autovacuum to request an immediate action. Let
>> it manage the children and the tasks.
>>
>>SELECT pg_autovacuum_immediate(nworkers = N, list_of_tables);
>>
>> Request would allocate an additional N workers and immediatel
Over in the "Log notice that checkpoint is to be written on shutdown" thread...
On 10/16/14, 2:31 PM, Michael Banck wrote:
> There were some comments that this might not actually be the case and/or
> that the postmaster was simply waiting for clients to disconnect due to
> smart shutdown being in
On 10/16/14, 10:47 AM, Stephen Frost wrote:
As others have commented, I too think this should support pg_dump.
> >
> >I'm uttly mystified as to what that*means*. Everyone asking for it is
> >great but until someone can define what "support pg_dump" means, there's
> >not much progress I can make
>
> I'll break them into three pieces- superuser() cleanup, GetUserId() ->
> has_privs_of_role(), and the additional-role-attributes patch will just
> depend on the others.
>
The superuser() cleanup has already been submitted to the current
commitfest.
https://commitfest.postgresql.org/action/pat
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 16 October 2014 20:04, Robert Haas wrote:
> >>> GRANT CAPABILITY whatever TO somebody;
> >>
> >> So, we went back to just role attributes to avoid the keyword issue..
> >> The above would require making 'CAPABILITY' a reserved word, and there
> >>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 16, 2014 at 3:09 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER
> >> ROLE .. [ ADD | DROP ] CAPABILITY x. That would still require maki
On 16 October 2014 20:04, Robert Haas wrote:
>>> I'd suggest calling these capabilities, and allow:
>>>
>>> GRANT CAPABILITY whatever TO somebody;
>>
>> So, we went back to just role attributes to avoid the keyword issue..
>> The above would require making 'CAPABILITY' a reserved word, and there
On Wed, Oct 15, 2014 at 11:41 AM, Sawada Masahiko
wrote:
>
> On Mon, Oct 13, 2014 at 11:16 PM, Robert Haas
wrote:
> > On Sun, Oct 12, 2014 at 1:27 PM, Stephen Frost
wrote:
> >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >>> Sawada Masahiko wrote:
> >>> > Attached WIP patch adds new syn
On Thu, Oct 16, 2014 at 3:09 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER
>> ROLE .. [ ADD | DROP ] CAPABILITY x. That would still require making
>> CAPABILITY a keyword, but it could be unreserve
Hi,
Am Donnerstag, den 02.10.2014, 15:21 +0200 schrieb Michael Banck:
> we have seen repeatedly that users can be confused about why PostgreSQL
> is not shutting down even though they requested it. Usually, this is
> because `log_checkpoints' is not enabled and the final checkpoint is
> being wri
* Robert Haas (robertmh...@gmail.com) wrote:
> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER
> ROLE .. [ ADD | DROP ] CAPABILITY x. That would still require making
> CAPABILITY a keyword, but it could be unreserved.
That works for me- would we change the existing role att
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm not sure what your point is. Whether keeping changes separate is
> easy or hard, and whether things overlap with multiple other things or
> just one, we need to make the effort to do it.
What I was getting at is that the role attributes patch wou
On Thu, Oct 16, 2014 at 2:59 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera
>> wrote:
>> > To me, what this repeated discussion on this particular BACKUP point
>> > says, is that the ability to run pg_start/stop_backend
On Thu, Oct 16, 2014 at 11:39 AM, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 2:01 PM, Peter Geoghegan wrote:
>> I want to retain CONFLICTING(), although I'm thinking about changing
>> the spelling to EXCLUDED(). While CONFLICTING() is more or less a new
>> and unprecedented style of expression,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera
> wrote:
> > To me, what this repeated discussion on this particular BACKUP point
> > says, is that the ability to run pg_start/stop_backend and the xlog
> > related functions should be a different pri
>> That's an argument in favour of only applying a read-filtering policy
>> where a RETURNING clause is present, but that introduces the "surprise!
>> the effects of your DELETE changed based on an unrelated clause!" issue.
>
> No- if we were going to do this, I wouldn't want to change the existing
On Thu, Oct 16, 2014 at 11:28 AM, Stephen Frost wrote:
> On Thursday, October 16, 2014, Robert Haas wrote:
>>
>> On Thu, Oct 16, 2014 at 9:49 AM, Stephen Frost wrote:
>> > As a side-note, this change is included in the 'role attributes' patch.
>>
>> It's really important that we keep separate ch
On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>> * Petr Jelinek (p...@2ndquadrant.com) wrote:
>> > On 15/10/14 07:22, Stephen Frost wrote:
>> > > First though, the new privileges, about which the bikeshedding can
>> > > begin, short-and-sweet format:
>> > >
>>
On Thu, Oct 16, 2014 at 2:01 PM, Peter Geoghegan wrote:
> I want to retain CONFLICTING(), although I'm thinking about changing
> the spelling to EXCLUDED(). While CONFLICTING() is more or less a new
> and unprecedented style of expression, and in general that's something
> to be skeptical of, I th
On Thu, Oct 16, 2014 at 11:01 AM, Peter Geoghegan wrote:
> It is? In any case, I'm working on a revision with this syntax:
By the way, in my next revision, barring any objections, the ON
CONFLICT (column/expression) syntax is mandatory in the case of ON
CONFLICT UPDATE, and optional in the case o
On Thu, Oct 16, 2014 at 12:26 PM, Ryan Johnson
wrote:
> The only metric where RCU loses to
> hazard pointers is if you have really tight timing constraints on resource
> reclamation.
I think we do have that problem. It's certainly completely
unacceptable for a query to prevent buffer reclaim on
I just tripped over that CommitFest mace that went missing after
Heikki put it down from the last CF. Unless someone else wants to
pick it up, I'll manage this one.
Just to get the ball rolling, I note that 19 patches were moved to
this CF from the last one. These are in the following states:
C
On Thu, Oct 16, 2014 at 6:48 AM, Robert Haas wrote:
> If that seems too complicated, leave it out for v1: just insist that
> there must be at least one unique non-partial index on the relevant
> set of columns.
That's what I'll do.
> There seems to be some confusion here. This part was about th
On Oct 15, 2014 7:32 PM, "Ants Aasma" wrote:
> I'm imagining a bucketized cuckoo hash with 5 item buckets (5-way
> associativity). This allows us to fit the bucket onto 2 regular sized
> cache lines and have 8 bytes left over. Buckets would be protected by
> seqlocks stored in the extra space. On
On 16/10/2014 7:59 AM, Robert Haas wrote:
On Thu, Oct 16, 2014 at 9:30 AM, Andres Freund wrote:
On 2014-10-16 09:19:16 -0400, Robert Haas wrote:
On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
wrote:
Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
an ideal fit...
In
Ronan Dunklau writes:
> From my point of view as a FDW implementor, the feature I need is to have
> EXPLAIN (COSTS ON) with stable output for foreign scan nodes.
Well, as long as the FDW's costing is exactly predictable, you can have
that ...
> In the Multicorn FDW (Python API on top of the C-A
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane wrote:
> > "Brightwell, Adam" writes:
> >> The attached patch for review implements a directory permission system that
> >> allows for providing a directory read/write capability to directories for
> >> COPY
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Petr Jelinek (p...@2ndquadrant.com) wrote:
> > > On 15/10/14 07:22, Stephen Frost wrote:
> > > > First though, the new privileges, about which the bikeshedding can
> > > > begin, short-and-sweet format:
> >
On 16/10/2014 7:19 AM, Robert Haas wrote:
On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
wrote:
Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
an ideal fit...
In brief, RCU has the following requirements:
Read-heavy access pattern
Writers must be able to make dead o
Robert,
On Thursday, October 16, 2014, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 9:49 AM, Stephen Frost > wrote:
> > As a side-note, this change is included in the 'role attributes' patch.
>
> It's really important that we keep separate changes in separate
> patches that are committed in sep
Stephen Frost wrote:
> * Petr Jelinek (p...@2ndquadrant.com) wrote:
> > On 15/10/14 07:22, Stephen Frost wrote:
> > > First though, the new privileges, about which the bikeshedding can
> > > begin, short-and-sweet format:
> > >
> > > BACKUP:
> > > pg_start_backup()
> > > pg_stop_backu
On Wed, Oct 15, 2014 at 2:55 PM, Simon Riggs wrote:
> On 15 October 2014 17:03, Robert Haas wrote:
>> Well, I'm fervently in agreement with you on one point: the first
>> version of all this needs to be as simple as possible, or the time to
>> get to the first version will be longer than we can a
On Wed, Oct 15, 2014 at 1:06 AM, Andres Freund wrote:
> I personally think we should just disregard the race here and add a
> snapshot parameter. The race is already there and not exactly
> small. Let's not kid ourselves that hiding it solves anything.
I, too, favor that plan.
--
Robert Haas
En
On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane wrote:
> "Brightwell, Adam" writes:
>> The attached patch for review implements a directory permission system that
>> allows for providing a directory read/write capability to directories for
>> COPY TO/FROM and Generic File Access Functions to non-super
On Thu, Oct 16, 2014 at 9:49 AM, Stephen Frost wrote:
> As a side-note, this change is included in the 'role attributes' patch.
It's really important that we keep separate changes in separate
patches that are committed in separate commits. Otherwise, it gets
really confusing.
--
Robert Haas
En
Le jeudi 16 octobre 2014 10:43:25 Robert Haas a écrit :
> On Thu, Oct 16, 2014 at 10:06 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Oct 14, 2014 at 3:03 AM, David Rowley
wrote:
> >>> Hmm, was my case above not compelling enough?
> >>
> >> Apparently not to Tom, but it made sense t
On Thu, Oct 16, 2014 at 10:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 14, 2014 at 3:03 AM, David Rowley wrote:
>>> Hmm, was my case above not compelling enough?
>
>> Apparently not to Tom, but it made sense to me.
>
> No, it wasn't. I'm not convinced either that that patch will
Andres Freund writes:
> On 2014-10-16 10:06:59 -0400, Tom Lane wrote:
>> No, it wasn't. I'm not convinced either that that patch will get in at
>> all, or that it has to have regression tests of that particular form,
>> or that such a switch would be sufficient to make such tests platform
>> inde
On 2014-10-16 10:06:59 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Oct 14, 2014 at 3:03 AM, David Rowley wrote:
> >> Hmm, was my case above not compelling enough?
>
> > Apparently not to Tom, but it made sense to me.
>
> No, it wasn't. I'm not convinced either that that patch will
On Thu, Oct 16, 2014 at 1:56 PM, Simon Riggs wrote:
> On 16 October 2014 06:05, Amit Kapila wrote:
> > On Thu, Oct 16, 2014 at 8:08 AM, Simon Riggs
wrote:
> >>
> >> This patch seems to allow me to run multiple VACUUMs at once. But I
> >> can already do this, with autovacuum.
> >>
> >> Is there a
Robert Haas writes:
> On Tue, Oct 14, 2014 at 3:03 AM, David Rowley wrote:
>> Hmm, was my case above not compelling enough?
> Apparently not to Tom, but it made sense to me.
No, it wasn't. I'm not convinced either that that patch will get in at
all, or that it has to have regression tests of t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Petr Jelinek (p...@2ndquadrant.com) wrote:
> >> Yeah it will, mainly because extensions can load modules and can
> >> have untrusted functions, we might want to limit which extensions
> >> are possible to create without being sup
On Thu, Oct 16, 2014 at 9:30 AM, Andres Freund wrote:
> On 2014-10-16 09:19:16 -0400, Robert Haas wrote:
>> On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
>> wrote:
>> > Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
>> > an ideal fit...
>> >
>> > In brief, RCU has the
Stephen Frost writes:
> * Petr Jelinek (p...@2ndquadrant.com) wrote:
>> Yeah it will, mainly because extensions can load modules and can
>> have untrusted functions, we might want to limit which extensions
>> are possible to create without being superuser.
> The extension has to be available on t
Andrew Gierth writes:
> "Bruce" == Bruce Momjian writes:
> Bruce> Uh, did this ever get addressed?
> It did not.
It dropped off the radar screen (I think I'd assumed the patch would
appear in the next commitfest, which it didn't unless I missed something).
I'll make a note to look at it once
On Tue, Oct 14, 2014 at 3:03 AM, David Rowley wrote:
>> Andres Freund writes:
>> > Well. Unless I miss something it doesn't resolve the problem that
>> > started this thread. Namely that it's currently impossible to write
>> > regression using EXPLAIN (ANALYZE, TIMING OFF. COSTS OFF). Which is
>>
One of the queries in ri_triggers.c has be a little baffled.
For (relatively) obvious reasons, a FK insert triggers a SELECT 1 FROM
pk_rel ... FOR KEY SHARE.
For not-so-obvious reasons, a PK delete triggers a SELECT 1 FROM fk_rel ...
FOR KEY SHARE.
I can't see what the lock on fk_rel achieves. Bo
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 9/24/14 4:58 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> I think the case for pgstat_get_backend_current_activity() and
> >> pg_stat_get_activity and the other pgstatfuncs.c callers is easy to make
> >> and se
On Mon, Oct 13, 2014 at 2:02 PM, Peter Geoghegan wrote:
>> If the user issues INSERT .. ON DUPLICATE (a) UPDATE, we'll fire
>> before-insert triggers and then inspect the tuple to be inserted. If
>> b is neither 1 nor 2, then we'll fail with an error saying that we
>> can't support ON DUPLICATE w
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/10/14 8:44 PM, Stephen Frost wrote:
> > As a comparison, what about unlogged tables? They're not normal tables
> > and they aren't defined by the SQL standard either.
>
> They are normal tables when considered within the scope of the SQL
> stand
Answering your first question: running tpcc for 1 minute, in a database
with 64 warehouses (6~7GB), with a buffer pool of 128MB (around 1.8% of
database size) and a hit ratio of ~91%, I get a throughput of 45~50
transactions per second.
I did some experiments and I got the following information ab
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 16 October 2014 12:59, Stephen Frost wrote:
> >> > LOGROTATE:
> >> > pg_rotate_logfile()
> >>
> >> Do we need one just for that?
> >
> > It didn't seem to "belong" to any others and it's currently limited to
> > superuser but useful for non-s
On 2014-10-16 09:19:16 -0400, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
> wrote:
> > Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
> > an ideal fit...
> >
> > In brief, RCU has the following requirements:
> >
> > Read-heavy access pattern
> > W
* Petr Jelinek (p...@2ndquadrant.com) wrote:
> The explanation you wrote to Jim makes sense, plus given the comment
> from Magnus about REPLICATION flag I guess I am happy enough with it
> (I might have liked to have REPLICATION flag to somehow be part of
> BACKUP flag but that's very minor thing).
On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
wrote:
> Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
> an ideal fit...
>
> In brief, RCU has the following requirements:
>
> Read-heavy access pattern
> Writers must be able to make dead objects unreachable to new readers
* Magnus Hagander (mag...@hagander.net) wrote:
> On Oct 16, 2014 1:59 PM, "Stephen Frost" wrote:
> > Once I understand what "include pg_dump" and "include pg_basebackup"
> > mean, I'd be happy to work on adding those.
>
> Include pg_basebackup would mean the replication protocol methods for base
On 16 October 2014 12:59, Stephen Frost wrote:
>> > LOGROTATE:
>> > pg_rotate_logfile()
>>
>> Do we need one just for that?
>
> It didn't seem to "belong" to any others and it's currently limited to
> superuser but useful for non-superusers, so I would argue 'yes'. Now,
> another option (a
On 16/10/14 13:44, Stephen Frost wrote:
* Petr Jelinek (p...@2ndquadrant.com) wrote:
On 15/10/14 07:22, Stephen Frost wrote:
First though, the new privileges, about which the bikeshedding can
begin, short-and-sweet format:
BACKUP:
pg_start_backup()
pg_stop_backup()
pg_s
On Oct 16, 2014 1:59 PM, "Stephen Frost" wrote:
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > On 15 October 2014 06:22, Stephen Frost wrote:
> > > BACKUP:
> > > pg_start_backup()
> > > pg_stop_backup()
> > > pg_switch_xlog()
> > > pg_create_restore_point()
> >
> > Yes, bu
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 10/15/14, 12:22 AM, Stephen Frost wrote:
> > BACKUP:
> > pg_start_backup()
> > pg_stop_backup()
> > pg_switch_xlog()
> > pg_create_restore_point()
>
> It seems odd to me that this (presumably) supports PITR but not pg_dump*
On 2014-10-16 08:04:17 -0400, Jan Wieck wrote:
> Hi,
>
> PostgreSQL has for ages defined INT64_FORMAT and UINT64_FORMAT in
> pg_config.h. This commit
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ce486056ecd28050
>
> moved those definitions to c.h, which breaks compilation of
Hi,
PostgreSQL has for ages defined INT64_FORMAT and UINT64_FORMAT in
pg_config.h. This commit
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ce486056ecd28050
moved those definitions to c.h, which breaks compilation of all released
Slony-I versions against current master. Can
On 15/10/2014 11:41 AM, Robert Haas wrote:
On Wed, Oct 15, 2014 at 2:03 AM, Andres Freund wrote:
On 2014-10-14 17:53:10 -0400, Robert Haas wrote:
On Tue, Oct 14, 2014 at 4:42 PM, Andres Freund wrote:
The code in CHashSearch shows the problem there: you need to STORE the
hazard pointer before
On Thu, Oct 16, 2014 at 7:09 PM, Simon Riggs wrote:
> I find it confusing that the "Lowest" pointer value is also "Invalid".
> Valid != Invalid
>
In complement to that, note that I mentioned Invalid should be UINT_MAX for
clarity.
--
Michael
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 15 October 2014 06:22, Stephen Frost wrote:
> > BACKUP:
> > pg_start_backup()
> > pg_stop_backup()
> > pg_switch_xlog()
> > pg_create_restore_point()
>
> Yes, but its more complex. As Jim says, you need to include pg_dump,
> plus
2014-10-15 23:49 GMT+02:00 Andrew Dunstan :
>
> On 10/15/2014 05:47 PM, Alvaro Herrera wrote:
>
>> Andrew Dunstan wrote:
>>
>> If we really want to change the name of json_object_two_arg, it
>>> would probably be best to change it NOW in 9.4 before it gets out
>>> into a production release at all
* Petr Jelinek (p...@2ndquadrant.com) wrote:
> On 15/10/14 07:22, Stephen Frost wrote:
> > First though, the new privileges, about which the bikeshedding can
> > begin, short-and-sweet format:
> >
> > BACKUP:
> > pg_start_backup()
> > pg_stop_backup()
> > pg_switch_xlog()
> >
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 10/16/2014 01:44 PM, Craig Ringer wrote:
> > So the read-filtering policy should apply to all statements. Not just
> > SELECT.
>
> Oh, IIRC one wrinkle in the prior discussion about this was that doing
> this will prevent the implementation of pol
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek :
> On 09/09/14 17:37, Pavel Stehule wrote:
>
>> Ada is language with strong character, and PLpgSQL is little bit strange
>> fork - so it isn't easy to find some form, how to solve all requirements.
>>
>> My requests:
>>
>> * be consistent with current P
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> While I was checking the behavior of RLS, I found that the policy for SELECT
> doesn't seem to be applied to RETURNING. Is this intentional? Please see
> the following example.
Yes, it was intentional. That said, I'm not against changing it.
On 15/10/14 07:22, Stephen Frost wrote:
First though, the new privileges, about which the bikeshedding can
begin, short-and-sweet format:
BACKUP:
pg_start_backup()
pg_stop_backup()
pg_switch_xlog()
pg_create_restore_point()
As others have commented, I too think th
> "Bruce" == Bruce Momjian writes:
Bruce> Uh, did this ever get addressed?
It did not.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 15 October 2014 06:22, Stephen Frost wrote:
> BACKUP:
> pg_start_backup()
> pg_stop_backup()
> pg_switch_xlog()
> pg_create_restore_point()
Yes, but its more complex. As Jim says, you need to include pg_dump,
plus you need to include the streaming utilities, e.g. pg_baseback
On 9 October 2014 20:01, Robert Haas wrote:
> OK, here's an attempt at a real patch for that. I haven't perf-tested this.
Patch looks good to me. Surprised we didn't do that before.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
On 12 September 2014 13:16, Michael Paquier wrote:
> On Fri, Sep 12, 2014 at 4:55 PM, Heikki Linnakangas
> wrote:
>> I haven't looked at those places closely, but it seems possible that at
>> least some of those variables are supposed to be initialized to a value
>> smaller than any valid WAL pos
1 - 100 of 108 matches
Mail list logo
