On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby wrote:
>
> I'm surprised to see that the docs make no mention of how
max_connections, max_worker_processes and autovacuum_max_workers (don't)
relate. I couldn't remember and had to actually look at the code. I'd like
to clarify this in the max_connecitons
On Sat, Jan 10, 2015 at 2:45 AM, Stefan Kaltenbrunner
wrote:
>
> On 01/09/2015 08:01 PM, Stephen Frost wrote:
> > Amit,
> >
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> On Fri, Jan 9, 2015 at 1:02 AM, Jim Nasby
wrote:
> >>> I agree, but we should try and warn the user if they set
> >>>
On Fri, Jan 9, 2015 at 10:54 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > In our case as currently we don't have a mechanism to reuse parallel
> > workers, so we need to account for that cost as well. So based on that,
> > I am planing to add three new parameters
2015-01-10 9:56 GMT+09:00 Jim Nasby :
> On 1/9/15, 6:54 PM, Jim Nasby wrote:
>>
>> On 1/9/15, 6:44 PM, Petr Jelinek wrote:
>
>
Yep, I had a same impression when I looked at the code first time,
however, it is defined as below. Not a manner of custom-scan itself.
/*
> On Fri, Jan 9, 2015 at 9:23 PM, Tatsuo Ishii wrote:
>> This is because gen_db_file_maps() allocates memory even if n_maps == 0.
> Purely cosmetic: the initialization n_maps = 0 before the call of
> gen_db_file_maps is unnecessary ;)
Of course. n_maps is written by calling gen_db_file_maps() any
On 2014-11-17 18:22:54 +0300, Alex Shulgin wrote:
>
> Andres Freund writes:
> >
> > I've invested some more time in this:
> > 0002 now makes sense on its own and doesn't change anything around the
> > interrupt handling. Oh, and it compiles without 0003.
>
> In this patch, the endif appears
> On Jan 9, 2015, at 11:37 AM, Andrew Dunstan wrote:
>
>
> On 01/08/2015 08:42 PM, Aaron Botsis wrote:
>>
>>> On Jan 8, 2015, at 3:44 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/08/2015 03:05 PM, Aaron Botsis wrote:
> It's also unnecessary. CSV format, while not designed for this,
On 1/6/15, 6:15 PM, Tom Lane wrote:
Jim Nasby writes:
On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:
I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?
+1
Unless either o
On 1/9/15, 6:54 PM, Jim Nasby wrote:
On 1/9/15, 6:44 PM, Petr Jelinek wrote:
Yep, I had a same impression when I looked at the code first time,
however, it is defined as below. Not a manner of custom-scan itself.
/*
* ==
* Scan nodes
* ==
*/
typedef struct Scan
{
On 1/9/15, 6:44 PM, Petr Jelinek wrote:
Yep, I had a same impression when I looked at the code first time,
however, it is defined as below. Not a manner of custom-scan itself.
/*
* ==
* Scan nodes
* ==
*/
typedef struct Scan
{
Planplan;
Index sca
I'm surprised to see that the docs make no mention of how max_connections,
max_worker_processes and autovacuum_max_workers (don't) relate. I couldn't
remember and had to actually look at the code. I'd like to clarify this in the
max_connecitons section of the documents by doing s/connections/us
On 10/01/15 01:19, Kohei KaiGai wrote:
2015-01-10 8:18 GMT+09:00 Jim Nasby :
On 1/6/15, 5:43 PM, Kouhei Kaigai wrote:
scan_relid != InvalidOid
Ideally, they should be OidIsValid(scan_relid)
Scan.scanrelid is an index of range-tables list, not an object-id.
So, InvalidOid or OidIsValid
On Fri, Jan 9, 2015 at 06:57:02PM -0500, Tom Lane wrote:
> I wrote:
> > Christoph Berg writes:
> >> libpq wants the user home directory to find .pgpass and
> >> .pg_service.conf files, but apparently the behavior to require the
> >> existence of the passwd file (or nss equivalent) is new in 9.4.
On 1/9/15, 11:24 AM, Stephen Frost wrote:
What I was advocating for up-thread was to consider multiple "parallel"
paths and to pick whichever ends up being the lowest overall cost. The
flip-side to that is increased planning time. Perhaps we can come up
with an efficient way of working out wher
On 9 January 2015 at 20:46, Stephen Frost wrote:
> I'd suggest we further clarify
> with:
>
>The CREATE POLICY command defines a new policy for a
>table. Note that row level security must also be enabled on the table
> using
>ALTER TABLE in order for created policies to be applied.
>
2015-01-10 8:18 GMT+09:00 Jim Nasby :
> On 1/6/15, 5:43 PM, Kouhei Kaigai wrote:
scan_relid != InvalidOid
> >
>>>
>>> >
>>> >Ideally, they should be OidIsValid(scan_relid)
>>> >
>>
>> Scan.scanrelid is an index of range-tables list, not an object-id.
>> So, InvalidOid or OidIsValid()
On 1/9/15, 3:34 PM, Stephen Frost wrote:
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
On 01/09/2015 08:01 PM, Stephen Frost wrote:
Now, for debugging purposes, I could see such a parameter being
available but it should default to 'off/never-fail'.
not sure what it really would be u
On 1/8/15, 12:00 PM, Kevin Grittner wrote:
Robert Haas wrote:
On Thu, Jan 8, 2015 at 10:19 AM, Kevin Grittner wrote:
Robert Haas wrote:
Andres is talking in my other ear suggesting that we ought to
reuse the 2PC infrastructure to do all this.
If you mean that the primary transaction and a
On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote:
> Christoph Berg writes:
> > libpq wants the user home directory to find .pgpass and
> > .pg_service.conf files, but apparently the behavior to require the
> > existence of the passwd file (or nss equivalent) is new in 9.4.
>
> There is de
I wrote:
> Christoph Berg writes:
>> libpq wants the user home directory to find .pgpass and
>> .pg_service.conf files, but apparently the behavior to require the
>> existence of the passwd file (or nss equivalent) is new in 9.4.
> There is demonstrably no direct reference to /etc/passwd in the P
Christoph Berg writes:
> libpq wants the user home directory to find .pgpass and
> .pg_service.conf files, but apparently the behavior to require the
> existence of the passwd file (or nss equivalent) is new in 9.4.
There is demonstrably no direct reference to /etc/passwd in the PG code.
It's pos
Hi,
I've got several reports that postfix's pgsql lookup tables are broken
with 9.4's libpq5, while 9.3's libpq5 works just fine. The error
message looks like this:
Jan 10 00:11:40 lehmann postfix/trivial-rewrite[29960]: warning: connect to
pgsql server localhost:5432: out of memory?
Jan 10 00:1
On 1/6/15, 5:43 PM, Kouhei Kaigai wrote:
scan_relid != InvalidOid
> >
>
>Ideally, they should be OidIsValid(scan_relid)
>
Scan.scanrelid is an index of range-tables list, not an object-id.
So, InvalidOid or OidIsValid() are not a good choice.
I think the name needs to change then; scan_relid
* Peter Geoghegan (p...@heroku.com) wrote:
> On Fri, Jan 9, 2015 at 1:09 PM, Stephen Frost wrote:
> > Therefore,
> > I'm not sure that I see the point in checking the INSERT tuple against
> > the UPDATE policy.
>
> I guess it wouldn't be hard to modify the struct WithCheckOption to
> store the cm
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> On 01/09/2015 08:01 PM, Stephen Frost wrote:
> > Now, for debugging purposes, I could see such a parameter being
> > available but it should default to 'off/never-fail'.
>
> not sure what it really would be useful for - if I execute a query
On Fri, Jan 9, 2015 at 1:09 PM, Stephen Frost wrote:
> To flip it around a bit, I don't think we can avoid checking the
> *resulting* tuple from the UPDATE against the UPDATE policy.
We can avoid it - by not updating. What I'm suggesting is that an
enforcement occurs that is more or less equivale
On 01/09/2015 08:01 PM, Stephen Frost wrote:
> Amit,
>
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> On Fri, Jan 9, 2015 at 1:02 AM, Jim Nasby wrote:
>>> I agree, but we should try and warn the user if they set
>>> parallel_seqscan_degree close to max_worker_processes, or at least give
>>>
* Peter Geoghegan (p...@heroku.com) wrote:
> On Fri, Jan 9, 2015 at 12:26 PM, Stephen Frost wrote:
> > Where this leaves me, at least, is feeling like we should always apply
> > the INSERT WITH CHECK policy, then if there is a conflict, check the
> > UPDATE USING policy and throw an error if the r
On Fri, Jan 9, 2015 at 12:53 PM, Stephen Frost wrote:
> I'm not sure how that would work exactly though, since the tuple the
> UPDATE results in might be different from what the INSERT has, as Dean
> pointed out. The INSERT tuple might even pass the UPDATE policy where
> the resulting tuple from
On Fri, Jan 9, 2015 at 12:26 PM, Stephen Frost wrote:
> Where this leaves me, at least, is feeling like we should always apply
> the INSERT WITH CHECK policy, then if there is a conflict, check the
> UPDATE USING policy and throw an error if the row isn't visible but
> otherwise perform the UPDATE
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> On Fri, Jan 9, 2015 at 2:22 AM, Dean Rasheed wrote:
> > Whoa, hang on. I think you're being a bit quick to dismiss that
> > example. Why shouldn't I want an upsert where the majority of the
> > table columns follow the usual "make it so" pattern
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 8 January 2015 at 18:57, Stephen Frost wrote:
> >> What do you think of the attached rewording?
> >
> > Rewording it this way is a great idea. Hopefully that will help address
> > the confusion which we've seen. The only comment I have
On Fri, Jan 9, 2015 at 2:22 AM, Dean Rasheed wrote:
> Whoa, hang on. I think you're being a bit quick to dismiss that
> example. Why shouldn't I want an upsert where the majority of the
> table columns follow the usual "make it so" pattern of an upsert, but
> there is also this kind of audit colum
Dean, Peter,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 January 2015 at 08:49, Peter Geoghegan wrote:
> > On Fri, Jan 9, 2015 at 12:19 AM, Dean Rasheed
> > wrote:
> >> I was trying to think up an example where you might actually have
> >> different INSERT and UPDATE policies, and t
On Thu, Sep 4, 2014 at 12:52:14PM -0400, Robert Haas wrote:
> On Wed, Sep 3, 2014 at 6:24 PM, Bruce Momjian wrote:
> > On Fri, May 9, 2014 at 12:03:36PM -0400, Robert Haas wrote:
> >> On Thu, May 8, 2014 at 5:21 PM, Tom Lane wrote:
> >> > Perhaps the text should be like this:
> >> >
> >> > The
I'm worried about libpq blocking in some circumstances; particularly
around SSL renegotiations.
This came up while writing an async postgres library for lua, I
realised that this code was dangerous:
https://github.com/daurnimator/cqueues-pgsql/blob/ee9c3fc85c94669b8128386d99d730fe93d9dbad/cqueues-p
On Thu, Jan 08, 2015 at 08:04:47PM -0800, David Fetter wrote:
> On Mon, Jan 05, 2015 at 02:26:59PM -0800, David Fetter wrote:
> > On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:
> > > On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> > > >
> > > > Yeah, that's the cor
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Fri, Jan 9, 2015 at 1:02 AM, Jim Nasby wrote:
> > I agree, but we should try and warn the user if they set
> > parallel_seqscan_degree close to max_worker_processes, or at least give
> > some indication of what's going on. This is somethin
On Fri, Jan 9, 2015 at 11:34:24AM -0500, Tom Lane wrote:
> Tatsuo Ishii writes:
> > According to Coverity, there's a memory leak bug in transfer_all_new_dbs().
>
> It's pretty difficult to get excited about that; how many table-free
> databases is pg_upgrade likely to see in one run? But surely
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Fri, Dec 19, 2014 at 7:57 PM, Stephen Frost wrote:
> > There's certainly documentation available from the other RDBMS' which
> > already support parallel query, as one source. Other academic papers
> > exist (and once you've linked into o
> On Jan 8, 2015, at 3:44 PM, Andrew Dunstan wrote:
>
>
> On 01/08/2015 03:05 PM, Aaron Botsis wrote:
>>
>>
>>> It's also unnecessary. CSV format, while not designed for this, is
>>> nevertheless sufficiently flexible to allow successful import of json data
>>> meeting certain criteria (es
> On Jan 7, 2015, at 2:45 PM, Andrew Dunstan wrote:
>
>
> On 01/07/2015 08:25 AM, Aaron Botsis wrote:
>> Hi folks, I was having a problem importing json data with COPY. Lots of
>> things export data nicely as one json blob per line. This is excellent for
>> directly importing into a JSON/JSON
On 01/08/2015 08:42 PM, Aaron Botsis wrote:
On Jan 8, 2015, at 3:44 PM, Andrew Dunstan wrote:
On 01/08/2015 03:05 PM, Aaron Botsis wrote:
It's also unnecessary. CSV format, while not designed for this, is nevertheless
sufficiently flexible to allow successful import of json data meeting
Tatsuo Ishii writes:
> According to Coverity, there's a memory leak bug in transfer_all_new_dbs().
It's pretty difficult to get excited about that; how many table-free
databases is pg_upgrade likely to see in one run? But surely we could
just move the pg_free call to after the if-block.
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> A while ago [1] I proposed an enhancement to the way qual pushdown
> safety is decided in RLS / security barrier views. Currently we just
> test for the presence of leaky functions in the qual, but it is
> possible to do better than that, by
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> I ran into a comment type. Please find attached a patch.
Fix pushed.
Thanks!
Stephen
signature.asc
Description: Digital signature
> On Tue, Jan 6, 2015 at 9:17 AM, Kouhei Kaigai wrote:
> > The attached patch is newer revision of custom-/foreign-join
> > interface.
>
> It seems that the basic purpose of this patch is to allow a foreign scan
> or custom scan to have scanrelid == 0, reflecting the case where we are
> scanning
Heikki Linnakangas wrote:
> xlogreader.c contains a bunch of strings passed to the report_invalid_record
> function, that are supposed to be translated. src/backend/nls.mk lists
> report_invalid_record as a gettext trigger.
>
> In 9.2 and below, when those functions were still in xlog, those strin
Craig Ringer writes:
> While looking into client code that relies on parsing server_version
> instead of checking server_version_num, I was surprised to discover that
> server_version_num isn't sent to the client by the server as part of the
> standard set of parameters reported post-auth.
Why sh
On Fri, Dec 19, 2014 at 7:57 PM, Stephen Frost wrote:
>
>
> There's certainly documentation available from the other RDBMS' which
> already support parallel query, as one source. Other academic papers
> exist (and once you've linked into one, the references and prior work
> helps bring in others)
xlogreader.c contains a bunch of strings passed to the
report_invalid_record function, that are supposed to be translated.
src/backend/nls.mk lists report_invalid_record as a gettext trigger.
In 9.2 and below, when those functions were still in xlog, those strings
were in the postgres.pot file
On Tue, Jan 6, 2015 at 9:17 AM, Kouhei Kaigai wrote:
> The attached patch is newer revision of custom-/foreign-join
> interface.
It seems that the basic purpose of this patch is to allow a foreign
scan or custom scan to have scanrelid == 0, reflecting the case where
we are scanning a joinrel rath
On Fri, Jan 9, 2015 at 1:02 AM, Jim Nasby wrote:
>
> On 1/5/15, 9:21 AM, Stephen Frost wrote:
>>
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>>
>>> I think it's right to view this in the same way we view work_mem. We
>>> plan on the assumption that an amount of memory equal to work_mem will
A while ago [1] I proposed an enhancement to the way qual pushdown
safety is decided in RLS / security barrier views. Currently we just
test for the presence of leaky functions in the qual, but it is
possible to do better than that, by further testing if the leaky
function is actually being passed
>So this test can be used to evaluate how shorter records influence
>performance since the master waits for flush confirmation from the
>standby, right?
Yes. This test can help measure performance improvement due to reduced I/O
on standby as master waits for WAL records flush on standby.
>Isn'
On Fri, Jan 9, 2015 at 9:23 PM, Tatsuo Ishii wrote:
> This is because gen_db_file_maps() allocates memory even if n_maps == 0.
Purely cosmetic: the initialization n_maps = 0 before the call of
gen_db_file_maps is unnecessary ;)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
According to Coverity, there's a memory leak bug in transfer_all_new_dbs().
mappings = gen_db_file_maps(old_db, new_db, &n_maps, old_pgdata,
new_pgdata);
if (n_maps)
{
On 9 January 2015 at 08:49, Peter Geoghegan wrote:
> On Fri, Jan 9, 2015 at 12:19 AM, Dean Rasheed
> wrote:
>> I was trying to think up an example where you might actually have
>> different INSERT and UPDATE policies, and the best I can think of is
>> some sort of mod_count column where you have
On Fri, Jan 9, 2015 at 12:19 AM, Dean Rasheed wrote:
> I was trying to think up an example where you might actually have
> different INSERT and UPDATE policies, and the best I can think of is
> some sort of mod_count column where you have an INSERT CHECK
> (mod_count = 0) and an UPDATE CHECK (mod_
On 01/08/2015 10:44 PM, Peter Eisentraut wrote:
On 1/6/15 7:17 PM, Andres Freund wrote:
One problem is that it doesn't use the replication protocol,
so the setup is going to be inconsistent with pg_basebackup. Maybe the
replication protocol could be extended to provide the required data.
I'm
On 8 January 2015 at 18:57, Stephen Frost wrote:
>> What do you think of the attached rewording?
>
> Rewording it this way is a great idea. Hopefully that will help address
> the confusion which we've seen. The only comment I have offhand is:
> should we should add a sentence to this paragraph a
Hi Heikki.
I've attached two regenerated CRC patches, split up as before.
1. The slicing-by-8 patch contains numerous changes:
a. A configure test for __builtin_bswap32
b. A comment referencing the slicing-by-8 paper (which is behind a
paywall, unfortunately, so I haven't even rea
Hello, thank you for the comment.
This is the second version of the patch.
- Refactored to make the code simpler and clearer.
- Added comment about logic outline and struct members.
- Removed trailig white spaces..
- No additional test yet.
==
> warning: 3 lines add whitespace errors.
Who
On Fri, Jan 9, 2015 at 1:10 AM, Petr Jelinek wrote:
> On 06/01/15 14:22, Petr Jelinek wrote:
>>
>> On 06/01/15 08:51, Michael Paquier wrote:
>>>
>>> On Tue, Dec 23, 2014 at 5:21 AM, Petr Jelinek
>>> wrote:
Attached is v3 which besides the fixes mentioned above also includes
changes
On 9 January 2015 at 00:49, Stephen Frost wrote:
> Peter,
>
> * Peter Geoghegan (p...@heroku.com) wrote:
>> For column level privileges, you wouldn't expect to only get an error
>> about not having the relevant update permissions at runtime, when the
>> update path happens to be taken. And so it i
65 matches
Mail list logo
