On 01/25/2012 06:40 PM, Tom Lane wrote:
Marko Kreen writes:
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
Huh? How can that work? If we decide to change the representation of
some other "well known type", say numeric, how do we decide whether a
client setting that bit is expectin
On Wed, Dec 28, 2011 at 7:27 PM, Simon Riggs wrote:
> On Thu, Dec 22, 2011 at 6:16 AM, Simon Riggs wrote:
>
>> I can see a reason to do this now. I've written patch and will commit
>> on Friday. Nudge me if I don't.
>
> It's hard to write this so it works in all cases and doesn't work in
> the ri
On Wed, Jan 25, 2012 at 11:12 PM, Simon Riggs wrote:
> On Wed, Jan 25, 2012 at 1:57 PM, Robert Haas wrote:
>
>> I think that this would be a lot more clear if we described this as
>> synchronous_commit = remote_write rather than just synchronous_commit
>> = write. Actually, the internal constant
On Thu, Jan 26, 2012 at 3:07 AM, Simon Riggs wrote:
> On Wed, Jan 25, 2012 at 8:49 AM, Simon Riggs wrote:
>> On Wed, Jan 25, 2012 at 8:16 AM, Fujii Masao wrote:
>>
What happens if we shutdown the WALwriter and then issue SIGHUP?
>>>
>>> SIGHUP doesn't affect full_page_writes in that case. O
On Fri, Jan 20, 2012 at 12:33 AM, Simon Riggs wrote:
> On Wed, Jan 18, 2012 at 7:15 AM, Fujii Masao wrote:
>> On Sun, Nov 13, 2011 at 5:13 PM, Simon Riggs wrote:
>>> On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggs wrote:
>>>
When I say skip the shutdown checkpoint, I mean remove it from the
>
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié ene 25 17:32:49 -0300 2012:
>> On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
> New version that repairs a defective test case.
>>
>> Committed. I don't find this to be particularly good style:
>>
>> + for (i = 0;
On Tue, Jan 24, 2012 at 6:43 PM, Fujii Masao wrote:
>> Cleaned up the points noted, new patch attached in case you wish to
>> review further.
>>
>> Still has bug, so still with me to fix.
>
> Thanks! Will review further.
v3 patch contains lots of unrelated code changes like the following.
- pi
This is my test case (all in one session):
CREATE TABLE foo (
key int PRIMARY KEY,
value int
);
INSERT INTO foo VALUES (1, 1);
BEGIN;
DECLARE foo CURSOR FOR SELECT * FROM foo FOR UPDATE;
UPDATE foo SET value = 2 WHERE key = 1;
UPDATE foo SET value = 3 WHERE key = 1
On Wed, Jan 25, 2012 at 11:17:27AM -0300, Alvaro Herrera wrote:
>
> Excerpts from Noah Misch's message of dom ene 22 02:05:31 -0300 2012:
>
> > Thanks. I've attached a new version fixing this problem.
>
> Looks good to me. Can you please clarify this bit?
>
>* Since we
On Wed, Jan 25, 2012 at 03:32:49PM -0500, Robert Haas wrote:
> On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
> > New version that repairs a defective test case.
>
> Committed. I don't find this to be particularly good style:
Thanks.
> + for (i = 0; i < old_natts && ret; i++)
> +
On Tue, Jan 24, 2012 at 11:24:08AM -0500, Jaime Casanova wrote:
> On Mon, Jan 23, 2012 at 7:18 PM, Noah Misch wrote:
> > If someone feels like
> > doing it, +1 for making pgstattuple() count non-leaf free space.
>
> actually i agreed that non-leaf pages are irrelevant... i just
> confirmed that i
On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs wrote:
> Your caution is wise. All users of an index have already checked
> whether the index is usable at plan time, so although there is much
> code that assumes they can look at the index itself, that is not
> executed until after the correct checks
On Wed, Jan 25, 2012 at 3:11 AM, Heikki Linnakangas
wrote:
> I've been thinking, what exactly is the important part of this group commit
> patch that gives the benefit? Keeping the queue sorted isn't all that
> important - XLogFlush() requests for commits will come in almost the correct
> order an
On Sat, Jan 21, 2012 at 9:50 PM, Jeff Janes wrote:
> A review:
>
> [ review ]
Thanks. Committed with hopefully-appropriate revisions.
> As a side-note, I noticed that I needed to run vacuum twice in a row
> to get the Heap Fetches to drop to zero. I vaguely recall that only
> one vacuum was ne
On 01/23/2012 11:16 PM, Robert Treat wrote:
I keep thinking Greg has mistaken happiness with the MB based info in
the vacuum patch as being happy without the output format, when really
it is all about increased visibility.
I haven't taken that as anything but evidence I'm at least moving in the
Hello.
It's probably not the right place to write, but I guess you are there to
take care of it.
When I was creating a trigger with command like:
create trigger asdf before update on beginninOfTheNameOfMyTable...
I hit tab and I got:
create trigger asdf before update on SET
That was obviously
While testing a backup script, I noticed that pg_basebackup exits with
0, even if it had errors while writing the backup to disk when the
backup file is to be sent to stdout. The attached patch should fix this
problem (and some special cases when the last write fails).
Regards,
Thomas
diff -uNr p
Hi hackers,
the attached patch fixes the problem I explained in pgsql-bugs (forwarded).
It's a trivial problem, so no initial patch design was required.
Hope to see my patch applied.
Thanks for your work.
Regards.
-- Forwarded message --
From: Giuseppe Sucameli
Date: Sun, Jan
On Sun, Jan 22, 2012 at 5:57 AM, Kohei KaiGai wrote:
>> This passes installcheck initially. Then upon second invocation of
>> installcheck, it fails.
>>
>> It creates the role "alice", and doesn't clean it up. On next
>> invocation alice already exists and cases a failure in test
>> select_views
Excerpts from Robert Haas's message of mié ene 25 19:05:44 -0300 2012:
>
> On Wed, Jan 25, 2012 at 3:52 PM, Alvaro Herrera
> wrote:
> >
> > Excerpts from Robert Haas's message of mié ene 25 17:32:49 -0300 2012:
> >> On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
> >> > New version that rep
On Wed, Jan 25, 2012 at 3:52 PM, Alvaro Herrera
wrote:
>
> Excerpts from Robert Haas's message of mié ene 25 17:32:49 -0300 2012:
>> On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
>> > New version that repairs a defective test case.
>>
>> Committed. I don't find this to be particularly good
On Wed, Jan 25, 2012 at 1:24 PM, Tom Lane wrote:
> Also, you're assuming that the changes have no upside whatsoever, which
> I fondly hope is not the case. Large join problems tend not to execute
> instantaneously --- so nobody is going to complain if the planner takes
> awhile longer but the res
Excerpts from Noah Misch's message of sáb ene 14 12:40:02 -0300 2012:
> It has bothered me that psql's \copy ignores the ON_ERROR_ROLLBACK setting.
> Only SendQuery() takes note of ON_ERROR_ROLLBACK, and \copy, like all
> backslash commands, does not route through SendQuery(). Looking into this
>
On Wed, Jan 25, 2012 at 02:50:09PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen wrote:
> >> well, I see the following cases:
> >> 1) Vserver > Vapplication: server downgrades wire formats to
> >> applications version
> >> 2) Vapplication > Vlibpq > Vserver: since the
> I actually don't know much about the I/O subsystem, but, no, WAL is
> not separated from data. I believe $PGDATA is on a SAN, but I don't
> know anything about its characteristics.
The computer is here:
http://www.supermicro.nl/Aplus/system/2U/2042/AS-2042G-6RF.cfm
$PGDATA is on a 5 disk SATA
Excerpts from Robert Haas's message of mié ene 25 17:32:49 -0300 2012:
> On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
> > New version that repairs a defective test case.
>
> Committed. I don't find this to be particularly good style:
>
> + for (i = 0; i < old_natts && ret; i++)
>
On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen wrote:
>> well, I see the following cases:
>> 1) Vserver > Vapplication: server downgrades wire formats to
>> applications version
>> 2) Vapplication > Vlibpq > Vserver: since the application is
>> reading/writing formats the server can't understand, an
On Sun, Jan 22, 2012 at 12:23 AM, Noah Misch wrote:
> New version that repairs a defective test case.
Committed. I don't find this to be particularly good style:
+ for (i = 0; i < old_natts && ret; i++)
+ ret = (!IsPolymorphicType(get_opclass_input_type(classObjectId[i
+
On Wed, Jan 25, 2012 at 01:43:03PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen wrote:
> > On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> >> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> >> > I specifically want to avoid any sort of per-c
On Jan 25, 2012, at 12:19 PM, Tom Lane wrote:
>> Why not create a branch? IIRC the build farm can be configured to run
>> branches.
>
> I already know what the patch does against the regression tests.
> Buildfarm testing is not of interest here. What would be of help is,
> say, Kevin volunteeri
"David E. Wheeler" writes:
> On Jan 25, 2012, at 10:24 AM, Tom Lane wrote:
>> Anyway, I'd be willing to hold off committing if someone were to
>> volunteer to test an unintegrated copy of the patch against some
>> moderately complicated application. But it's a sufficiently large
>> patch that I d
On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes wrote:
> On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
>> Early yesterday morning, I was able to use Nate Boley's test machine
>> do a single 30-minute pgbench run at scale factor 300 using a variety
>> of trees built with various patches, and w
On Wed, Jan 25, 2012 at 9:09 AM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes wrote:
>> On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
>>> Early yesterday morning, I was able to use Nate Boley's test machine
>>> do a single 30-minute pgbench run at scale factor 300 usi
PG Gurus,
I have a table like this:
CREATE TABLE filemods (
guid BIGINT NOT NULL UNIQUE,
filepath_guid BIGINT NOT NULL,
createtimeTIMESTAMP WITH TIME ZONE DEFAULT NULL,
writetime TIMESTAMP WITH TIME ZONE DEFAULT NULL,
deletetime
On Jan 25, 2012, at 10:24 AM, Tom Lane wrote:
> Anyway, I'd be willing to hold off committing if someone were to
> volunteer to test an unintegrated copy of the patch against some
> moderately complicated application. But it's a sufficiently large
> patch that I don't really care to sit on it and
On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen wrote:
> On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
>> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
>> > I specifically want to avoid any sort of per-connection
>> > negotation, except the "max format version supported",
>>
On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> > I specifically want to avoid any sort of per-connection
> > negotation, except the "max format version supported",
> > because it will mess up multiplexed usage of single conn
On Wed, Jan 25, 2012 at 12:58:15PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> >> Then why bother with the bit in the format code? If you've already done
> >> some other negotiation to establish what datatype formats you will
> >> a
On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> I specifically want to avoid any sort of per-connection
> negotation, except the "max format version supported",
> because it will mess up multiplexed usage of single connection.
> Then they need to either disabled advanced formats completely,
Robert Haas writes:
> I have to admit that I have a bad feeling about this. It strikes me
> that there is no way we're not going to get complaints about a 35%
> slowdown on planning a large join problem.
I have to admit that I'm worried about that too. However, I hope to
continue whittling away
On Sun, Jan 22, 2012 at 5:12 AM, Kohei KaiGai wrote:
> 2012/1/21 Robert Haas :
>> On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai wrote:
>>> I marked the default leakproof function according to the criteria that
>>> does not leak contents of the argument.
>>> Indeed, timestamp_ne_timestamptz() has
On Wed, Jan 25, 2012 at 8:49 AM, Simon Riggs wrote:
> On Wed, Jan 25, 2012 at 8:16 AM, Fujii Masao wrote:
>
>>> What happens if we shutdown the WALwriter and then issue SIGHUP?
>>
>> SIGHUP doesn't affect full_page_writes in that case. Oh, you are concerned
>> about
>> the case where smart shutd
Marko Kreen writes:
> On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
>> Then why bother with the bit in the format code? If you've already done
>> some other negotiation to establish what datatype formats you will
>> accept, this doesn't seem to be adding any value.
> The "other negot
On Wed, Jan 25, 2012 at 11:24 AM, Tom Lane wrote:
> After that I started doing some performance testing, and the initial
> news was bad: the planner was about 3x slower than 9.1 on a moderately
> large join problem. I've spent the past several days hacking away at
> that, and have got it down to
On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> >> Huh? How can that work? If we decide to change the representation of
> >> some other "well known type", say numeric, how do we decide whether a
> >>
On Wed, Jan 25, 2012 at 11:40 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
>>> Huh? How can that work? If we decide to change the representation of
>>> some other "well known type", say numeric, how do we decide whether a
>>> client sett
On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
> Early yesterday morning, I was able to use Nate Boley's test machine
> do a single 30-minute pgbench run at scale factor 300 using a variety
> of trees built with various patches, and with the -l option added to
> track latency on a per-transa
On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai wrote:
> I tried to implement based on the idea to call object-access-hook with
> flag; that
> informs extensions contexts of objects being removed.
> Because I missed DROP_RESTRICT and DROP_CASCADE are enum type,
> this patch added performInternalDele
Marko Kreen writes:
> On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
>> Huh? How can that work? If we decide to change the representation of
>> some other "well known type", say numeric, how do we decide whether a
>> client setting that bit is expecting that change or not?
> It sets
hubert depesz lubaczewski writes:
> anyway - the point is that in \df date_part(, timestamp) says it's
> immutable, while it is not.
Hmm, you're right. I thought we'd fixed that way back when, but
obviously not. Or maybe the current behavior of the epoch case
postdates that.
Committed, with OID change. Thanks.
I tested it with plphp just for the heck of it and it worked
wonderfully.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-h
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> >> Furthermore, while we haven't settled the question of exactly what a
> >> good negotiation facility would look like, we seem to agree that a GUC
> >
Marko Kreen writes:
> On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
>> Furthermore, while we haven't settled the question of exactly what a
>> good negotiation facility would look like, we seem to agree that a GUC
>> isn't it. I think that means this isn't going to happen for 9.2,
Excerpts from Noah Misch's message of dom ene 22 02:05:31 -0300 2012:
> Thanks. I've attached a new version fixing this problem.
Looks good to me. Can you please clarify this bit?
* Since we elsewhere require that all collations share
the same
On Wed, Jan 25, 2012 at 1:57 PM, Robert Haas wrote:
> I think that this would be a lot more clear if we described this as
> synchronous_commit = remote_write rather than just synchronous_commit
> = write. Actually, the internal constant is named that way already,
> but it's not exposed as such t
On Wed, Jan 25, 2012 at 1:23 AM, Fujii Masao wrote:
> On Wed, Jan 25, 2012 at 5:35 AM, Jaime Casanova wrote:
>> On Tue, Jan 24, 2012 at 3:22 PM, Simon Riggs wrote:
>>> Add new replication mode synchronous_commit = 'write'.
>>> Replication occurs only to memory on standby, not to disk,
>>> so pro
On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
> I think we should be working to commit XLogInsert and then Group
> Commit, then come back to the discussion.
I definitely agree that those two have way more promise than anything
else on the table. However, now that I understand how badly we'
On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
wrote:
> On 23.01.2012 22:52, Jim Mlodgenski wrote:
>>
>> On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenski wrote:
>>>
>>> On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
I don't think that's a problem, it's just a free-form message
On Wed, Jan 25, 2012 at 7:13 AM, Julien Tachoires wrote:
> 2012/1/24 Robert Haas :
>> On Sun, Jan 22, 2012 at 11:04 AM, Julien Tachoires wrote:
>>> 2011/12/15 Alvaro Herrera :
Uhm, surely you could compare the original toast tablespace to the heap
tablespace, and if they differ, ha
2012/1/24 Robert Haas :
> On Sun, Jan 22, 2012 at 11:04 AM, Julien Tachoires wrote:
>> 2011/12/15 Alvaro Herrera :
>>>
>>> Uhm, surely you could compare the original toast tablespace to the heap
>>> tablespace, and if they differ, handle appropriately when creating the
>>> new toast table? Just p
Hi,
I'm doing some development on the storage manager module of Postgres.
I have added few source files already to the smgr folder, and I was able to
have the Make system includes them by adding their names to the OBJS list
in the Makefile inside the smgr folder. (i.e. When I add A.c, I would add
On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> Furthermore, while we haven't settled the question of exactly what a
> good negotiation facility would look like, we seem to agree that a GUC
> isn't it. I think that means this isn't going to happen for 9.2, so
> we should mark this p
On tis, 2012-01-24 at 20:13 -0500, Tom Lane wrote:
> Yeah. In both cases, the (proposed) new output format is
> self-identifying *to clients that know what to look for*.
> Unfortunately it would only be the most anally-written pre-existing
> client code that would be likely to spit up on the unexp
What's about travel&accomodation support ?
On Tue, 24 Jan 2012, Joshua D. Drake wrote:
Hello,
The call for papers for PgNext (the old PgWest/PgEast) is now open:
January 19th: Talk submission opens
April 15th: Talk submission closes
April 30th: Speaker notification
Submit: https://www.postg
On Wed, Jan 25, 2012 at 8:16 AM, Fujii Masao wrote:
>> What happens if we shutdown the WALwriter and then issue SIGHUP?
>
> SIGHUP doesn't affect full_page_writes in that case. Oh, you are concerned
> about
> the case where smart shutdown kills walwriter but some backends are
> still running?
>
On Tue, Jan 24, 2012 at 7:54 PM, Simon Riggs wrote:
> On Tue, Jan 24, 2012 at 9:51 AM, Fujii Masao wrote:
>
>>> I'll proceed to commit for this now.
>>
>> Thanks a lot!
>
> Can I just check a few things?
Sure!
> You say
> /*
> + * Update full_page_writes in shared memory and write an
> +
I've been thinking, what exactly is the important part of this group
commit patch that gives the benefit? Keeping the queue sorted isn't all
that important - XLogFlush() requests for commits will come in almost
the correct order anyway.
I also don't much like the division of labour between gro
On Mon, Jan 23, 2012 at 7:13 PM, Matthew Draper wrote:
> On 19/01/12 20:28, Hitoshi Harada wrote:
>>> (Now it occurred to me that forgetting the #include parse_func.h might
>>> hit this breakage..., so I'll fix it here and continue to test, but if
>>> you'll fix it yourself, let me know)
>>
>> I f
68 matches
Mail list logo
