On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera wrote:
> I am reworking this patch, both to accomodate earlier review comments
> and to fix the multiple verify step of namespaces, as noted by Tom in
> 4530.1390023...@sss.pgh.pa.us
>
>
Alvaro,
Do you need some help?
Regards,
--
Fabrízio de Royes
On Sun, Dec 1, 2013 at 12:07:21PM -0500, Gurjeet Singh wrote:
> On Wed, Nov 27, 2013 at 9:12 AM, Robert Haas wrote:
>
>
> This is a performance patch, so it should come with benchmark results
> demonstrating that it accomplishes its intended purpose. I don't see
> any.
>
>
> Yes,
On Mon, Nov 18, 2013 at 10:13:19PM -0500, Bruce Momjian wrote:
> On Tue, Nov 12, 2013 at 10:35:58AM +, Marc Mamin wrote:
> > Hello,
> >
> > IMHO, there is a serious issue in the script to clean the old data directory
> > when running pg_upgrade in link mode.
> >
> > in short: When working w
On Fri, Mar 7, 2014 at 7:59 PM, Bruce Momjian wrote:
> On Fri, Mar 7, 2014 at 07:18:04PM +0530, Amit Kapila wrote:
>> > OK, done with the attached patch Three is returned for status, but one
>> > for other cases.
>>
>> I think it would have been better if it return status as 4 for cases where
>>
[I answered most of these concerns in more detail in the reply to Dimitri.]
On 3/7/14, 9:16 AM, Stephen Frost wrote:
> Being able to have a self-contained module which requires a minimum of
> modification to postgresql.conf is a reduction in complexity, imv.
> Having to maintain two config options
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday users
>>> got of making sense of it?
>
>> T
On 3/7/14, 11:39 AM, Dimitri Fontaine wrote:
> Just please make sure that it's still possible to use full absolute path
> for the module path name so that the packager can have control too.
I can't think of any package system where absolute paths are part of a
recommended workflow. There is alway
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday users
>>> got of making sense of it?
>
>> T
Florian Pflug writes:
> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>> My advice is to lose the EXPLAIN output entirely. If the authors of
>> the patch can't agree on what it means, what hope have everyday users
>> got of making sense of it?
> The question isn't what the current output means, but
On 05/03/14 15:44, Craig Ringer wrote:
On 03/05/2014 05:25 PM, Yeb Havinga wrote:
Maybe a naive thought, but shouldn't all plans that include a table with
an RLS clause be invalidated when the session role switches, regardless
of which users from and to?
Only if the plan is actually accessed wh
On Fri, Mar 7, 2014 at 10:03:42PM -0500, Bruce Momjian wrote:
> On Thu, Nov 14, 2013 at 11:32:23AM +0100, Marko Tiikkaja wrote:
> > On 11/14/13 7:08 AM, Tatsuo Ishii wrote:
> > >>It means "the connection is idle except for keepalive packets".
> > >>We could perhaps just drop the word "otherwise",
On Thu, Nov 14, 2013 at 11:32:23AM +0100, Marko Tiikkaja wrote:
> On 11/14/13 7:08 AM, Tatsuo Ishii wrote:
> >>It means "the connection is idle except for keepalive packets".
> >>We could perhaps just drop the word "otherwise", if people find
> >>it confusing.
> >
> >Wah. I seemed to completely mis
On Wed, Nov 13, 2013 at 10:28:07AM +0100, Colin 't Hart wrote:
> David et al,
>
> How about something like this?
I have applied a modified version of your patch. I didn't like the
idea of putting "SELECT" inside an OR syntax clauses --- the syntax is
already too complicated. I also didn't like
On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote:
> On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera
> wrote:
>
> > I am reworking this patch, both to accomodate earlier review comments
> > and to fix the multiple verify step of namespaces, as noted by Tom in
> > 4530.1390023...@sss.pgh.
I was testing some builds I was doing and found that the regression
tests fails when doing the against a Hot Standby server:
$ make standbycheck
[...]
== running regression test queries==
test hs_standby_check ... ok
test hs_standby_allowed ... FAILED
Patrick Curran writes:
> We use Postgres in our product and we have a client that requires a
> static code analysis scan to detect vulnerabilities. They are concerned
> because the tool (Veracode) found several flaws in Postgres and they
> believe there might be a security risk. I'm sure there
On Fri, Mar 7, 2014 at 7:21 PM, Andres Freund wrote:
> On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote:
> > On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera >wrote:
> >
> > > I am reworking this patch, both to accomodate earlier review comments
> > > and to fix the multiple verify step
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera wrote:
> I am reworking this patch, both to accomodate earlier review comments
> and to fix the multiple verify step of namespaces, as noted by Tom in
> 4530.1390023...@sss.pgh.pa.us
>
>
This link is broken...
--
Fabrízio de Royes Mello
Consultoria/
On Fri, Mar 7, 2014 at 12:55 PM, Peter LaDow wrote:
> Just to be clear, what do you mean by "nontrivial code"? Do you mean
> C library calls, other than fork/exec/_exit?
I think I've answered my own question:
http://man7.org/linux/man-pages/man7/signal.7.html
The 'Async-signal-safe functions'
On Mar 6, 2014, at 1:51 AM, Peter Geoghegan wrote:
>> It's true for perl. Syntax of hstore is close to hash/array syntax and it's
>> easy serialize/deserialize hstore to/from perl. Syntax of hstore was
>> inspired by perl.
>
> I understand that. There is a module on CPAN called Pg::hstore that
>
On Thu, Mar 6, 2014 at 7:44 AM, Fabrízio de Royes Mello
wrote:
> Hi all,
>
> There are some place with the next commitfest deadlines (2014/06 and
> 2014/09) ?
>
> Regards,
Those deadlines won't be finalized until after PGCon, but it seems
likely to me that we'll do about what we did last year.
-
Hi,
We use Postgres in our product and we have a client that requires a
static code analysis scan to detect vulnerabilities. They are concerned
because the tool (Veracode) found several flaws in Postgres and they
believe there might be a security risk. I'm sure there are lots of
companies tha
I am reworking this patch, both to accomodate earlier review comments
and to fix the multiple verify step of namespaces, as noted by Tom in
4530.1390023...@sss.pgh.pa.us
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Se
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund wrote:
> Forking twice is ok as well, as long as you just use _exit() after the
> fork. The thing is that you shouldn't run any nontrivial code in the
> fork, as long as you're connected to the original environment (fd's,
> memory mappings and so fort
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund wrote:
> Man. The point is that that the library code is carefully written to not
> use exit() but _exit() after a fork failure, that's it.
I understand your point. I understand that in the case of the
postmaster we don't want to invoke behavior tha
On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
> On Friday, March 7, 2014, Andres Freund wrote:
> >
> > If the third party library is suitably careful it will only use fork()
> > and then exec() or _exit(), otherwise there are other things that'll be
> But that is not possible* in our case of t
On Friday, March 7, 2014, Andres Freund wrote:
>
> If the third party library is suitably careful it will only use fork()
> and then exec() or _exit(), otherwise there are other things that'll be
But that is not possible* in our case of trying to spawn an asynchronous
backgound process. The goal
On Fri, Mar 7, 2014 at 1:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane wrote:
>>> I just noticed that the DSM patch has introduced a whole new class of
>>> failures related to the bug #9464 issue: to wit, any on_detach
>>> actions registered in a paren
On 2014-03-07 14:14:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
> >> The big picture here is that in the scenario being debated in the other
> >> thread, exit() in a child process forked from a backend will execute that
> >> backend's on_deta
Andres Freund writes:
> On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
>> The big picture here is that in the scenario being debated in the other
>> thread, exit() in a child process forked from a backend will execute that
>> backend's on_detach actions *even if the code had done on_exit_reset afte
Hi,
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
> Robert Haas writes:
> > I don't think this can actually happen. There are quite a number of
> > things that would go belly-up if you tried to use dynamic shared
> > memory from the postmaster, which is why dsm_create() and dsm_attach()
> > both
Robert Haas writes:
> On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane wrote:
>> I just noticed that the DSM patch has introduced a whole new class of
>> failures related to the bug #9464 issue: to wit, any on_detach
>> actions registered in a parent process will also be performed when a
>> child proces
On 2014-03-07 13:27:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > A patch fixing this is attached. I've added some more local variables to
> > deal with the longer lines...
>
> Since I've got a compiler in captivity that complains about this,
> I'll take care of checking and committing th
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane wrote:
> I just noticed that the DSM patch has introduced a whole new class of
> failures related to the bug #9464 issue: to wit, any on_detach
> actions registered in a parent process will also be performed when a
> child process exits, because nothing ha
Andres Freund writes:
> A patch fixing this is attached. I've added some more local variables to
> deal with the longer lines...
Since I've got a compiler in captivity that complains about this,
I'll take care of checking and committing this patch.
I still think it might be a good idea to spin u
Hello
I am returning back to this topic. Last time I proposed styles:
http://www.postgresql.org/message-id/cafj8prclgoktryjpbtoncpgyftrcz-zgfowdc1jqulb+ede...@mail.gmail.com
http://postgres.cz/wiki/Pretty_borders_in_psql
This experiment fails, but there are some interesting tips in discuss.
So
Hi,
On 2014-03-07 09:50:15 -0800, Peter LaDow wrote:
> Also, the on_exit_reset() does clear up the issue, and we have
> implemented it as suggested in this thread (calling it immediately
> after the fork() in the child). And Andres' keen eye noted we were
> calling exit() after an exec() failure,
On 7 March 2014 17:46, Tom Lane wrote:
> There are a few threads floating around currently in which some of
> the cc'd addresses are various-people at hobby.2ndquadrant.com.
> Addresses like that seem not to work, or at least not work reliably.
> I believe the official addresses are just soandso a
Craig Ringer writes:
> What I'm concerned about is the locking. It looks to me like we're
> causing the user to lock rows that they may not intend to lock, by
> applying a LockRows step *before* the user supplied qual. (I'm going to
> test that tomorrow, it's sleep time in Australia).
The fact th
Sorry for the bit of top-posting, but I wanted to make some things
clear. Also, I wasn't subscribed to pgsql-hackers at the time this
thread began, so I apologize for the missing headers that might cause
threading issues.
I'm the submitter of bug #9464. Here's the background on what we are
doing
There are a few threads floating around currently in which some of
the cc'd addresses are various-people at hobby.2ndquadrant.com.
Addresses like that seem not to work, or at least not work reliably.
I believe the official addresses are just soandso at 2ndquadrant.com.
If you're replying to any su
Craig Ringer writes:
> On 03/06/2014 02:58 AM, Tom Lane wrote:
>> The PlanInvalItem could perfectly well be generated by the planner,
>> no, if it has the user OID? But I'm not real sure why you need it.
>> I don't see the reason for an invalidation triggered by user ID.
>> What exactly about the
On Fri, Mar 7, 2014 at 11:57:48AM -0500, Andrew Dunstan wrote:
> >If they can be done for 9.4, great, if not, we have to decide if these
> >suboptimal cases are enough for us to delay the data type until 9.5. I
> >don't know the answer, but I have to ask the question.
> >
>
> AFAIK, there is no
On 03/07/2014 11:45 AM, Bruce Momjian wrote:
On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote:
IIRC The sacrifice was one bit in the header (i.e. in the first int
after the varlena header). We could now repurpose that (for example
if we ever decided to use a new format).
Oleg and
On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote:
> IIRC The sacrifice was one bit in the header (i.e. in the first int
> after the varlena header). We could now repurpose that (for example
> if we ever decided to use a new format).
>
> Oleg and Teodor made most of the adjustments on
Hi,
Peter Eisentraut writes:
> On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
>>directory = 'local/hstore-new'
>>module_pathname = '$directory/hstore'
>
> I think your previously proposed patch to add extension_control_path
> plus my suggestion to update existing de facto best practices to
On 03/06/2014 11:33 PM, Bruce Momjian wrote:
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb)
On Thu, Mar 6, 2014 at 10:33 PM, Bruce Momjian wrote:
> On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
>> Hi there,
>>
>> Looks like consensus is done. I and Teodor are not happy with it, but
>> what we can do :) One thing I want to do is to reserve our
>> contribution to the fl
Hi,
On 2014-03-07 10:24:31 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
> >> No, I think it should do nothing. The coding pattern shown in bug #9464
> >> seems perfectly reasonable and I think we should allow it.
>
> > I don't think it's a rea
Hi,
On 2014-03-06 02:39:37 +0100, Andres Freund wrote:
> Unless somebody protests I'll try to get the remaining walsender and
> docs patches ready before sending in the patch fixing this as it's not
> disturbing the buildfarm. I'll be onsite/travelling tomorrow; so I am
> not sure I'll be done the
Andres Freund writes:
> On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
>> No, I think it should do nothing. The coding pattern shown in bug #9464
>> seems perfectly reasonable and I think we should allow it.
> I don't think it's a reasonable pattern run background processes that
> aren't managed
On 03/07/2014 04:10 PM, Tom Lane wrote:
Florian Weimer writes:
On 03/07/2014 03:57 PM, Tom Lane wrote:
It's not a reason not to do something about the much larger chance of
this happening in a direct child process, which certainly won't have a
matching PID.
Indeed. Checking getppid() in ad
Florian Weimer writes:
> On 03/07/2014 03:57 PM, Tom Lane wrote:
>> It's not a reason not to do something about the much larger chance of
>> this happening in a direct child process, which certainly won't have a
>> matching PID.
> Indeed. Checking getppid() in addition might narrow things down f
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
> >> In the bug thread I proposed making atexit_callback check whether getpid()
> >> still matches MyProcPid.
>
> > What are you proposing to do in that case? This is only one o
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be performed when a
child process exits, because nothing has been added to on_exit_reset
to prevent that. It seems l
On 03/07/2014 03:57 PM, Tom Lane wrote:
I think Florian's right that there's a risk there, but it seems pretty
remote, and I don't see any reliable way to detect the case anyhow.
(Process start time? Where would you get that from portably?)
I don't think there's a portable source for that. O
Heikki Linnakangas writes:
> On 03/07/2014 04:23 PM, Florian Weimer wrote:
>> There's the PID reuse problem. Forking twice (with a delay) could end
>> up with the same PID as MyProcPid.
> Not if the parent process is still running.
If the original parent backend is *not* still running, then run
Andres Freund writes:
> On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
>> In the bug thread I proposed making atexit_callback check whether getpid()
>> still matches MyProcPid.
> What are you proposing to do in that case? This is only one of the
> failure cases of forking carelessly, right?
No, I
On 03/07/2014 10:07 PM, Craig Ringer wrote:
> On 03/07/2014 09:33 PM, Craig Ringer wrote:
>> On 03/05/2014 11:02 AM, Craig Ringer wrote:
>>> The main known issue remaining is plan invalidation.
>>
>> I've pushed a version with a plan invalidation implementation. It's tagged:
>>
>> rls-9.4-upd-sb-
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
> In the bug thread I proposed making atexit_callback check whether getpid()
> still matches MyProcPid.
What are you proposing to do in that case? This is only one of the
failure cases of forking carelessly, right?
I think the only appropriate thing wo
On 03/07/2014 04:23 PM, Florian Weimer wrote:
On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, fro
On Fri, Mar 7, 2014 at 07:18:04PM +0530, Amit Kapila wrote:
> > OK, done with the attached patch Three is returned for status, but one
> > for other cases.
>
> I think it would have been better if it return status as 4 for cases where
> directory/file is not accessible (current new cases added b
On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, from some parent
backend process whose elbow we sh
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
> > What about allowing a control file like this:
> >
> ># hstore extension
> >comment = 'data type for storing sets of (key, value) pairs'
> >default_version = '1.3'
> >directory = 'local/hs
On 03/07/2014 03:48 PM, Robert Haas wrote:
On Fri, Mar 7, 2014 at 4:34 AM, Heikki Linnakangas
wrote:
>Hmm. You suggested ensuring that a scan always has at least a pin, and split
>takes a vacuum-lock. That ought to work. There's no need for the more
>complicated maneuvers you described, ISTM t
On 03/07/2014 09:33 PM, Craig Ringer wrote:
> On 03/05/2014 11:02 AM, Craig Ringer wrote:
>> The main known issue remaining is plan invalidation.
>
> I've pushed a version with a plan invalidation implementation. It's tagged:
>
> rls-9.4-upd-sb-views-v9
>
> in
>
> g...@github.com:ringerc/po
On Thu, Mar 06, 2014 at 06:14:21PM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes wrote:
> >
> > I've been tempted to implement a new type of hash index that allows both WAL
> > and high concurrency, simply by disallowing bucket splits. At the index
> > creation time you u
On 03/07/2014 03:48 PM, Robert Haas wrote:
>So, there seems to be a few fairly simple and independent improvements to be
>made:
>
>1. Replace the heavy-weight lock with pin & vacuum-lock.
>2. Make it crash-safe, by adding WAL-logging
>3. Only acquire the exclusive-lock (vacuum-lock after step 1)
[ I just sent a reply to Greg Stark's email which touches on some of
the same points you mentioned here; that was mostly written last
night, and finished this morning before seeing this. ]
On Fri, Mar 7, 2014 at 4:34 AM, Heikki Linnakangas
wrote:
> Hmm. You suggested ensuring that a scan always
On Fri, Mar 7, 2014 at 9:41 AM, Bruce Momjian wrote:
> On Fri, Mar 7, 2014 at 09:07:24AM +0530, Amit Kapila wrote:
>> One reason could be that as we are already returning special exit code
>> for 'status' option of pg_ctl (exit(3)), this seems to be inline with it as
>> this
>> also get called d
On 03/05/2014 11:02 AM, Craig Ringer wrote:
> The main known issue remaining is plan invalidation.
I've pushed a version with a plan invalidation implementation. It's tagged:
rls-9.4-upd-sb-views-v9
in
g...@github.com:ringerc/postgres.git
The invalidation implementation does not yet handle
On 2014-03-07 10:17:21 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
>
> > fprintf(stderr,
> > - _("%s: could not identify system: got
> > %d rows and %d fields, expected %d rows and %d fields\n"),
> > -
On Thu, Mar 6, 2014 at 7:07 PM, Greg Stark wrote:
> On Thu, Mar 6, 2014 at 11:14 PM, Robert Haas wrote:
>>> I've been tempted to implement a new type of hash index that allows both WAL
>>> and high concurrency, simply by disallowing bucket splits. At the index
>>> creation time you use a storage
Andres Freund escribió:
> fprintf(stderr,
> - _("%s: could not identify system: got
> %d rows and %d fields, expected %d rows and %d fields\n"),
> - progname, PQntuples(res),
> PQnfields(res), 1, 3);
>
Hi,
On 2014-03-05 23:20:57 +0100, Andres Freund wrote:
> On 2014-03-05 17:05:24 -0500, Robert Haas wrote:
> > > I very much dislike having the three different event loops, but it's
> > > pretty much forced by the design of the xlogreader. "My" xlogreader
> > > version didn't block when it neeeded
Hello,
> > After all, I have confirmed that this fixes the problem on crash
> > recovery of hot-standby botfor 9.3 and HEAD and no problem was
> > found except unreadability :(
>
> Ok, committed. Thanks!
Thank you.
> Any concrete suggestions about the readability? Is there some
> particular spo
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
> What about allowing a control file like this:
>
># hstore extension
>comment = 'data type for storing sets of (key, value) pairs'
>default_version = '1.3'
>directory = 'local/hstore-new'
>module_pathname = '$directory/hstore'
>
On 03/06/2014 02:18 AM, Bruce Momjian wrote:
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel->rd_smgr != NULL)
smgrsetowner(NULL, rel->rd_smgr)
when closing the fake relcac
On 03/06/2014 09:34 PM, Robert Haas wrote:
On Thu, Mar 6, 2014 at 8:11 AM, Heikki Linnakangas
wrote:
I don't think it's necessary to improve concurrency just to get WAL-logging.
Better concurrency is a worthy goal of its own, of course, but it's a
separate concern.
To some extent, I agree, bu
On 6 March 2014 22:43, Noah Misch wrote:
> On Tue, Mar 04, 2014 at 06:50:17PM +0100, Andres Freund wrote:
>> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
>> > Robert Haas writes: > I think this is all too
>> > late for 9.4, though.
>> >
>> > I agree with the feeling that a meaningful fix for pg_
On 03/07/2014 08:24 AM, Michael Paquier wrote:
In the documentation, particularly the doc index, syslog_ident is
incorrectly mentioned as syslog_identify. The attached patch fixes
that. This error is in the docs since 8.0.
Thanks, fixed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql
On Thu, Mar 6, 2014 at 12:09 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 03/05/2014 09:11 AM, Michael Paquier wrote:
>>> After testing this feature, I noticed that FORCE_NULL and
>>> FORCE_NOT_NULL can both be specified with COPY on the same column.
>
>> Strictly they are not actually cont
82 matches
Mail list logo
