Re: [HACKERS] bgworker sigusr1 handler

On Wed, Apr 10, 2013 at 12:15 PM, Robert Haas wrote: > Just for fun, I implemented a toy background worker tonight using the > new bgworker framework. Generally, it went well, and I'm pleased with > the design of the new facility. However, I did notice one oddity. I > initialized the worker fla

Re: [HACKERS] Unrecognized type error (postgres 9.1.4)

On Wed, Apr 10, 2013 at 12:24 AM, Amit Kapila wrote: > > On Tuesday, April 09, 2013 6:19 PM Rodrigo Barboza wrote: > On Tue, Apr 9, 2013 at 3:05 AM, Amit Kapila > wrote: > On Monday, April 08, 2013 7:28 PM Rodrigo Barboza wrote: > >> You have identified rightly in your other mail that it happens

Re: [HACKERS] Reassign variable value in XLogReadRecord

On Mon, Apr 8, 2013 at 9:31 PM, Dickson S. Guedes wrote: > Do I am missing something or the last one is unnecessary? Looks unnecessary to me, too. Removed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Unrecognized type error (postgres 9.1.4)

On Tuesday, April 09, 2013 6:19 PM Rodrigo Barboza wrote: On Tue, Apr 9, 2013 at 3:05 AM, Amit Kapila wrote: On Monday, April 08, 2013 7:28 PM Rodrigo Barboza wrote: >> You have identified rightly in your other mail that it happens in function >> convert_numeric_to_scalar(). But I think adding us

[HACKERS] bgworker sigusr1 handler

Just for fun, I implemented a toy background worker tonight using the new bgworker framework. Generally, it went well, and I'm pleased with the design of the new facility. However, I did notice one oddity. I initialized the worker flags like this: worker.bgw_flags = BGWORKER_SHMEM_ACCESS

Re: [HACKERS] Enabling Checksums

On Tue, 2013-04-09 at 05:35 +0300, Ants Aasma wrote: > And here you go. I decided to be verbose with the comments as it's > easier to delete a comment to write one. I also left in a huge jumble > of macros to calculate the contents of a helper var during compile > time. This can easily be replaced

[HACKERS] Re: [BUGS] BUG #8049: Incorrect results when using ORDER BY and query planner options

2013/4/9 : > I've got a strange problem with a query that produces more results than > expected. I tested this [1] and saw that 9.1 don't has the behavior then I started bisect from REL9_1_9 to HEAD and found that commit 5b7b5518d0e [2] introduced it. I'm putting a copy to -hacker list in a hope

[HACKERS] lwlock contention with SSI

About a month ago, I told Kevin Grittner in an off-list conversation that I'd work on providing him with some statistics about lwlock contention under SSI. I then ran a benchmark on a 16-core, 64-hardware thread IBM server, testing read-only pgbench performance at scale factor 300 with 1, 8, and 3

Re: [HACKERS] introduction

On 10/04/13 09:40, Dickson S. Guedes wrote: 2013/4/9 Bert : So I'll just monitor the mailing list a bit, pick some patches and test them. I think this is the best way to learn to know the code, and is probably helpful for everyone? Plus to that you can start reading some information about devel

Re: [HACKERS] introduction

2013/4/9 Bert : > So I'll just monitor the mailing list a bit, pick some patches and test > them. I think this is the best way to learn to know the code, and is > probably helpful for everyone? Plus to that you can start reading some information about development process [1]. There you'll see that

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Alvaro Herrera writes: > I don't see how inlining could work here. We will end up with a couple > dozen calls to ProcessSlowUtility inside ProcessUtility, so inlining it > will be a really poor strategy. Maybe I should have spent some time thinking about the idea rather than just writing it down

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Dimitri Fontaine wrote: > Tom Lane writes: > > RenameStmt: > > if (stmt allows event triggers) > > ProcessSlowUtility(...); > > else > > ExecRenameStmt(stmt); > > break; > > > > while in ProcessSlowUtility it'd just l

[HACKERS] introduction

Hi all, I've just subscribed to this mailing list, so I thought it would be nice to introduce myself. I'm Bert Desmet, and I currently live in Belgium. I work for Deloitte, where we are building a cloud BI platform. As a database for the datawarehouses we use PostgreSQL since a few months. Before

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Tom Lane writes: > Yeah, I was just looking at the IfSupported variant. In the structure > I just suggested (separate ProcessSlowUtility function), we could make > that work by having switch cases for some statements in both functions, > perhaps like this: Ah yes, that's minimal code duplication

Re: Success (Re: [HACKERS] page 1 of relation global/11787 was uninitialized)

Florian Pflug wrote: >> I used this to upgrade to 9.0.13, which indeed is fully compatible with >> Debian. It started up like a charm. I can upgrade it to 9.1.9 now >> (while I'm at it). >Since you've been running with full_page_writes=off, I suggest you update >to 9.1 by dumping and reloading y

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Tom Lane wrote: > I wrote: >> Kevin Grittner writes: >>> Any objections to my pushing the patch I posted Friday to draw a >>> distinction between populated and scannable, which also attempted >>> to address a couple points raised by you, or would you rather the >>> code didn't change at the momen

Re: Success (Re: [HACKERS] page 1 of relation global/11787 was uninitialized)

On Apr9, 2013, at 19:56 , "Stephen R. van den Berg" wrote: > Andres Freund wrote: >> Afaik debian has never shipped 9.0 in any stable release at all. You can >> use the packages provided by the postgres community though, they are >> compatible: >> http://wiki.postgresql.org/wiki/Apt > > I used th

Success (Re: [HACKERS] page 1 of relation global/11787 was uninitialized)

Thanks, all of you, for all good advice and suggestions. Andres Freund wrote: >Afaik debian has never shipped 9.0 in any stable release at all. You can >use the packages provided by the postgres community though, they are >compatible: >http://wiki.postgresql.org/wiki/Apt I used this to upgrade to

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

Andres Freund writes: > Afaik we don't have any debugging utility to dump the pg_filenode.map > contents? Hardly need one ... od -t d4 $PGDATA/global/pg_filenode.map is readable enough, though it does leave you still having to map the numeric OIDs back to names. The OIDs will be stable though.

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

Tom Lane wrote: >"Stephen R. van den Berg" writes: >> Tom Lane wrote: >>> It's conceivable that updating to something more current than 9.0.4 >>> would get you out of this --- we've fixed quite a number of WAL replay >>> bugs in the last two years. >> I see that there is a 9.0.13, but that would

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

On 2013-04-09 19:30:38 +0200, Andres Freund wrote: > On 2013-04-09 19:18:57 +0200, Stephen R. van den Berg wrote: > > Tom Lane wrote: > > >"Stephen R. van den Berg" writes: > > >> Just today one of my systems experienced a kernel panic, and halted > > >> abruptly. > > >> Running Linux 3.1.9, Post

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

On 2013-04-09 13:34:41 -0400, Tom Lane wrote: > "Stephen R. van den Berg" writes: > > Tom Lane wrote: > >> It's conceivable that updating to something more current than 9.0.4 > >> would get you out of this --- we've fixed quite a number of WAL replay > >> bugs in the last two years. > > > I see t

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

"Stephen R. van den Berg" writes: > Tom Lane wrote: >> It's conceivable that updating to something more current than 9.0.4 >> would get you out of this --- we've fixed quite a number of WAL replay >> bugs in the last two years. > I see that there is a 9.0.13, but that would be a source upgrade, s

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

Andres Freund wrote: >On 2013-04-09 18:21:20 +0200, Stephen R. van den Berg wrote: >Thats an absolutely outdated version of 9.0. You shouldn't be running >this in production. Yes, well, it's one of those things. It got installed with Debian and the automatic upgrade didn't upgrade it further, the

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

On 2013-04-09 19:18:57 +0200, Stephen R. van den Berg wrote: > Tom Lane wrote: > >"Stephen R. van den Berg" writes: > >> Just today one of my systems experienced a kernel panic, and halted > >> abruptly. > >> Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise). > > >It's con

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

I wrote: > Kevin Grittner writes: >> Any objections to my pushing the patch I posted Friday to draw a >> distinction between populated and scannable, which also attempted >> to address a couple points raised by you, or would you rather the >> code didn't change at the moment? > I didn't look at i

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

Joshua D. Drake wrote: >full_page_writes = off is the problem. >Turning this parameter off speeds normal operation, but might lead to >either unrecoverable data corruption, or silent data corruption, >after a system failure. The risks are similar to turning off fsync, >though smaller, and it shoul

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

Tom Lane wrote: >"Stephen R. van den Berg" writes: >> Just today one of my systems experienced a kernel panic, and halted abruptly. >> Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise). >It's conceivable that updating to something more current than 9.0.4 >would get you out

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

"Stephen R. van den Berg" writes: > Just today one of my systems experienced a kernel panic, and halted abruptly. > Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise). It's conceivable that updating to something more current than 9.0.4 would get you out of this --- we've fix

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

On 2013-04-09 18:21:20 +0200, Stephen R. van den Berg wrote: > Just today one of my systems experienced a kernel panic, and halted abruptly. > Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise). Thats an absolutely outdated version of 9.0. You shouldn't be running this in pro

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Dimitri Fontaine writes: > Tom Lane writes: >> Personally, I'd really like to see the InvokeDDLCommandEventTriggers >> macros go away; that's not a coding style I find nice. If we had a >> separate switch containing just the event-supporting calls, we could >> drop that in favor of one invocatio

Re: [HACKERS] page 1 of relation global/11787 was uninitialized

On 04/09/2013 09:21 AM, Stephen R. van den Berg wrote: - Looking at global/11787, doesn't reveal any obvious corruption. The server was running with: synchronous_commit = off full_page_writes = off full_page_writes = off is the problem. From the docs: Turning th

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Robert Haas writes: > I kind of wonder if there's some way we could split ProcessUtility() > up into more digestible pieces. I can't really think of a good way to > do it though, without writing duplicative switches. I'm thinking a bit about ProcessUtility() { sw

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Tom Lane writes: > Actually ... wait a moment. That does have some attraction independent > of performance questions, because what Alvaro suggested requires knowing > which commands support command triggers in two places. Perhaps with > some refactoring we could end up with no net addition of cr

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

On Tue, Apr 9, 2013 at 12:07 PM, Tom Lane wrote: > I wrote: >> Dimitri Fontaine writes: >>> What about splitting the big switch statement into two of them? The >>> first one for transaction control statements, and then the other bigger >>> one. > >> Sounds like considerable uglification to fix a

[HACKERS] page 1 of relation global/11787 was uninitialized

Just today one of my systems experienced a kernel panic, and halted abruptly. Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise). The system was moderately active, i.e. about one commit per minute. It is not a large problem if the last few commits would be gone. Now, in rest

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

I wrote: > Dimitri Fontaine writes: >> What about splitting the big switch statement into two of them? The >> first one for transaction control statements, and then the other bigger >> one. > Sounds like considerable uglification to fix a performance issue that's > entirely hypothetical... let's

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Dimitri Fontaine writes: > Tom Lane writes: >> I think it would be difficult and probably dangerous to have PG_TRY >> for only some utility commands, so not much to be done about that. >> The main thing is to not invoke event trigger code for BEGIN/ABORT/SET. > What about splitting the big switc

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Tom Lane writes: > Alvaro Herrera writes: >> (Someone might still complain that we cause a PG_TRY in BEGIN >> TRANSACTION etc. Not sure if this is something we should worry about. >> Robert did complain about this previously.) > > I think it would be difficult and probably dangerous to have PG_T

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Alvaro Herrera writes: > (Someone might still complain that we cause a PG_TRY in BEGIN > TRANSACTION etc. Not sure if this is something we should worry about. > Robert did complain about this previously.) I think it would be difficult and probably dangerous to have PG_TRY for only some utility c

Re: [HACKERS] [COMMITTERS] pgsql: Add sql_drop event for event triggers

Tom Lane wrote: > Alvaro Herrera writes: > > Add sql_drop event for event triggers > > The buildfarm members that use -DCLOBBER_CACHE_ALWAYS don't like this > patch: Ah. Andres Freund found it, after Dimitri prodded me on IM after Andrew's today mailing list post -- the problem is the new UTILI

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Kevin Grittner writes: > Any objections to my pushing the patch I posted Friday to draw a > distinction between populated and scannable, which also attempted > to address a couple points raised by you, or would you rather the > code didn't change at the moment? I didn't look at it yet --- had my

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Tom Lane wrote: > If we don't revert then what you pushed is clearly necessary, so > no objection to having done that.  I'll look at the larger > situation as soon as I get a chance. Any objections to my pushing the patch I posted Friday to draw a distinction between populated and scannable, whi

[HACKERS] sql_drop event trigger vs buildfarm

Buildfarm critters friarbird and jaguarundi have been failing for 11 days, apparently due to the sql_drop event for event triggers feature. These are both FBSD machines, but more importantly are both building with -DCLOBBER_CACHE_ALWAYS. Tom complained about it at the time, see

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Robert Haas writes: > On Tue, Apr 9, 2013 at 10:25 AM, Tom Lane wrote: >> TBH I'd like to revert all of that anyway; it seemed to me to be >> basically gratuitous breakage of an API used by plugins. I've not >> had time to look at whether there was an actual reason for it and >> if so how we mig

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

On Tue, Apr 9, 2013 at 10:25 AM, Tom Lane wrote: > Robert Haas writes: >> The materialized views patch adjusted ExplainOneQuery to take an >> additional DestReceiver argument, but failed to add a matching >> argument to the definition of ExplainOneQuery_hook. This makes the >> hook unusable. Th

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Robert Haas writes: > The materialized views patch adjusted ExplainOneQuery to take an > additional DestReceiver argument, but failed to add a matching > argument to the definition of ExplainOneQuery_hook. This makes the > hook unusable. The idea of this hook is that your hook function will > do

Re: [HACKERS] MV patch broke users of ExplainOneQuery_hook

Robert Haas wrote: > The materialized views patch adjusted ExplainOneQuery to take an > additional DestReceiver argument, but failed to add a matching > argument to the definition of ExplainOneQuery_hook.  This makes the > hook unusable.  The idea of this hook is that your hook function will > do

[HACKERS] MV patch broke users of ExplainOneQuery_hook

The materialized views patch adjusted ExplainOneQuery to take an additional DestReceiver argument, but failed to add a matching argument to the definition of ExplainOneQuery_hook. This makes the hook unusable. The idea of this hook is that your hook function will do something before and/or after

Re: [HACKERS] Unrecognized type error (postgres 9.1.4)

On Tue, Apr 9, 2013 at 3:05 AM, Amit Kapila wrote: > On Monday, April 08, 2013 7:28 PM Rodrigo Barboza wrote: > On Sat, Apr 6, 2013 at 10:39 PM, Rodrigo Barboza > wrote: > Ok! I will try to reproduce in a smaller scenario. > On Sat, Apr 6, 2013 at 9:53 PM, Amit Kapila > wrote: > On Saturday, Ap

[HACKERS] [PATCH] pg_regress and non-default unix socket path

Hi, Debian has been patching pg_regress for years because our default unix socket directory is /var/run/postgresql, but that is not writable by the build user at build time. This used to be a pretty ugly "make- patch-make check-unpatch-make install" patch dance, but now it is a pretty patch that m

Re: [HACKERS] Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog

Re: Jeff Janes 2013-04-06 > I don't think the docs are very clear on that. They say "This file will of > course be archived as a part of your backup dump file", but "will be" does > not imply "must be". Elsewhere it emphasizes that the label you gave to > pg_start_backup is written into the fil

Re: [HACKERS] WIP: index support for regexp search

On Tue, Apr 9, 2013 at 9:15 AM, Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Apr 8, 2013 at 9:28 AM, Tom Lane wrote: > >> I spent the weekend hacking on this, making a number of bug fixes and a > >> whole lot of cosmetic changes. I think there are large parts of this > >> that are

Re: [HACKERS] corrupt pages detected by enabling checksums

On Mon, 2013-04-08 at 09:19 +0100, Simon Riggs wrote: > Applied, with this as the only code change. > > > Thanks everybody for good research and coding and fast testing. > > > We're in good shape now. Thank you. I have attached two more patches: 1. I believe that the issue I brought up at t

Re: [HACKERS] corrupt pages detected by enabling checksums

On Sat, 2013-04-06 at 16:44 +0200, Andres Freund wrote: > I think we can just make up the rule that changing full page writes also > requires SpinLockAcquire(&xlogctl->info_lck);. Then its easy enough. And > it can hardly be a performance bottleneck given how infrequently its > modified. That seem

Re: [HACKERS] Inconsistent DB data in Streaming Replication

On 04/08/2013 12:34 PM, Samrat Revagade wrote: Hello, We have been trying to figure out possible solutions to the following problem in streaming replication Consider following scenario: If master receives commit command, it writes and flushes commit WAL records to the disk, It also writes a

Re: [HACKERS] Enabling Checksums

On Tue, Apr 9, 2013 at 5:35 AM, Ants Aasma wrote: > Quick bench results on the worst case workload: > master no checksums: tps = 15.561848 > master with checksums: tps = 1.695450 > simd checksums: tps = 14.602698 For reference, results for the generic version, with default build params and with t

Re: [HACKERS] Inconsistent DB data in Streaming Replication

On Tue, Apr 9, 2013 at 9:42 AM, Samrat Revagade wrote: >>What Samrat is proposing here is that WAL is not flushed to the OS before >>it is acked by a synchronous replica so recovery won't go past the >>timeline change made in failover, making it necessary to take a new >>base backup to resync with

Re: [HACKERS] Enabling Checksums

On Tue, Apr 9, 2013 at 10:03 AM, Simon Riggs wrote: > Thanks. Would you mind reworking the patch so that you aren't removing the > existing code, only IFDEFing it out of the way. I'd like to make it as easy > as possible to skip your implementation for both us and the use of the code, > and/or add

Re: [HACKERS] Page replacement algorithm in buffer cache

> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Tuesday, April 09, 2013 9:28 AM > To: Amit Kapila > Cc: Greg Smith; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Page replacement algorithm in buffer cache > > On Fri, Apr 5, 2013 at 11:08 PM, Amit K

Re: [HACKERS] Enabling Checksums

On 9 April 2013 03:35, Ants Aasma wrote: > On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma wrote: > > Unless somebody tells me not to waste my time I'll go ahead and come > > up with a workable patch by Monday. > > And here you go. I decided to be verbose with the comments as it's > easier to delete