Re: [HACKERS] [Fwd: Re: [PATCHES] 64-bit CommandIds]
Decibel! [EMAIL PROTECTED] writes: If we're going to make this a ./configure option, ISTM we should do the same with XID size as well. I know there are high-velocity databases that could use that. Keep in mind we just changed things so that read-only transactions don't consume xids. That means you would have to be actually modifying 2- billion records before wrap-around becomes an issue. If you're modifying 2-billion records that quickly presumably you're going to have other pressing reasons to run vacuum aside from xid freezing... Also, consider that you're suggesting increasing the per-tuple overhead from 24 bytes to, if my arithmetic is right, 40 bytes. So really you would need, say, a system with enough i/o bandwidth to handle 2-billion updates or inserts per day and with enough spare i/o bandwidth that another 16-bytes on every one of those updates is ok, but without the ability to run vacuum. Also, we still have hope that the visibility map info will make running vacuum even less of an imposition. All that said I don't really see much reason not to make it an option. I just don't think anyone really needs it. In 5-10 years though... Doing this for XIDs is pretty useless this days. It is only targeted for command ids which are consumed heavily by stored procedure languages. It happens once on a while that a complex business logic procedure runs out of command ids inside a transaction. the idea is to give users a chance to avoid that. touching XIDs does not make sense to me at all. many thanks, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at
Re: [HACKERS] Proposal for db level triggers
On Mar 13, 2008, at 5:14 PM, James Mansion wrote: James Mansion wrote: In usage: AFTER START clears counters and flags. UPDATE triggers on data set counters and flags. BEFORE COMMIT examines the counters and flags and performs any final validation or adjustments (or external events such as sending a MoM message) I'd like to point out also that AFTER CONNECT is a good opportunity to CREATE TEMP TABLE (be nice if a global temp table definition could be persisted and automatically duplicated into each session, but never mind). +1 on both counts. Can we get a TODO? -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] How large file is really large - pathconf results
Reini Urban napsal(a): cygwin 1.5 on NTFS. But 1.7 will a have much larger _PC_PATH_MAX. _PC_FILESIZEBITS undefined _PC_LINK_MAX = 8 _PC_NAME_MAX = 260 _PC_PATH_MAX = 257 So this is really bad. Thanks for reporting. It seems not good because postgreSQL assumes that _PC_PATH_MAX is minimal 1024 for all platforms. If this values is correct then user on cygwin can have a trouble. Please, could you test postgres with a long PATH? thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Commit Fest (was Re: [HACKERS] Sort Refinement)
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote: Simon, would it be too much to ask that you concentrate on reviewing existing patches during commit fest? Trying to get people to think about random new ideas is about the most direct undermining of the commit-fest concept that I can think of. Save 'em for later. That's a fair reminder, thanks, I will do that. I'm a bit in the dark about this Commit Fest, to be honest. Is this the list of patches to be reviewed? http://wiki.postgresql.org/wiki/Todo:CommitFest I was suspicious of that because it mentions Minor changes to Recovery related code by Simon Riggs, which I'd already mentioned had been committed more than 6 months ago. ISTM that nobody has reviewed anything except you, Tom, from the list. Is that true, or are there others working on reviews I can't see? or maybe the patch list is this? http://wiki.postgresql.org/wiki/Todo:PatchStatus I'll review Tom Doran's and Dany DeBontridder's work. Incidentally, I'm in favour of letting Heikki review his own work because there's a backlog on index changes that appears to be months long and he has a good chance of tackling that. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Integer datetimes
Tom Lane napsal(a): Alvaro Herrera [EMAIL PROTECTED] writes: Neil Conway wrote: Sure -- I sent in a patch earlier, but I'll post an updated version shortly. Hmm, I mean just switching the default value in configure.in ... is there anything else that needs doing at this point? Well, that's hardly a one-liner. If nothing else there are probably multiple places in the documentation that need adjustment. Does we keep same OID for this type? I prefer to redefine it as new type. It helps to determine which type is it for upgrade purpose. I think best solution is to have both code floating/int active and configure or initdb only perform correct linking in BKI file to preferred variant. The result will be two datatypes datetime and timestamp_int or timestamp_float. Or maybe better is to have two datatypes timestamp_int timestamp_float and one domain timestamp which points to preferred type. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit Fest
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote: Simon, would it be too much to ask that you concentrate on reviewing existing patches during commit fest? Trying to get people to think about random new ideas is about the most direct undermining of the commit-fest concept that I can think of. Save 'em for later. That's a fair reminder, thanks, I will do that. I'm a bit in the dark about this Commit Fest, to be honest. Is this the list of patches to be reviewed? http://wiki.postgresql.org/wiki/Todo:CommitFest That was labelled experimental and in-progress. It was my attempt to dump Bruces mailbox into the wiki. Unfortunately not enough information was present in Bruce's pages to do that reasonably. The list is at http://momjian.us/cgi-bin/pgpatches It would be nice if we could remove the patches which have been reviewed or applied from that list, but only Bruce can do that. Tom's berated Bruce once for not focusing on the commitfest so I suspect that may happen soon. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Simon Riggs wrote: On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote: Simon, would it be too much to ask that you concentrate on reviewing existing patches during commit fest? Trying to get people to think about random new ideas is about the most direct undermining of the commit-fest concept that I can think of. Save 'em for later. That's a fair reminder, thanks, I will do that. I'm a bit in the dark about this Commit Fest, to be honest. Is this the list of patches to be reviewed? http://wiki.postgresql.org/wiki/Todo:CommitFest I was suspicious of that because it mentions Minor changes to Recovery related code by Simon Riggs, which I'd already mentioned had been committed more than 6 months ago. ISTM that nobody has reviewed anything except you, Tom, from the list. Is that true, or are there others working on reviews I can't see? or maybe the patch list is this? http://wiki.postgresql.org/wiki/Todo:PatchStatus I'll review Tom Doran's and Dany DeBontridder's work. Incidentally, I'm in favour of letting Heikki review his own work because there's a backlog on index changes that appears to be months long and he has a good chance of tackling that. Umm, I don't think there's any patches from me in the queue that need review. There's some discussion threads related to bitmap indexes, but that's all. We're definitely not going to get bitmap indexes in this commit fest. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Simon Riggs wrote: On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote: Simon, would it be too much to ask that you concentrate on reviewing existing patches during commit fest? Trying to get people to think about random new ideas is about the most direct undermining of the commit-fest concept that I can think of. Save 'em for later. That's a fair reminder, thanks, I will do that. I'm a bit in the dark about this Commit Fest, to be honest. Is this the list of patches to be reviewed? http://wiki.postgresql.org/wiki/Todo:CommitFest I don't think that list is complete. The full archive is: http://momjian.us/cgi-bin/pgpatches Sorry, there is no summary. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
On Fri, 2008-03-21 at 08:48 -0400, Bruce Momjian wrote: I don't think that list is complete. The full archive is: http://momjian.us/cgi-bin/pgpatches Sorry, there is no summary. I've reviewed Nikhil's partitioning patch for now. I have some time to contribute, but not much. I don't want to review things that will be rejected for other reasons, so unless there is clearer information I don't see how I can contribute further. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new large object API
What is evil with a polymorphic function?
(1) It's creating a false match --- your proposed entry in the opr_sanity
results has nothing at all to do with what the test is looking for.
(2) Refactoring to have two separate C functions will make the code
clearer, and not noticeably longer.
Ok, here is the revised patch.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: src/backend/libpq/be-fsstubs.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/be-fsstubs.c,v
retrieving revision 1.87
diff -c -r1.87 be-fsstubs.c
*** src/backend/libpq/be-fsstubs.c 1 Jan 2008 19:45:49 - 1.87
--- src/backend/libpq/be-fsstubs.c 21 Mar 2008 14:35:02 -
***
*** 79,84
--- 79,85
static intnewLOfd(LargeObjectDesc *lobjCookie);
static void deleteLOfd(int fd);
+ static Oid lo_import_internal(text *filename, Oid lobjOid);
/*
***
*** 320,333
lo_import(PG_FUNCTION_ARGS)
{
text *filename = PG_GETARG_TEXT_P(0);
Filefd;
int nbytes,
tmp;
charbuf[BUFSIZE];
charfnamebuf[MAXPGPATH];
LargeObjectDesc *lobj;
! Oid lobjOid;
!
#ifndef ALLOW_DANGEROUS_LO_FUNCTIONS
if (!superuser())
ereport(ERROR,
--- 321,354
lo_import(PG_FUNCTION_ARGS)
{
text *filename = PG_GETARG_TEXT_P(0);
+
+ PG_RETURN_OID(lo_import_internal(filename, InvalidOid));
+ }
+
+ /*
+ * lo_import_with_oid -
+ * imports a file as an (inversion) large object specifying oid.
+ */
+ Datum
+ lo_import_with_oid(PG_FUNCTION_ARGS)
+ {
+ text *filename = PG_GETARG_TEXT_P(0);
+ Oidoid = PG_GETARG_OID(1);
+
+ PG_RETURN_OID(lo_import_internal(filename, oid));
+ }
+
+ static Oid
+ lo_import_internal(text *filename, Oid lobjOid)
+ {
Filefd;
int nbytes,
tmp;
charbuf[BUFSIZE];
charfnamebuf[MAXPGPATH];
LargeObjectDesc *lobj;
! Oid oid;
!
#ifndef ALLOW_DANGEROUS_LO_FUNCTIONS
if (!superuser())
ereport(ERROR,
***
*** 356,367
/*
* create an inversion object
*/
! lobjOid = inv_create(InvalidOid);
/*
* read in from the filesystem and write to the inversion object
*/
! lobj = inv_open(lobjOid, INV_WRITE, fscxt);
while ((nbytes = FileRead(fd, buf, BUFSIZE)) 0)
{
--- 377,388
/*
* create an inversion object
*/
! oid = inv_create(lobjOid);
/*
* read in from the filesystem and write to the inversion object
*/
! lobj = inv_open(oid, INV_WRITE, fscxt);
while ((nbytes = FileRead(fd, buf, BUFSIZE)) 0)
{
***
*** 378,384
inv_close(lobj);
FileClose(fd);
! PG_RETURN_OID(lobjOid);
}
/*
--- 399,405
inv_close(lobj);
FileClose(fd);
! return oid;
}
/*
Index: src/include/catalog/pg_proc.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.482
diff -c -r1.482 pg_proc.h
*** src/include/catalog/pg_proc.h 1 Jan 2008 19:45:57 - 1.482
--- src/include/catalog/pg_proc.h 21 Mar 2008 14:35:07 -
***
*** 1027,1032
--- 1027,1034
DATA(insert OID = 764 ( lo_import PGNSP PGUID 12 1 0 f f t f v
1 26 25 _null_ _null_ _null_ lo_import - _null_ _null_ ));
DESCR(large object import);
+ DATA(insert OID = 767 ( lo_import PGNSP PGUID 12 1 0 f f t f v
2 26 25 26 _null_ _null_ _null_ lo_import_with_oid - _null_ _null_ ));
+ DESCR(large object import);
DATA(insert OID = 765 ( lo_export PGNSP PGUID 12 1 0 f f t f v
2 23 26 25 _null_ _null_ _null_ lo_export - _null_ _null_ ));
DESCR(large object export);
Index: src/include/catalog/catversion.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.442
diff -c -r1.442 catversion.h
*** src/include/catalog/catversion.h10 Mar 2008 13:53:35 - 1.442
--- src/include/catalog/catversion.h21 Mar 2008 14:35:07 -
***
*** 53,58
*/
/*mmddN */
! #define CATALOG_VERSION_NO200803101
#endif
--- 53,58
*/
/*mmddN */
! #define CATALOG_VERSION_NO200803211
#endif
Index: src/include/libpq/be-fsstubs.h
Re: [HACKERS] [Fwd: Re: [PATCHES] 64-bit CommandIds]
Hans-Juergen Schoenig [EMAIL PROTECTED] writes: Doing this for XIDs is pretty useless this days. It is only targeted for command ids which are consumed heavily by stored procedure languages. It happens once on a while that a complex business logic procedure runs out of command ids inside a transaction. the idea is to give users a chance to avoid that. touching XIDs does not make sense to me at all. In view of the fact that 8.3 greatly reduced the CommandID consumption of typical plpgsql code http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php I wonder whether the case for wider CIDs hasn't likewise taken a major hit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Heikki Linnakangas wrote: Simon Riggs wrote: Incidentally, I'm in favour of letting Heikki review his own work because there's a backlog on index changes that appears to be months long and he has a good chance of tackling that. Umm, I don't think there's any patches from me in the queue that need review. There's some discussion threads related to bitmap indexes, but that's all. We're definitely not going to get bitmap indexes in this commit fest. There is your CopyReadLineText speedup, but I think there are too many open questions on it, e.g.: * should we change the line-end detection mode in text (non-CSV) mode by looking for an LF preceded by an even number of backslashes, or some similar logic? * how do we decide when to use the memchr tests rather than char by char tests? * is there a more economical way to code the searcher? (although I could live with it for now) So I suggest we take it out of the queue for now and kick it back to you. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Integer datetimes
Zdenek Kotala [EMAIL PROTECTED] writes: The result will be two datatypes datetime and timestamp_int or timestamp_float. This is not happening, at least not without 100 times more work than anyone has shown willingness to put into the issue. It seems fairly clear that everyone thinks the int64 datatypes will be the mainstream usage, and the float implementation will be interesting only on very old platforms or for very specialized applications. I cannot see us putting in the effort needed to refactor the code as two simultaneously-available datatypes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Heikki Linnakangas [EMAIL PROTECTED] writes: Umm, I don't think there's any patches from me in the queue that need review. There's some discussion threads related to bitmap indexes, but that's all. We're definitely not going to get bitmap indexes in this commit fest. I think there are basically three types of work represented in the current patch queue: 1. Actual patches that have some hope of being applied now, and if not we are supposed to provide feedback about what's needed to fix them. 2. Design proposals that require further feedback. I think the idea of the commit fest is that we should provide such feedback now, so that whoever is going to work on it can proceed. 3. Discussions that don't really need any further feedback right now, but should be summarized as TODO entries. The reason category 3 is represented is that this is after all Bruce's personal work queue (you'll remember that I pushed him to open it up before he'd finished cleaning out that type of entry). Personally I've been trying to knock off items in category 1. It'd be useful for people to go through some of the longer discussion threads and try to categorize them as needing further discussion now or being just TODO items. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new large object API
Tatsuo Ishii [EMAIL PROTECTED] writes:
Ok, here is the revised patch.
This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.
SELECT lo_unlink(173454); -- deletes large object with OID 173454
INSERT INTO image (name, raster)
VALUES ('beautiful image', lo_import('/etc/motd'));
+
+ INSERT INTO image (name, raster) -- same as above, but specify OID to use
+ VALUES ('beautiful image', lo_import('/etc/motd', 68583));
SELECT lo_export(image.raster, '/tmp/motd') FROM image
WHERE name = 'beautiful image';
/programlisting
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Andrew Dunstan [EMAIL PROTECTED] writes: There is your CopyReadLineText speedup, but I think there are too many open questions on it, e.g.: ... So I suggest we take it out of the queue for now and kick it back to you. Per my comments just now, the question is whether it's been adequately reviewed or still needs some attention from the community. If we think the ball's entirely in Heikki's court on it, then we're done with it until he comes back with a new version (or evidence showing it's good as-is). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timestamp datatype cleanup
On Thu, Mar 20, 2008 at 6:48 PM, Tom Lane [EMAIL PROTECTED] wrote: Warren Turkal [EMAIL PROTECTED] writes: I have to say, I am wondering more and more how real the need is for the two representations of timestamps. Would it be better to deprecate the float format or at least make the int64 format the default? This was gone over in great detail just recently ... didn't you see that thread? I actually hadnn't seen the resolution until just now. Thanks for pointing it out. wt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] serial arrays?
A recent message from a would-be mysql converter led me to realize
that we don't check for array decoration when we expand serial.
So this is accepted but doesn't do what one might expect:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence foo_f1_seq for serial
column foo.f1
CREATE TABLE
regression=# \d foo
Table public.foo
Column | Type |Modifiers
+-+--
f1 | integer | not null default nextval('foo_f1_seq'::regclass)
Should we throw an error for this? If not, what behavior would be
sane?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Add TimeOffset and DateOffset typedefs
On Thu, Mar 20, 2008 at 6:41 PM, Tom Lane [EMAIL PROTECTED] wrote: Warren Turkal [EMAIL PROTECTED] writes: I added TimeOffset and DateOffset typedefs to get rid of the instances using the HAVE_INT64_TIMESTAMP define being used to determine the types of variables or functions in timestamp.c. Applied with minor revisions. I dropped DateOffset since it didn't seem to be pulling its weight --- there was only one use and that was probably better declared as TimeOffset anyway. We can always add it later if we really do need it. Also I knocked over one or two other places (in files beyond the ones you touched) where there was a conditional declaration that could be eliminated. There sure are a lot of #ifdef HAVE_INT64_TIMESTAMP's left, though, aren't there :-(. It looked like the next thing to think about was how to unify the scale-dependent calculations. We could make some headway by defining a conversion constant that was either 100 or 1.0, but I'm worried about whether the C compiler is always smart enough to optimize away a floating point multiplication or division by 1.0 (there are at least some contexts where it *shouldn't* do that, I think). Might be better to make macros that either multiply/divide by 100 or do nothing. BTW, not sure if you're aware of this, but pgindent tends to add and subtract blank lines around #if/#else/#endif commands in weird, inconsistent ways. If the vertical spacing seems a bit odd after you've removed a conditional, feel free to fix it. I fixed a number of places like that in this patch. Thanks for the info. I will look over the conversions. I have had them in the back of my mind for a little while. wt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] serial arrays?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:55:26 -0400
Tom Lane [EMAIL PROTECTED] wrote:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence foo_f1_seq for
serial column foo.f1 CREATE TABLE
regression=# \d foo
Table public.foo
Column | Type |Modifiers
+-+--
f1 | integer | not null default nextval('foo_f1_seq'::regclass)
Should we throw an error for this? If not, what behavior would be
sane?
Interesting? Would be to create 11 sequences that can update each
element of the array. Sane? None. We should throw an error.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH4+m0ATb/zqfZUUQRAhNgAKCR9dM4lw7Wu7p1OMHm7ESWi25gxwCgqUuL
RkTa6gZqUqUXTlM6h97nf30=
=bwi3
-END PGP SIGNATURE-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] serial arrays?
On Fri, Mar 21, 2008 at 10:25 PM, Tom Lane [EMAIL PROTECTED] wrote:
A recent message from a would-be mysql converter led me to realize
that we don't check for array decoration when we expand serial.
So this is accepted but doesn't do what one might expect:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence foo_f1_seq for
serial column foo.f1
CREATE TABLE
regression=# \d foo
Table public.foo
Column | Type |Modifiers
+-+--
f1 | integer | not null default nextval('foo_f1_seq'::regclass)
Should we throw an error for this?
+1
If not, what behavior would be
sane?
I don't see any sane explanation if we do provide that syntax!!!
Best regards,
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
17° 29' 34.37N, 78° 30' 59.76E - Hyderabad *
18° 32' 57.25N, 73° 56' 25.42E - Pune
37° 47' 19.72N, 122° 24' 1.69 W - San Francisco
http://gurjeet.frihost.net
Mail sent from my BlackLaptop device
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: There is your CopyReadLineText speedup, but I think there are too many open questions on it, e.g.: ... So I suggest we take it out of the queue for now and kick it back to you. Per my comments just now, the question is whether it's been adequately reviewed or still needs some attention from the community. If we think the ball's entirely in Heikki's court on it, then we're done with it until he comes back with a new version (or evidence showing it's good as-is). My comments were intended to say I think the latter is the case (since I had previously undertaken to review this patch). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for Null Bitmap Optimization(for Trailing NULLs)
I would work on this and try to present the performance test results. I would also go ahead and examine, whether the logic can be added into heap_form_tuple by any means. Thanks, Gokul. On Wed, Mar 19, 2008 at 12:11 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Added to TODO: * Consider not storing a NULL bitmap on disk if all the NULLs are trailing http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php Tom's comments are: What this lacks is some performance testing to measure the cost of the extra tests in heap_form_tuple. If that can be shown to be negligible then it's probably worth doing though I don't like any part of the actually submitted patch ;-). All this should need is a bit more logic in heap_form_tuple and heap_formtuple. --- Gokulakannan Somasundaram wrote: Hi, Currently we check for the existence of NULL values in the tuple and we set the has_null flag. If the has_null flag is present, the tuple will be storing a null bitmap. What i propose is a) By modifying the functions, heap_form_tuple and heap_fill_tuple, we can check whether all the nulls are trailing nulls. If all the nulls are trailing nulls, then we will not set the has_null flag and we will not have the null bitmap with the tuple. b) While selecting the tuple, we will check whether the tuple offset equals / exceeds the length of the tuple and then mark the remaining attributes of the tuple as null. To be exact, we need to modify the slot_deform_tuple in order to achieve the same. This may not give huge performance benefits, but as you may know, it will help is reducing the disk footprint. Expecting your comments.. -- Thanks, Gokul. CertoSQL Project, Allied Solution Group. (www.alliedgroups.com) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: There is your CopyReadLineText speedup, but I think there are too many open questions on it, e.g.: ... So I suggest we take it out of the queue for now and kick it back to you. Per my comments just now, the question is whether it's been adequately reviewed or still needs some attention from the community. If we think the ball's entirely in Heikki's court on it, then we're done with it until he comes back with a new version (or evidence showing it's good as-is). I'm not expecting any more review in this commit fest. My plan is to try special-casing the usual case of text-mode in a non ASCII-embedding encoding (one that can be used as server encoding), by using memchr() to find end of line first, and then scanning back from there to count preceding backslashes. That requires some refactoring, but should avoid the performance penalty when there's plenty of backslashes. Of course, if anyeone has better ideas, please speak up! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commit Fest (was Re: [HACKERS] Sort Refinement)
Heikki Linnakangas wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: There is your CopyReadLineText speedup, but I think there are too many open questions on it, e.g.: ... So I suggest we take it out of the queue for now and kick it back to you. Per my comments just now, the question is whether it's been adequately reviewed or still needs some attention from the community. If we think the ball's entirely in Heikki's court on it, then we're done with it until he comes back with a new version (or evidence showing it's good as-is). I'm not expecting any more review in this commit fest. My plan is to try special-casing the usual case of text-mode in a non ASCII-embedding encoding (one that can be used as server encoding), by using memchr() to find end of line first, and then scanning back from there to count preceding backslashes. That requires some refactoring, but should avoid the performance penalty when there's plenty of backslashes. Of course, if anyeone has better ideas, please speak up! That won't work for CSV mode, of course, which leaves us with trying to refine your previous solution in that case. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [EMAIL PROTECTED]: Re: [pgsql-es-ayuda] SLL error 100% cpu]
Added to TODO: o Prevent SSL from sending network packets to avoid interference with Win32 signal emulation http://archives.postgresql.org/pgsql-hackers/2007-12/msg00455.php --- Magnus Hagander wrote: On Wed, Dec 12, 2007 at 12:30:50AM -0500, Tom Lane wrote: Trevor Talbot [EMAIL PROTECTED] writes: On 12/11/07, Tom Lane [EMAIL PROTECTED] wrote: I dunno anything about how to fix the real problem (what's winsock error 10004?), WSAEINTR, A blocking operation was interrupted by a call to WSACancelBlockingCall. Oh, then it's exactly the same thing as our bug #2829. I opined in that thread that OpenSSL was broken because it failed to treat this as a retryable case like EINTR. But not being much of a Windows person, that might be mere hot air. Someone with a Windows build environment should try patching OpenSSL to treat WSAEINTR the same as Unix EINTR and see what happens ... When I last looked at this (and this was some time ago), I suspected (and still do) that the problem is in the interaction between our socket-emulation-stuff (for signals) and openssl. I'm not entirely sure, but I wanted to rewrite the SSL code so that *our* code is responsible for aclling the actuall send()/recv(), and not OpenSSL. This would also fix the fact that if an OpenSSL network operation ends up blocking, that process can't receive any signals... I didn't have time to get this done before feature-freeze though, and I beleive the changes are large enough to qualify as such.. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for db level triggers
Hi, We have something that seems to work and may be used as a start point. Please, take a look at http://gorda.di.uminho.pt/community/pgsqlg/ In particular, take a look at the file src/backend/commands/triggerspecial. Cheers, Alfranio. On Mar 13, 2008, at 5:14 PM, James Mansion wrote: James Mansion wrote: In usage: AFTER START clears counters and flags. UPDATE triggers on data set counters and flags. BEFORE COMMIT examines the counters and flags and performs any final validation or adjustments (or external events such as sending a MoM message) I'd like to point out also that AFTER CONNECT is a good opportunity to CREATE TEMP TABLE (be nice if a global temp table definition could be persisted and automatically duplicated into each session, but never mind). +1 on both counts. Can we get a TODO? -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new large object API
Tatsuo Ishii [EMAIL PROTECTED] writes:
Ok, here is the revised patch.
This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.
SELECT lo_unlink(173454); -- deletes large object with OID 173454
INSERT INTO image (name, raster)
VALUES ('beautiful image', lo_import('/etc/motd'));
+
+ INSERT INTO image (name, raster) -- same as above, but specify OID to use
+ VALUES ('beautiful image', lo_import('/etc/motd', 68583));
SELECT lo_export(image.raster, '/tmp/motd') FROM image
WHERE name = 'beautiful image';
/programlisting
Thanks for the comment. I have committed with your suggested doc
changing.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
