At 2014-09-25 15:40:11 +0530, a...@2ndquadrant.com wrote:
>
> All right, then I'll post a version that addresses Amit's other
> points, adds a new file/function to pgstattuple, acquires content
> locks, and uses HeapTupleSatisfiesVacuum, hint-bit setting and all.
Sorry, I forgot to post this patch
Hi,
While reviewing FPW compression patch, I found that allocate_recordbuf()
always returns TRUE though its source code comment says that FALSE is
returned if out of memory. Its return value is checked in two places, but
which is clearly useless.
allocate_recordbuf() was introduced by 7fcbf6a, an
On Fri, Dec 26, 2014 at 3:24 PM, Fujii Masao wrote:
> pglz_compress() and pglz_decompress() still use PGLZ_Header, so the frontend
> which uses those functions needs to handle PGLZ_Header. But it basically
> should
> be handled via the varlena macros. That is, the frontend still seems to need
>
On Fri, Dec 26, 2014 at 12:31 PM, Michael Paquier
wrote:
> On Thu, Dec 25, 2014 at 10:10 PM, Michael Paquier
> wrote:
>> On Wed, Dec 24, 2014 at 9:03 PM, Michael Paquier
>> wrote:
>>> Returning only a boolean is fine for me (that's what my first patch
>>> did), especially if we add at some point
On 2014/12/23 0:36, Tom Lane wrote:
> Yeah, we need to do something about the PlanRowMark data structure.
> Aside from the pre-existing issue in postgres_fdw, we need to fix it
> to support inheritance trees in which more than one rowmark method
> is being used. That rte.hasForeignChildren thing i
2014-12-16 1:22 GMT+09:00 Robert Haas :
> On Mon, Dec 15, 2014 at 3:40 AM, Shigeru Hanada
> wrote:
>> I'm working on $SUBJECT and would like to get comments about the
>> design. Attached patch is for the design below.
>
> I'm glad you are working on this.
>
>> 1. Join source relations
>> As descr
2014-12-16 0:45 GMT+09:00 Tom Lane :
> Shigeru Hanada writes:
>> I'm working on $SUBJECT and would like to get comments about the
>> design. Attached patch is for the design below. Note that the patch
>> requires Kaigai-san's custom foriegn join patch[1]
>
> For the record, I'm not particularly
On Thu, Nov 20, 2014 at 09:15:51PM +0100, Andres Freund wrote:
> On 2014-11-20 13:57:25 -0500, Robert Haas wrote:
> > On Thu, Nov 20, 2014 at 12:19 PM, Andres Freund
> > wrote:
> > If the
> > deadlock detector would kill the processes anyway, it doesn't matter,
> > because CheckTableNotInUse() sh
Tom Lane wrote:
> Andres Freund writes:
> > So I think a better way to deal with that warning would be a good
> > idea. Besides somehow making the mechanism there are two ways to attack
> > this that I can think of, neither of them awe inspiring:
>
> > 1) Make that WARNING a LOG message instead.
Tom Lane wrote:
> Andres Freund writes:
> > My guess is that it's related to d7ee82e50f. It seems realistic that the
> > event trigger added by it to the object_address test can cause errors at
> > varying times.
>
> [ squint... ] Event triggers are global across the whole database, aren't
> the
On Thu, Dec 25, 2014 at 10:10 PM, Michael Paquier
wrote:
> On Wed, Dec 24, 2014 at 9:03 PM, Michael Paquier
> wrote:
>> Returning only a boolean is fine for me (that's what my first patch
>> did), especially if we add at some point hooks for compression and
>> decompression calls.
> Here is a pat
Andres Freund writes:
> My guess is that it's related to d7ee82e50f. It seems realistic that the
> event trigger added by it to the object_address test can cause errors at
> varying times.
[ squint... ] Event triggers are global across the whole database, aren't
they? Isn't it frickin insane to
On Fri, Dec 26, 2014 at 6:28 AM, Tomas Vondra wrote:
> On 25.12.2014 21:14, Andres Freund wrote:
>> On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
>>
>> My guess is that a checkpoint happened at that time. Maybe it'd be a
>> good idea to make pg_regress start postgres with log_checkpoints
>> enable
On 26.12.2014 02:59, Tom Lane wrote:
> Tomas Vondra writes:
>> On 25.12.2014 22:40, Tom Lane wrote:
>>> I think that hamster has basically got a tin can and string for an I/O
>>> subsystem. It's not real clear to me whether there's actually been an
>>> increase in "wait timeout" failures recently
Tomas Vondra writes:
> On 25.12.2014 22:40, Tom Lane wrote:
>> I think that hamster has basically got a tin can and string for an I/O
>> subsystem. It's not real clear to me whether there's actually been an
>> increase in "wait timeout" failures recently; somebody would have to
>> go through and
Andres Freund writes:
> I wonder if it'd not be a good idea if the event trigger code installed
> a error context callback? Since they can be called in situations we
> don't routinely expect that'd make diagnosis in many cases easier.
+1 ... even if that's not related to the immediate issue, it s
Hi,
On 2014-12-25 16:01:47 -0500, Tom Lane wrote:
> In any case, it now seems dead certain that this is a recently introduced
> bug. Andres is fortunate that the first instance occurred before his
> recent batch of commits, or I'd be on him to revert them.
Yes, Phew. These look rather odd.
> As
On Thu, Dec 25, 2014 at 11:35:31PM +1300, David Rowley wrote:
> On 25 December 2014 at 18:27, Noah Misch wrote:
> > This needs to be conditional on whether the platform supports IPv6, like
> > we do
> > in setup_config(). The attached patch works on these configurations:
> >
> > 64-bit Windows Se
On 25.12.2014 22:40, Tom Lane wrote:
> Tomas Vondra writes:
>> The strange thing is that the split happened ~2 years ago, which is
>> inconsistent with the sudden increase of this kind of issues. So maybe
>> something changed on that particular animal (a failing SD card causing
>> I/O stalls, perh
On 25.12.2014 22:16, Tom Lane wrote:
> Tomas Vondra writes:
>> On 25.12.2014 20:36, Tom Lane wrote:
>>> BTW, I notice that in the current state of pgstat.c, all the logic
>>> for keeping track of request arrival times is dead code, because
>>> nothing is actually looking at DBWriteRequest.request_
Tomas Vondra writes:
> The strange thing is that the split happened ~2 years ago, which is
> inconsistent with the sudden increase of this kind of issues. So maybe
> something changed on that particular animal (a failing SD card causing
> I/O stalls, perhaps)?
I think that hamster has basically g
On 25.12.2014 21:14, Andres Freund wrote:
> On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
>
> My guess is that a checkpoint happened at that time. Maybe it'd be a
> good idea to make pg_regress start postgres with log_checkpoints
> enabled? My guess is that we'd find horrendous 'sync' times.
>
>
On Tue, Dec 23, 2014 at 11:20 AM, José Luis Tallón
wrote:
> I've found myself needing two role capabilities? as of lately, when
> thinking about restricting some roles to the barely minimum allowed
> permissions needed to perform their duties ... as opposed to having a
> superuser role devoted
Trent Shipley writes:
> On Friday 2007-12-14 16:22, Tom Lane wrote:
>> Neil Conway writes:
>> > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
>> > to drop (and log) rows that contain malformed data. That is, rows with
>> > too many or too few columns, rows that result in
Tomas Vondra writes:
> On 25.12.2014 20:36, Tom Lane wrote:
>> BTW, I notice that in the current state of pgstat.c, all the logic
>> for keeping track of request arrival times is dead code, because
>> nothing is actually looking at DBWriteRequest.request_time.
> Really? Which part of the code is
On 25.12.2014 20:36, Tom Lane wrote:
>
> Yeah, I've been getting more annoyed by that too lately. I keep
> wondering though whether there's an actual bug underneath that
> behavior that we're failing to see. PGSTAT_MAX_WAIT_TIME is already
> 10 seconds; it's hard to credit that increasing it still
I wrote:
> These two recent failures look suspiciously similar:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-12-24%2021%3A03%3A05
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kouprey&dt=2014-12-25%2018%3A43%3A17
And I'd barely finished posting that before
These two recent failures look suspiciously similar:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-12-24%2021%3A03%3A05
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kouprey&dt=2014-12-25%2018%3A43%3A17
to wit:
*** /usr/home/pgbf/buildenv/HEAD/pgsql.build/src/
On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
> I wonder whether when multiple processes are demanding statsfile updates,
> there's some misbehavior that causes them to suck CPU away from the stats
> collector and/or convince it that it doesn't need to write anything.
> There are odd things in the
Andres Freund writes:
> So I think a better way to deal with that warning would be a good
> idea. Besides somehow making the mechanism there are two ways to attack
> this that I can think of, neither of them awe inspiring:
> 1) Make that WARNING a LOG message instead. Since those don't get send
>
Hi,
We quite regularly have buildfarm failures that are caused by 'WARNING:
pgstat wait timeout' at random points during the build. Especially on
some of the ARM buildfarm animals those are really frequent, to the
point that it's hard to know the actual state of the buildfarm without
looking at se
On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen wrote:
>
> To summarise for people who haven't followed the thread in detail, the
> idea is that you would do:
>
> grant select on foo to audit;
>
> ...and the server would audit-log any "select ... from foo ..." queries (by
> any user).
what
On 2014-12-25 21:12:54 +0900, Michael Paquier wrote:
> On Thu, Dec 25, 2014 at 7:48 PM, Andres Freund wrote:
> > I think it's a bad idea to move it away - the current placement provides
> > a API that allows to get at the image data without having to deal with
> > the low level details. E.g. the i
On Wed, Dec 24, 2014 at 9:03 PM, Michael Paquier
wrote:
> Returning only a boolean is fine for me (that's what my first patch
> did), especially if we add at some point hooks for compression and
> decompression calls.
Here is a patch rebased on current HEAD (60838df) for the core feature
with the
On Thu, Dec 25, 2014 at 7:48 PM, Andres Freund wrote:
> I think it's a bad idea to move it away - the current placement provides
> a API that allows to get at the image data without having to deal with
> the low level details. E.g. the in_use, has_image and hole
> logic. *Especially* when we add c
On 2014-12-24 13:58:41 -0600, Jim Nasby wrote:
> This surprises me given that SMHasher shows XXH to be 50% faster than Spooky
> for 20 byte keys.
Note that there's quite some differences in how smhasher and postgres
use the hash functions. The former nearly exclusively exercises the hash
function
On 2014-12-25 08:52:05 +0900, Michael Paquier wrote:
> On Wed, Dec 24, 2014 at 10:51 PM, Fujii Masao wrote:
> > Fair enough. Anyway I wait for applying the patch which moves
> > pg_lzcompress.c
> > until we will have reached any consensus about this.
> Just to be clear (after sleeping on it), we
At 2014-12-22 08:05:57 -0500, robertmh...@gmail.com wrote:
>
> On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost wrote:
> > … "ok, does the audit role have any permissions here?" and, if the
> > result is yes, then the command is audited. …
>
> This is a little weird because you're effectively grant
On 25 December 2014 at 18:27, Noah Misch wrote:
> On Thu, Dec 25, 2014 at 03:55:02PM +1300, David Rowley wrote:
> > f6dc6dd seems to have broken vcregress check for me:
>
> > FATAL: no pg_hba.conf entry for host "::1", user "David", database
> > "postgres"
> > ...
> > FATAL: no pg_hba.conf entr
39 matches
Mail list logo
